Follow Us on Twitter

Microservices Architectuur: wat maakt MSA anders dan SOA?

Maart 2017 - Microservices Architectuur (MSA) komt steeds vaker in beeld bij organisaties als oplossing voor problemen waar eerder Service Oriented Architecture naar voren werd geschoven. Met dit Whitebook geef ik een antwoord op de vraag “Wat maakt Microservices Architecture anders dan Service Oriented Architecture?”

Om tot een antwoord te komen moeten we eerst het ontstaan van de twee kort beschrijven.

Service Oriented Architecture

Service Oriented Architecture, of kortweg SOA, is een stijl van software architectuur waarbij een monolithische applicatie, in de grootte van een ERP, wordt opgedeeld in losse delen, de services. Elke service heeft een taak (business activiteit), bijvoorbeeld het verwerken van data, het orkestreren van data uit verschillende bronnen of het tonen van de data aan de gebruiker via een UI.

Er is een mooi manifesto geschreven over SOA (zie SOA Manifesto) over hoe om te gaan met SOA. De kernpunten hieruit zijn:

  • Business waarde gaat boven technologie strategie
  • Strategische doelen gaan boven projectgebonden voordelen
  • Intrinsiek vermogen tot samenwerking gaat boven maatwerk integraties
  • Herbruikbare services gaan boven doel specifieke oplossingen
  • Flexibiliteit gaat boven optimalisatie
  • Evolutionaire verfijning gaat boven het nastreven van initiële perfectie

Alle verschillende services in een organisatie vormen samen een applicatie (of applicatielandschap) waarmee de organisatie kan werken en dat snel uitbreidbaar is in functionaliteit.

De implementatie van SOA wordt veelal gedaan op basis van webservices en queues die de services met elkaar verbinden. Dit is echter niet in beton gegoten als er voor SOA wordt gekozen. Elk protocol voor het ontkoppelen en koppelen mag gebruikt worden volgens de omschrijving van SOA. Daarnaast wordt er vaak gebruikgemaakt van een product/platform/applicatie om de verschillende services aan elkaar te koppelen. Deze zogenoemde orkestratie-applicatie zorgt ervoor dat de verschillende services aan elkaar gekoppeld worden.

Microservices Architectuur

Microservices Architectuur, of kortweg MSA, is een interpretatie van SOA die gericht is op het bouwen van onafhankelijk te installeren services. Elke service heeft net als bij SOA een eigen taak. De filosofie van MSA is gelijk aan die van Unix: “Doe een ding en doe dit goed!”. Dit houdt in dat een (micro)service één taak heeft en deze goed moet uitvoeren. Dat wil zeggen dat een service een stukje presentatie, business logica en data bevat.

Doordat een (micro)service volledig onafhankelijk is, zit er geen restrictie aan de programmeertaal, database hardware of software. Het koppelen gebeurt in de meeste gevallen op basis van een HTTP API in de vorm van REST. (Micro)service maakt geen gebruik van een specifieke applicatie voor het fysiek koppelen van services. Er wordt meestal gebruikgemaakt van een serviceregistratie. Hierin meldt de service zich aan en geeft daarmee aan dat die beschikbaar is om aan te roepen. Een andere service kan via de registratieservice de gegevens ophalen onder welke URL de gewenste service beschikbaar is, zodat de service geraadpleegd kan worden.

Netflix is één van de bedrijven die microservices heeft omarmd. In eerste instantie wilden ze een monitor-/beheerapplicatie ontwikkelen die snel terugkoppeling gaf wanneer er iets mis is met een van de applicaties. Hiervoor ontwikkelden ze bepaalde modules voor Spring Boot om informatie te sturen en te verzamelen van services.

Discovery and Registration

Om te weten waar deze services vandaan kwamen ontwikkelde Netflix een engine voor service discovery en registration. Discovery scant de omgeving af naar services, wanneer een service een bericht ontvangt van de discovery service stuurt deze een bericht terug met gegevens over zijn taak en hoe de service te benaderen is. Hierbij wordt de service geregistreerd. De service stuurt de statusgegevens vervolgens continu door naar de discovery service, zodat die weet dat de service actief is. Verder kan de service bij de discovery aangeven welke informatie ze graag willen ontvangen.

API Gateway

Het derde patroon, de API Gateway patroon zorgt voor de ontkoppeling tussen de cliënt en de services eronder en handelt in deze service eventuele correlatie en security af. Het zorgt ervoor dat de cliënt één contact punt heeft waarbij ze alle informatie die ze nodig hebben kunnen opvragen / ontvangen. Ze communiceren met deze service via één protocol. De gateway zorgt ervoor dat de cliënt geen kennis hoeft te hebben over alle services die in het landschap leven en hoe met ze te communiceren. Verder zorgt de gateway er daarmee voor dat het achterlandschap daarmee beschermd is van aanvallen van buitenaf.

Wat is nu het grote verschil?

MSA is gelijk aan SOA maar SOA is niet gelijk aan MSA. Hetgeen wat het verschil maakt zijn de extra handvaten die MSA met zich meebrengt en waar SOA de vrijheid in heeft gegeven.

Toen SOA voor het eerst in de IT wereld verscheen als opvolger van EAI (Enterprise Application Integration) gingen veel grote bedrijven met deze architectuur aan de slag en daardoor ook de grote leveranciers zoals Progress, Oracle, Microsoft maar ook open source leveranciers als MuleSoft, WSO2 en Apache. Doordat SOA niet beschreven heeft wat een service is en hoe deze moet communiceren met andere services, kwamen bijna alle leveranciers met een ESB (Enterprise Service Bus). Deze applicatie werd gebruikt voor de communicatie tussen de verschillende services. En veel bedrijven koppelden verschillende applicaties met elkaar door elkaar berichten te sturen of services uit te vragen.

Om het geheel iets meer structuur te geven werd er gebruikgemaakt van het SOA maturiteit model (lees ook dit). Daarin werd aangegeven waaraan voldaan moet worden om het ideale SOA landschap als oplossing te hebben. Veel bedrijven komen met hun oplossing eigenlijk niet verder dan level 2 met de tools en producten die op de markt worden aangeboden.

Naarmate de tijd verstreek kwamen er steeds meer leveranciers op de markt en werden de eerste projecten meetbaar met deze nieuwe architectuur. Zo kwamen er meer business gerichte oplossingen, waarin methodieken als BPM en BPMN in tools en producten werden aangeboden. En werd er door andere leveranciers meer ingezet op governance van services m.b.v. service registratiesystemen.

Vanuit de praktijk kwam meer naar voren dat het ontwikkelen van services en het uitwisselen van de berichten tussen deze services toch langzamer gaat dan verwacht. Services worden veelal ontsloten met behulp van complexe servicecontracten. Hoe meer samengestelde services er werden gebouwd op dit servicecontract hoe minder flexibel dit contract veranderd kan worden. Verder vallen de prestaties tegen in met name het kunnen opschalen van de services. Services zijn veelal uniek binnen een servicelandschap en bevatten één databron. Het ophalen van de gegevens gebeurt dan ook altijd via deze ene service. Bij het opschalen blijven de services naar deze ene databron verwijzen. De tegenvallende prestaties komt mede doordat veel berichten over de ESB of BPM worden verzonden. In deze applicaties wordt veel gewerkt met transformatietechnieken in de vorm van xslt en xquery. Dit kost meer tijd, vertalen van en naar programmacode, dan standaard applicaties hetgeen ten koste gaat van de prestaties van het geheel. MuleSoft heeft dit probleem opgelost door standaard in hun ESB gebruik te maken van programmacode. Ze hebben hun eigen datamapper geschreven dat gebruikmaakt van deze programmacode, zodat er geen vertaling nodig is.

De microservices architectuur heeft geen centraal product. Services vinden elkaar via een services registratiesysteem. Eenmaal geregistreerd bij de registratieservice heeft de service voldoende informatie om volledig autonoom te draaien. De service weet vervolgens waar die de informatie die hij nodig heeft, kan ontvangen en waar naartoe te verzenden. Veel microservices zijn event-driven en communiceren met elkaar via een publish / subscribe model. Dit zorgt voor een goede ontkoppeling van de services onderling. Informatie wordt uitgewisseld op basis van json, xml of html. Doordat er minder samengestelde services zijn, omdat elke service zijn eigen verantwoordelijkheid met zich meedraagt, voor zowel de business logica, persisteren en presenteren van de data, haalt de service alleen die informatie op, of ontvangt die van andere services die de service op dat moment nodig heeft.

Voordelen MSA

Naast dat een service volledig zijn eigen verantwoordelijkheid draagt biedt microservices nog een aantal patronen aan die ervoor moeten zorgen dat het landschap gezond werkt.

Circuit Breaker
Het circuit breaker patroon zorgt ervoor dat een service zijn eigen status bijhoudt, wanneer een service niet voldoet aan voor gedefinieerde meetwaardes, wordt de service afgesloten en neemt een andere service van hetzelfde type en versie zijn taak over.

API Gateway
API Gateway patroon wordt gebruikt voor het ontsluiten van services tussen derde partijen en het eigenlandschap. Ook wordt dit patroon vaak gebruikt voor het ontsluiten van de front-end. De API Gateway regelt de communicatie naar de verschillende services toe op basis van de informatiebehoefte van de front-end of de derde partij. Verder kan de API Gateway helpen met een stabiel contract met een derde partij.

Opschalen
Doordat de MSA beschrijft dat een service volledig autonoom moet kunnen draaien, volledig ontkoppeld moet zijn en zijn eigen gezondheid moet monitoren hebben verschillende bedrijven software ontwikkeld voor het kunnen beheren en opschalen van de microservices. Deze applicaties zorgen ervoor dat MSA optimaal draait. Dit houdt in dat ze extra instanties van services opstarten, wanneer andere instanties van de service het erg druk hebben en stoppen wanneer het rustig is. Het stoppen wordt gedaan om CPU en geheugen vrij te houden op de beschikbare services. Dit heeft ook als bijkomstigheid dat in de Cloud, waarin betaald wordt per CPU cycle en geheugen, hiermee geld wordt bespaard. Ze zorgen voor een dashboard waarin alle services worden getoond en de status van de microservices kunnen worden opgevraagd. Er zijn ook leveranciers die de complete communicatie tussen de services kunnen tonen. Verder zorgen ze voor een centrale plek van de configuratie van een service voor die omgeving. Voorbeelden van applicaties die dit verzorgen zijn Docker Swarm, Kubernetes en Mesos.

Nadelen MSA

Het grote nadeel van MSA is de complexiteit van het bouwen van services die voldoen aan de status volledig autonoom. Dit is niet complex, wanneer er maar één instantie van een service hoeft te functioneren. Het wordt pas complex wanneer de service opgeschaald moet gaan worden. Er moet dan rekening worden gehouden hoe de services die als taak hebben het opslaan van gegevens dit niet op slaan in dezelfde databron. Elke service moet namelijk zijn eigen databron hebben. Services die informatiebehoefte hebben willen dit niet verspreid ophalen bij verschillende services. MSA stelt voor om in plaats van gegevens op te halen, de gegevens éénmalig bij alle services op te vragen en daarna te abonneren op mutaties. Het gaat hierbij om services die veel data nodig hebben om zijn taak uit te voeren. Wanneer de services slechts een enkel gegeven van de services nodig heeft dan zet de service een vraag uit waarop één van de services die dat gegeven beheert antwoord geeft.

Conclusie

MSA is een uitbreiding op SOA, waarin kaders en patronen zijn vastgelegd die helpen bij de problemen die bij veel SOA implementaties naar voren zijn gekomen. SOA heeft ten opzichte van MSA maar een aantal kaders gesteld als het gaat om hoe een service zich moet gedragen. MSA heeft deze kaders aangescherpt met een aantal extra regels. Deze regels zorgen ervoor dat de kwaliteit en de prestatie van de services continu gemonitord worden. Wanneer een service niet voldoet aan de kwaliteit, die gevraagd wordt van de service wordt deze afgesloten en vervolgens neemt een andere service van hetzelfde type en dezelfde versie zijn taken over. Ook wanneer een bepaalde service het te druk krijgt wordt deze service opgeschaald door een service van dezelfde instantie en versie op te starten. Om zo de drukte te kunnen verdelen over meerdere services.

Referenties

Er is veel te lezen over MSA. Een aantal interessante artikelen:

Waardering:
 
Tags:

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.