+31 (0)20 716 3866 +31 (0)85 888 11 33 info@enable-u.com
Micro

Microservices: snelheid versus complexiteit?

Organisaties zullen steeds sneller moeten reageren op veranderende klantbehoeften. Gedreven door deze noodzaak zien we dat organisaties veelal DevOps omarmen, die gericht zijn op het snel en betrouwbaar ontwikkelen en in productie nemen van software door middel van Continuous Delivery (CD). Met CD kunnen teams -door gebruik te maken van zoveel mogelijk automatisering- in korte cycli software ontwikkelen en uitbrengen.  Een microservices architectuur (of gewoon microservices) is een methode voor het ontwikkelen van softwaresystemen.

De software-applicatie wordt als microservice samengesteld uit losse, autonome modules (services) met één functie en een duidelijk gedefinieerde interface. De afzonderlijke DevOps teams die deze modules of microservices ontwikkelen en beheren verkrijgen zo vrijheid van keuze wat betreft de technologie. Bovendien kunnen ze door Continuous Delivery snel nieuwe wijzigingen uitbrengen. Deze verhoging van snelheid en flexibiliteit is een heel belangrijk voordeel ten opzichte van huidige methoden, waarbij een applicatie als één enkele eenheid wordt ontwikkeld en getest en waarbij iedere wijziging het hele systeem beïnvloedt.

 

Microservices en het verleden

Het idee van het modulair opbouwen van applicaties op basis van standaard herbruikbare bouwstenen (services) is niet nieuw. In feite zijn er de afgelopen dertig jaar meerdere architectuurvormen en methodes ontwikkeld. Denk bijvoorbeeld aan RMI (Remote Method Invocation), EJB (Enterprice Java Beans), JCA (Java Container Architecture), Service Oriënted Architecture (SOA) en API’s/API Management.

De voordelen die worden genoemd in relatie tot microservices zoals schaalbaarheid, herbruikbaarheid en modulariteit, zijn we in deze vorige architecturen al eerder tegengekomen. Ook bij Web Services in de SOA-wereld is er vrijheid van technologie keuzes.
In die zin lijken microservices niets anders dan een herhaling van zetten.

Waarom dan nu microservices?

Microservices passen in de tendens van DevOps en CD waarin vergroting van de flexibiliteit en snelheid van applicatieontwikkeling via diverse, parallelle teams nieuwe applicaties kan worden bereikt. Bovendien zijn microservices, zoals de naam het al zegt, functioneel gezien veel kleiner en fijnmaziger. Elke microservice wordt als container uitgevoerd en geïmplementeerd. Met andere woorden; microservices zijn de bouwstenen voor hedendaagse toepassingen.

Er zijn ook nadelen aan microservices en deze liggen met name op het vlak van governance. Ook dit is niet nieuw. Governance was en is een pijnlijk dossier bij iedere organisatie die hun SOA architectuur veelal op basis van (SOAP) Web Services hebben ingericht. Het blijkt in de praktijk heel moeilijk om inzicht te krijgen in de services die er al zijn, de onderlinge relaties van die services (wie welke service gebruikt) en de afspraken die gemaakt worden wat betreft release management, versiebeheer enzovoorts. Ondanks het gebruik van SOA Governance tools (repositories, registries) blijft het bijhouden vaak een tijdrovend en vervelend handmatig proces, waardoor SOA repository’s vaker niet dan wel een actuele situatie weergeven. En als het aantal services toeneemt wordt dit probleem alleen maar vergroot. Het resultaat is onvoldoende overzicht en gebrek aan grip op het services landschap. Kortom we kunnen concluderen dat SOA Governance in de huidige vorm niet heeft gewerkt.

Bij microservices -waar de aantallen services nóg veel groter zijn- is een goede governance essentieel.
In onderstaand voorbeeld wordt dit door middel van een eenvoudige rekensom goed uitgelicht:

 

Microservice A, gebouwd en onderhouden door DevOps team A wordt gebruikt door 5 microservices waarvan ieder een eigen team heeft.

Vraag: Hoe weten we welke microservices er zijn en wie er uit welk team verantwoordelijk voor is?  Hoe houden we dit bij als er zoveel aparte teams
los van elkaar aan microservices werken?

Stel dat microservice A door team A gewijzigd wordt.
Hoe weten we dat de 5 consumerende microservices worden beïnvloed?
En daaraan gerelateerd: moeten deze 5 microservices dan ook getest worden bij iedere wijziging van microservice A? Hoe worden de teams geïnformeerd?

Stel dat microservice A wordt uit gefaseerd voor een compleet nieuwe service.
Geven we de gebruikers (de teams die verantwoordelijk zijn voor de 5 microservices) dan de tijd om te migreren? En voor hoe lang? Wat doen we als deze periode verstrijkt en er nog steeds microservices (bijv. 2 van de 5) zijn die er gebruik van maken?
Hoe weten we überhaupt dat er nog microservices zijn die nog van microservice A gebruik maken?

 Door de grote aantallen microservices en de hoge frequentie van wijzigingen is een geautomatiseerd release-proces essentieel. Continuous Delivery doet dit. Maar met CD is de governance problematiek nog niet opgelost. Immers, technische beperkingen kunnen ook een rol spelen. De extra vertraging die het communiceren via het netwerk tussen microservices oplevert bijvoorbeeld, kan voor applicaties onacceptabel zijn.

 

Service Mesh de nieuwe ESB?

Net als toendertijd bij SOA en API Management, vormt zich ook rond de problematiek van Microservices een nieuw ecosysteem van bedrijven die oplossingen bieden. Bijvoorbeeld
start-up’s die de toename van complexiteit en (deels) de governance-problematiek op willen lossen door de introductie van een Service Mesh. Omdat de Service Mesh -als infrastructuur-laag voor een microservices applicatie- zorgt voor de communicatie tussen service-instanties,
vormt deze een bepalende factor voor het gedrag van een applicatie.

De service mesh maakt gebruik van proxies. Elke microservice wordt samengevoegd en gekoppeld aan een proxy. Deze proxy, ook wel sidecar genoemd, handelt voor de microservice alle inter-service communicatie, monitoring en security af. Zo kunnen de ontwikkelaars zich uitsluitend richten op ontwikkeling, ondersteuning en het onderhoud van de applicatie code. Dit laatste is niet nieuw, deze argumenten worden ook gebruikt voor de inzet keuze van een ESB of API Management oplossing.

De service instanties, sidecar proxies, en de communicatie hiertussen worden de data plane van een service mesh applicatie genoemd. De control plane is de service mesh applicatie die de monitoring- en beheerlaag bevat. Het zorgt voor het creëren en afsluiten van service instanties. Via de control plane kunnen applicatie brede policies worden geïmplementeerd.

Er zijn veel overeenkomsten met een ESB, als het aankomt op beheer en beveiliging van de communicatie tussen services.  Het is niet vreemd dat ESB en API Management leveranciers met een vereenvoudigde versie van hun gateway oplossing komen die ze als microservice proxies positioneren. Het grote verschil is echter dat een Service Mesh is geoptimaliseerd voor applicaties die uit microservices bestaan. De overhead is geminimaliseerd en gedistribueerd.

De service mesh maakt gebruik van container gebaseerde architectuur. Naast container management is de service mesh een extra laag van complexiteit dat wordt toegevoegd.

Leveranciers van Service Mesh oplossingen (zoals Kong, Istio)  bieden auto discovery mogelijkheden om de microservices in kaart te brengen in een register. In mijn optiek is dit nog maar het begin, het is vooral belangrijk om te weten wie (mircoservice, applicatie) welke microservice aanroept.  De ontdekte microservices en hun relaties worden automatisch in een service register als onderdeel van de control plane opgeslagen. Auto discovery in combinatie met een service register is niet voldoende. Ook auto depency mapping is noodzakelijk waarbij niet alleen de aanroepende service maar ook de aanroepende velden in kaart worden gebracht. Dit laatste is noodzakelijk om te bepalen of een versie verandering de aanroepende microservices en applicatie beïnvloed. Deze informatie is essentieel wanneer deze microservice moet worden getest (zie voorbeeld). Daarbij zal in mijn optiek ook geavanceerde machine learning en kunstmatige intelligentie (AI) nodig zijn om de governance nog verder te verbeteren bijvoorbeeld door auto-discovery ook auto-mapping toe te passen waarbij microservices automatisch aan elkaar worden gekoppeld. Ook op het gebied van beveiliging helpt machine learning en kunstmatige intelligentie bijvoorbeeld om proactieve afwijkend verkeer te identificeren om te voorkomen dat bedreigingen zich verspreiden bijvoorbeeld.

Dit alles zonder menselijke tussenkomst. Op dit vlak is nog veel ontwikkeling gaande, maar wel noodzakelijk voor grootschalige microservice adoptie.

 

Conclusie

Microservices hebben heel veel voordelen maar zorgt ook voor een enorme toename van complexiteit. De industrie komt met nieuwe, geavanceerde technologische oplossingen waarin governance zoveel mogelijk wordt geautomatiseerd. Deze automatisering is noodzakelijk voor grootschalige inzet van microservices. Mijn advies is om pas grootschalig met microservices te starten als de governance problematiek is opgelost en de vragen in het scenario van het bovenstaande voorbeeld compleet, of in ieder geval zo veel mogelijk door automatisering worden beantwoord.