Als je de term ‘SOA’ hoort, dan denk ik niet dat je dit in eerste instantie met ‘voordeel’ associeert. Laten we eerlijk wezen… Gelukkig gaan we het niet over overdraagbare aandoeningen hebben, maar over een Service-Oriented Architecture. En ik kan je vertellen, daar zitten behoorlijk wat voordelen aan! Lees alles over architecturen, monolieten en services.
Mijn Antagonist – de monoliet
Op het moment van schrijven is Mijn Antagonist als monoliet ontworpen. Dat wil zeggen dat één applicatie alles doet. Wat is alles in deze context? Nou, Mijn Antagonist is verantwoordelijk voor de functionaliteit die je als klant ziet. Denk aan het beheren van producten, DNS-records en e-mailforwarders, maar ook aan het afhandelen van bestellingen en verlengingen.
Dat is nog lang niet alles. Zo gebruikt Support het systeem om informatie over klanten en hun producten op te zoeken. Daarnaast wordt Mijn Antagonist voor een (deel van) de boekhouding gebruikt. Ook achter de schermen is het druk bezig. Daar is het verantwoordelijk voor het opleveren van hostingpakketten (provisioning) en het registreren van domeinen.
Al deze functionaliteit (en veel meer) is samengevoegd in één grote applicatie, Mijn Antagonist. Deze opbouw wordt een monoliet genoemd. Het grootste voordeel voor ons is dat het makkelijk te onderhouden is. Als ontwikkelaar hoeven wij immers maar één applicatie te onderhouden. Is er een nieuwe versie, dan installeren we die op onze servers en zijn we klaar.
Het takensysteem van Mijn Antagonist
Zoals altijd, zijn er natuurlijk ook een aantal grote nadelen… Laten we naar een voorbeeld kijken. Dat is de makkelijkste manier om het grootste nadeel van de huidige opbouw van Mijn Antagonist duidelijk te maken.
Neem het takensysteem. Veel van de dingen die Mijn Antagonist doet, worden op de achtergrond uitgevoerd. Als je bijvoorbeeld een domein bestelt, dan worden er op de achtergrond een aantal taken gestart om de registratie uit te voeren en de standaard DNS-records voor het nieuwe domein in te stellen.
Deze taken voeren we op de achtergrond uit, zodat je er als gebruiker in je browser niet op hoeft te wachten. Daarnaast is het zo een stuk gemakkelijker om discrete stukjes van het registratieproces opnieuw te proberen, mochten er daar problemen optreden. Klinkt goed, maar nu wordt het lastiger…
Voor de taken die Mijn Antagonist uitvoert, hebben we namelijk verschillende eisen. Zo moeten sommige taken exact één keer uitgevoerd worden, zoals betalingen. Er zitten ook taken bij die zo snel mogelijk moeten gebeuren en weer andere moeten meerdere keren veilig kunnen worden uitgevoerd. Het is behoorlijk ingewikkeld om aan al deze eisen te voldoen. We hebben namelijk één takensysteem dat ook van één database gebruikmaakt.
Service-Oriented Architecture
Hier is gelukkig een oplossing voor. Een Service-Oriented Architecture is een methode om een grote applicatie op te bouwen. Hierbij splits je de applicatie op in meerdere logische onderdelen, services genoemd. Iedere service is dan verantwoordelijk voor een specifiek stukje functionaliteit.
Voor bijvoorbeeld Mijn Antagonist zouden we losse services kunnen maken om bestellingen te verwerken, betalingen af te handelen, domeinnamen te registreren en hostingpakketten op te leveren. Deze services samen vormen de totale applicatie. Qua functionaliteit verandert er niet per se iets, maar de architectuur wordt wél anders.
Adem jij code en automatiseer je alles wat op je pad komt? Is niet Spaans, maar Python je tweede taal? Kom werken bij Antagonist!
Contractuele obligaties
De services moeten met elkaar kunnen samenwerken. Zodoende maak je afspraken over de manier waarop de service opdrachten accepteert. Deze afspraken leggen we vast in een contract. Daarin staat precies beschreven welke informatie de service nodig heeft om een bepaalde functie uit te voeren.
Het is belangrijk dat er in het contract goed wordt vastgelegd hoe de service wordt aangesproken. Wat je niet vastlegt, is hoe de service zijn werk doet. Dit is een beetje vergelijkbaar met biefstuk bestellen in een restaurant. Jij geeft aan dat je het medium rare wilt. Hoe de keuken het dan precies bereidt, is niet zo belangrijk. Het gaat om het eindresultaat.
De Service-Oriented Architecture geeft op deze manier een abstractie. Als je van een service gebruik wilt maken, hoef je niet over de implementatie na te denken. Je denkt alleen na over de randvoorwaarden voor het gebruik en het eindresultaat. Dit maakt het een stuk gemakkelijker om na te denken over hoe services elkaar gebruiken. Tegelijkertijd zorgt deze constructie ervoor dat je makkelijker de interne werking van een service kunt aanpassen, zonder dat de services die ervan afhankelijk zijn iets hoeven aan te passen.
Gemakkelijk wisselen
Laten we als voorbeeld naar een service kijken die betalingen uitvoert. Doe je een betaling met een creditcard, dan stuur je een opdracht naar deze service om een betaling uit te voeren bij onze creditcardprovider. De gegevens van de kaart en het bedrag stuur je mee. De service voert ten slotte de betaling uit en koppelt het resultaat terug.
Wat als we nu naar een andere provider willen overstappen? Geen probleem, we passen dan de interne werking van de service aan om een andere provider te gebruiken. De randvoorwaarden en het eindresultaat blijven exact gelijk. Zo hoeven we de andere services dus niet aan te passen.
Keuzes, keuzes, keuzes…
Een groot voordeel van een Service-Oriented Architecture is dat we per services keuzes kunnen maken over de technologie die we gebruiken. Nu gebruiken we voor Mijn Antagonist bijvoorbeeld MySQL, memcached en een eigengebouwd takensysteem. Daar gelden deze keuzes voor alle onderdelen van Mijn Antagonist, omdat we met een monoliet te maken hebben.
Door de applicatie in losse services op te delen, kunnen we per service de set technologieën kiezen die er het beste bij aansluiten. Eerder noemde ik al het takensysteem. In een SOA zouden we specifiek voor de betalingsservice een takensysteem kunnen kiezen, dat de garantie biedt dat taken exact één keer uitgevoerd worden. Voor andere services is Redis misschien wel beter dan memcached. En wellicht zijn er services die geen database nodig hebben.
Betere schaalbaarheid
Soms doen we een actie, waarbij we fikse korting op bepaalde domeinnamen geven. Erg prettig voor klanten natuurlijk, maar soms behoorlijk stressvol voor ons ontwikkelaars. Wij moeten ervoor zorgen dat Mijn Antagonist goed blijft werken en alle bestellingen goed verwerkt worden.
Dat betekent soms dat we de capaciteit van Mijn Antagonist moeten verhogen. Op dit moment is dat een beetje log. Als we merken dat de server het zwaar heeft, kunnen we een extra server inzetten met een complete installatie van Mijn Antagonist. Dat werkt op zich prima, maar het is een beetje omslachtig.
Door de applicatie in services onder te delen, kunnen we individuele services opschalen. In het geval van een actie waarbij we veel domeinen registreren, kunnen we bijvoorbeeld een extra server (of virtual machine) inzetten die alleen de domeinservice draait. Op deze manier kunnen we heel gericht schalen. Dat leidt tot betere performance, maar ook voor beter gebruik van de middelen die we ter beschikking hebben.
Van monoliet naar SOA?
Op dit moment is Mijn Antagonist min of meer een monoliet. We willen echter graag de besproken architectuur breder inzetten. Door het in services op te splitsen, kunnen we keuzes maken die heel goed bij het gebruikspatroon van een service aansluiten. Dat scheelt ons veel werk en onderhoud, maar bovenal verkleint het de kans op bugs.
Zoals je misschien kunt voorstellen, is dat een behoorlijk omvangrijk project. Gelukkig kan dit stapsgewijs. Zo kunnen we voor specifieke onderdelen van de applicatie een service maken en die gaan gebruiken. Op die manier is het mogelijk om langzaamaan de overstap te maken. Hopelijk is nu in ieder geval duidelijk dat een SOA soms dus ook voordelen heeft… 😉
P.S. Op de hoogte blijven van alle artikelen, updates, tips en trucs die op ons blog verschijnen? Volg ons via Facebook, Twitter, Instagram, RSS en e-mail!
