Architectuur deel 2: De jodiBooks architectuur

Vorige keer kon je al lezen dat we bij jodiBooks noodgedwongen gekeken hebben naar onze architectuur. De conclusie: hij moet op de schop. Maar wat is een architectuur eigenlijk als je praat over software? Een software architectuur is een abstracte weergave van de software. Dat maakt het natuurlijk niet veel duidelijker.

De meeste mensen zijn wel bekend met de term architectuur als het gaat om gebouwen. Maar wat is de architectuur van een gebouw dan? Ook moelijk om woorden voor te vinden. Dus, nog een stapje terug. Naar degene die de architectuur bedenkt, de architect.

Een architect maakt een mooi plaatje van een gebouw. Dat plaatje of model ziet er vaak prachtig en flitsend uit. Maar met dat plaatje kun je geen gebouw bouwen. Je moet nog uitrekenen hoeveel beton, hout en stenen je nodig hebt. Waar er stalen balken in de plafonds moeten. Waar de leidingen moeten lopen. En nog zoveel meer details.

Bouwers vlechten beton bewapening
“Architectuur alleen maakt nog geen gebouw.” Foto door Josue Isai Ramos Figueroa op Unsplash

Bij software is het niet anders. De software architect bedenkt in grote lijnen wat de software moet kunnen en hoe het eruit moet zien. Maar daarmee is er nog geen regel code geschreven. Waar alle verbindingen (leidingen) moeten komen, moet nog bepaald worden. Ook is er nog geen idee hoeveel regels code (aantal stenen) er nodig zijn.

Om het iets praktischer te maken een voorbeeld. De architectuur van een WordPress website is een homepage verbonden met een database. Die homepage bestaat weer uit 4-7 bestanden die allemaal gevuld worden met dingen (tekst, plaatjes, videos) die opgeslagen worden in de database.

Software is nooit af

In tegenstelling tot een gebouw, evolueert software. Het verandert continu. Om precies te zijn, komt dat omdat je software al kunt gebruiken voordat het af is. Wie gaat er daarentegen in een gebouw slapen waar nog geen dak op zit en geen muren heeft?

Software is dus altijd in ontwikkeling. Terwijl je het gebruikt, worden er op de achtergrond nieuwe dingen aan toegevoegd. De vergelijking met huis zou zijn: de ene dag sta je te koken in je keuken met gasfornuis. Maar de volgende dag heb je opeens een kookeiland met inductiekookplaat.

Dit gaat een tijdlang goed, maar er komt een moment dat de leidingen in je huis niet meer groot genoeg zijn. Die gasleiding naar de keuken gebruik je niet meer, maar hij ligt er wel nog. En tegelijkertijd moet je om de week naar de meterkast omdat de zekering van de keuken er de hele tijd uitvliegt; die stroomkabel was niet berekend op een inductieplaat.

Keuken met kookeiland
Foto door iAlicante Mediterranean Homes op Unsplash

Onze huidige architectuur

Dit is precies wat er met jodiBooks ook gebeurd is. Toen we begonnen hadden we een idee van wat we wilden gaan maken. Met de kennis en ervaring van toen heeft Diana de huidige architectuur bedacht.

Het grootste probleem van deze architectuur is dat er een aantal dingen die niets met elkaar te maken hebben, toch aan elkaar geplakt zitten. Dit heeft veel nadelen, maar waarom hebben we het dan?

Hoe komt dat

Zoals gezegd is software nooit af. In het begin bedenk je met de beste bedoelingen hoe je het gaat maken, wat je gaat bouwen en hoe het eruit moet gaan zien. Maar in de praktijk begin je met bouwen en kom je erachter dat het toch niet lekker werkt. Je past ter plekke je architectuur een beetje aan.

Wat nog vaker gebeurt is dat jij zelf of een klant een nieuw idee heeft. Iets waar je van tevoren niet aan gedacht had. Dit bouw je er snel aan en je gaat weer verder. Doe je dit vaak genoeg, dan hangt er vanalles aan je product. Als een gebouw met meerdere aan- en uitbouwen, met allemaal andere hoogtes en kleuren. Welkom bij jodiBooks in 2019 🙂

schematisch overzicht huidige architectuur
Schematisch overzicht van onze huidige architectuur. (Dit is een heel erg versimpeld plaatje.)

Oorspronkelijk hadden we alleen het jodiBooks beauty dashboard. Later hebben we onze homepage (jodibooks.com) afgesplitst van het dashboard. Die kon nu apart gereleased worden. Nog wat later hebben we een API ertussen gezet en is onze app die gaan gebruiken. In de tussentijd zijn er allemaal losse applicaties bijgekomen om jodiBooks te beheren. We sturen automatische facturen naar onze klanten. Mollie wilde graag een toegangspunt (API) hebben om ons te informeren over betalingen. En we wilden allerlei instellingen van jodiBooks kunnen beheren.

Zoals je kunt zien in het plaatje wijzen er heel veel pijlen naar de cilinder onderaan; de database. Als we een klein dingetje willen veranderen aan de database omdat een van de vierkantjes het nodig heeft, dan moeten we nu vaak alle vierkantjes met een pijl naar de database updaten.

De nadelen

Als we op dit moment een release doen van de website, moeten we vaak alles releasen. Dat is opzich nog niet zo’n punt, want het daadwerkelijk releasen gaat vrij snel. Maar alles moet dan ook getest worden en de hele website moet uit de lucht. Klanten kunnen dus niet bij hun data via het dashboard als wij het beheerpaneel willen aanpassen.

Als we kijken naar de toekomst, maakt dit het ook lastig om op te schalen. Stel de server waarop jodiBooks draait kan 100 klanten tegelijk aan. Als er dan een keer 120 willen inloggen, wordt het weer traag voor iedereen. Dat kun je oplossen door twee servers neer te zetten, waardoor iedere server 60 klanten doet. Maar dan heb je ook 2 Mollie-api’s en 2 beheerpanelen. Helemaal niet nodig. En waar staat de database dan? Want daar heb je er altijd maar eentje van.

Hoster beperkingen

Er zitten ook wat concessies in onze architectuur, die we eigenlijk helemaal niet wilden hebben. Onze huidige hoster ondersteunt bijvoorbeeld geen windows services (wel in een duurder pakket). Een windows service is een applicatie (app) die de hele tijd niks doet behalve wachten op een instructie. Zodra hij die krijgt, doet hij zijn trucje en gaat weer wachten.

Nu hebben we een applicatie moeten maken die een wekker nodig heeft. Iedere x minuten maken we hem wakker en geven hem de instructie: “hey, kijk even of je iets te doen hebt”. Daardoor moet je als klant nu bijvoorbeeld tot 5 minuten wachten op je boekhouder export. We maken de export applicatie namelijk iedere 5 minuten wakker.

En omdat onze hoster heel zuinig is, worden al die applicaties standaard na een paar minuten weer uitgezet. We moeten ze dus iedere keer opnieuw wakker maken. Dat kost altijd even wat tijd, waardoor het bijvoorbeeld dus even kan duren voordat je bent ingelogd in jodiBooks.

Onze gewenste architectuur

De meest voor de hand liggende wijziging is het opknippen van onze software. Opknippen pakt de meeste problemen die we nu hebben aan. We gaan dit in meerdere stappen doen, zodat we een voor een alle nadelen kunnen wegnemen.

1. Het klantgedeelte losknippen van het interne beheer gedeelte

Het eerste voordeel hiervan is dat klanten geen last hebben van wijzigingen aan interne jodiBooks software. Waarom zouden ze ook? Het tweede voordeel is dat we daarmee ook het beheerpaneel niet meer “op internet” hoeven te zetten. Het is dus een stuk veiliger.

schematisch overzicht nieuwe architectuur
Schematisch overzicht van onze gewenste architectuur

2. De API standaardiseren

Doordat het dashboard, de app en de website allemaal via dezelfde API hun gegevens uit de database halen, hebben ze ook allemaal de beschikking over dezelfde data. Bij de huidige architectuur heeft de app bijvoorbeeld een andere set data dan het dashboard. En moeten we alles twee keer programmeren.

3. Minder verbindingen met de database

Zoals je kunt zien zijn er minder verbindingen (pijlen) met de database (de cilinder). Dat maakt het onderhoudt aan die pijlen en de database een stuk simpeler. We hoeven nog maar 3 pijlen te checken in plaats van 6. Dat maakt het doen en voorbereiden van een release makkelijker en sneller.

4. Losse applicaties

Nu we alles losgeknipt hebben, kunnen we iedere applicatie (ieder blokje) en de database een voor een verhuizen. Het hoeft niet in een keer, waardoor de verhuizing een stuk makkelijker wordt. Ook kunnen we nu gebruik gaan maken van de voordelen van AWS of Azure. We kunnen ook voor ieder blokje de perfecte server zoeken en die servers zijn ook heel makkelijk op te schalen. Dat kun je als volgt zien.

Jij (de applicatie) hebt een salon (de server) waar je normaal gesproken alleen werkt. Dat doe je zo goed dat je meestal een paar weken van te voren volgeboekt bent. Dat is leuk, maar eigenlijk wil je je klanten niet zo lang laten wachten.

Met een AWS/Azure voor beautyspecialisten, zou je personeel kunnen inhuren dat precies past. Je huurt een pedicure in als veel klanten daarom vragen. Of een haarstylist, gespecialiseerd in bruidskapsels.

Wat AWS nou ook nog voor jou doet is zorgen dat die persoon precies zoveel komt werken als jij nodig hebt. Dat is de ene week misschien 3 dagen, de andere week 4 uur. Je hebt dus altijd precies genoeg personeel (servers ons geval).

Het Amazon logo op een telefoon bij gebrek aan een AWS logo
Foto door Christian Wiediger op Unsplash

5. Nieuwe technieken

Nu we toch aan de slag moeten, gaan we meteen kijken welke nieuwe technieken er zijn. Wij maken gebruik van ASP.NET MVC 5.2.6. Een hele mond vol en alweer 1 jaar oud. Sterker nog, de techniek is nog ouder: Dit pakket is 6 jaar geleden uitgebracht. Natuurlijk zijn er wel kleine verbeteringen gedaan, maar het wordt voor ons steeds moeilijker om gebruik te maken van de nieuwste features. Om bij de tijd te blijven moeten we dus een keer overschakelen naar .NET Core.

Wat moet daarvoor gebeuren

We hebben een goed beeld van hoe de architectuur eruit moet gaan zien. Maar we hebben nog geen idee waar alle leidingen moeten komen en hoeveel stenen we nodig hebben. Er moet dus een hoop herontworpen worden, zodat we zeker weten dat we weer een tijdje vooruit kunnen.

Als dat bekend is, moet het ook gebouwd worden. Daarvoor moeten we precies in kaart gaan brengen wat we los gaan halen, zodat de rest niet omvalt. Het is net als de verbouwing van een treinstation. Alle treinen moeten gewoon blijven rijden en ondertussen wordt er omheen een nieuw gebouw neergezet.

trein op station
Foto door Marc Kleen op Unsplash

Als een onderdeel daadwerkelijk gebouwd is, moet alles getest worden. Werkt alles nog zoals gepland? Ja? Dan gaan we dit nieuwe deel releasen. Dat betekent gepland onderhoud en dus even geen treinen. Dit zullen we net zoals nu ruim van te voren plannen. No worries, het zal niet zolang duren als bij de trein.

Planning

Onze huidige architectuur is met iedere feature die we aan jodiBooks Beauty toevoegden gegroeid. Bij iedere feature hebben we de keuze gemaakt om eerst de feature te implementeren en daarna “een keer” naar de architectuur te kijken. Een heel ervaren software engineer en vriend van Diana vatte het mooi samen: “feature-first, foei!”.

Het is een keuze die wij heel bewust gemaakt hebben. Een klant heeft niks aan een mooie architectuur. Natuurlijk wil een klant een snelle website die niet crasht, maar daar komen ze niet voor. Klanten willen iets kunnen doen op die website. Het liefst iets waar ze ook mee geholpen worden. Dat bouwen wij graag voor jullie.

Om ons toch te dwingen om ook aan de architectuur te gaan werken hebben we milestones in onze planning gezet. Iedere ca. 2 maanden gaan we een deel van de nieuwe architectuur bouwen, zodat we volgend jaar helemaal over zijn naar een nieuwe hoster. Aan iedere milestone hebben we ook alle bekende issues gehangen. Daarmee lossen we ook een hoop bestaande problemen op.

Milestones 1 - 6
6 milestones

Doel

Over een jaar is jodiBooks weer een stuk volwassener geworden en klaar voor de toekomst. Daarmee kunnen we verder bouwen aan onze droom: ervoor zorgen dat iedereen meer vrijheid heeft. We beginnen met de vrijheid van gedoe met computers, techniek en financiën.

Deze verbouwing en verhuizing gaat onvermijdelijk wat overlast geven. We zullen onvermijdelijk een keer een foutje (bug) maken en een verhuizing kan betekenen dat de website even niet bereikbaar is. We gaan ons stinkende best doen om ervoor te zorgen dat jij er als klant zo min mogelijk van merkt. En wat er ook gebeurt, wij willen gedoe voor onze klanten absoluut vermijden.

Leave a Reply