Blog

Hoe ontwerp je een schaalbare digitale dienst?

Auteur Ruud van Vliet Ruud is infomatiekundig ontwerper en ontwikkelaar bij Trivento.

Bij het ontwerpen van schaalbare digitale diensten denk je al snel dat het een IT aangelegenheid is. IT speelt zeker een belangrijke rol, maar samenwerken met de business is minstens zo belangrijk. Ik beperk me in deze blog tot schaalbaarheid, wetende dat er andere aspecten - zoals de gebruikerservaring (UX) - minstens zo bepalend zijn voor het succes van een dienst. Voordat ik tot mijn punt kom geef ik wat context, waarvan ik vind dat die van toepassing is.

Wat is schaalbaarheid eigenlijk?

Wikipedia geeft de volgende definitie van schaalbaarheid: “de mogelijkheid om een configuratie eenvoudig groter [of kleiner] te maken”. Wanneer we het hebben over het schaalbaar maken van een digitale dienst, gaat het erom dat de dienst gemakkelijk meer of minder capaciteit aan kan. Denk daarbij aan gelijktijdige gebruikers, de hoeveelheid data of het aantal aanvragen die het systeem verwerkt.

Software verticaal of horizontaal schaalbaar maken

Eerst wat theorie over het schaalbaar maken van software. Daarin worden 2 fundamenteel verschillende benaderingen onderscheiden: verticaal versus horizontaal.

Verticaal schaalbaar maken van software komt er op neer dat je feitelijk snellere hardware gebruikt, zonder dat je de gebruikte applicatie wezenlijk verandert. Je kunt onderdelen van de applicatie op andere hardware plaatsen, maar in wezen is er maar 1 versie van je applicatie. Dat maakt verticaal schalen eindig. Als je de snelste hardware hebt die te koop is, dan is verder opschalen op een gegeven moment niet meer mogelijk.

Bij horizontaal schalen zet je meerdere versies van je applicatie náást elkaar. Daarom heet het ook horizontaal schalen. En het is duidelijk dat horizontaal schalen tot in het oneindige kan. Maar er is 1 probleem: stel je hebt een webshop waarop een klant logt inlogt. De vraag is bij welke versie van je applicatie die klant zich moet melden Als alle applicaties alle klanten moeten kennen heb je een punt waarop er niet echt effectief horizontaal geschaald wordt.

Reactive Manifesto

Er zijn meerdere oplossingsrichtingen voor het schaalbaarder maken van applicaties denkbaar. Ik ga in dit blog in op de principes volgens het 'Reactive Manifesto':

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

Naast schaalbaarheid gaat het Reactive Manifesto ook over Responsiveness en Resilience. Het systeem geeft altijd antwoord, ook al is dat antwoord het equivalent van 'sorry, ik weet het even niet'. En het systeem doet z'n best om het op dat moment best mogelijke antwoord te geven, ook als is dat op basis van bijvoorbeeld verouderde data.

De essentie van het Reactive Manifesto is dat je je systeem indeelt in kleine deel applicaties, voor het gemak: microservices. Microservices kunnen afzonderlijk van elkaar hun werk doen en met elkaar communiceren, zonder te wachten tot er een antwoord komt. Eigenlijk zoals het sturen van een email of een appje: je verstuurt het bericht en gaat gewoon weer door met waar je mee bezig was ...

Door het communiceren zonder te wachten, 'asynchronous message-passing' in het jargon, wordt de applicatie horizontaal schaalbaar ...

Begrijp hoe microservices samenwerken

Het punt dat ik wil maken: als business moet je de opdeling in die microservices begrijpen. De namen van die services moeten ook voor niet IT-ers te begrijpen zijn. De manier waarop ze samenwerken om tot het gewenste resultaat te komen moet navolgbaar zijn. De taal die wordt gehanteerd moet afkomstig zijn van het business domein.

Wanneer je een applicatie door microservices in kleine stukjes opdeelt, neemt de complexiteit toe. Soms blijkt zo'n microservice toch nog een bottleneck en moet dus worden opgesplitst. Soms moet, door nieuwe functionaliteit, een verantwoordelijkheid van de ene microservice verhuizen naar een andere. Om de complexiteit beheersbaar te houden is het van belang dat de indeling voor alle betrokken partijen duidelijk is. Dat iedereen ‘dezelfde taal’ spreekt. Juist door vanuit de verschillende invalshoeken te kijken, en de eventuele conflicten bespreekbaar te maken, ontstaat een ontwerp dat beter bestand is tegen wijzigingen en uitbreidingen.

De moraal van het verhaal is is dat je als business partner altijd betrokken blijft bij de indeling, die voor een applicatie wordt gekozen. Je hoeft het niet allemaal zelf te verzinnen, maar zorg dat je je systemen blijft begrijpen.

 

Dit artikel delen?