In de natuur is groter niet altijd beter. Een grote witte haai kan dan wel de plaag van de oceanen zijn, maar er zijn vele gevallen waarin een school vissen beter in staat is om als groep te overleven en te gedijen dan welk ander organisme ook. Succes door samenwerking is eigenlijk in het hele dierenrijk een algemeen thema; mierenkolonies, bijenkorven, wolvenroedels enz. doen allemaal hun voordeel bij het werken in op losse wijze verbonden systemen, om de controle te verdelen en gemeenschappelijke doelen te bereiken. En als er één lid van de kolonie, de bijenkorf of de roedel omkomt, kan de rest van de groep blijven functioneren en het verlies goed maken.
Microservices werken volgens deze aanpak, en passen hem toe op softwareontwikkeling en systeemarchitectuur. Het idee is dat het vaak sneller, gemakkelijker, veiliger en efficiënter is om een aantal componentfuncties of -services afzonderlijk op te bouwen, dan om dezelfde functionaliteit in een zelfstandig en volledig onderling verbonden systeem te installeren. We nemen hier de microservices en hun kenmerken, voordelen en uitdagingen onder de loep.
Misschien is de beste benadering om te begrijpen wat microservices zijn, te beginnen met het identificeren van wat microservices niet zijn. Er zijn een aantal verschillen tussen microservices en andere organisatorische benaderingen. Hier vergelijken we microservices met de traditionele monolithische architectuur, en met de recentere service-oriented architecture (SOA).
Zoals de naam al suggereert, zijn monolieten grote, uniforme toepassingen waarbij elke component grotendeels onderling verbonden is en afhankelijk is van naburige componenten. Monolieten zijn de traditionele benadering van ontwikkeling, waarbij alle functies op één plek worden beheerd en bediend, en alles op één codebasis is gebaseerd. Elke verandering die ontwikkelaars in monolithische structuren willen doorvoeren zal natuurlijk verandering brengen in de hele stack. Activiteiten zoals test worden ook uitgevoerd op de hele stack, en wijzigingen worden dus gegroepeerd in grote releases die van begin tot einde relatief lang kunnen duren. Microservices onderscheiden zich van monolieten, omdat ze bestaan uit een aantal kleinere, zelfstandige, op losse wijze samengevoegde componenten. Wijzigingen kunnen worden geïmplementeerd op de afzonderlijke componenten zonder dat dit gevolgen heeft voor andere services binnen de toepassing.
Het onderscheid tussen microservices en SOA is subtieler. Hoewel beide componenten afhankelijk zijn van herbruikbare componenten die modulair worden toegepast op verschillende toepassingen kunnen worden toegepast, is SOA echter lang niet zo granulair. Terwijl microservices zodanig containergebaseerd zijn dat elke service slechts één functie uitvoert, kan elke SOA-component een compleet subsysteem zijn dat verantwoordelijk is voor een reeks bedrijfsfuncties. Bovendien optimaliseert SOA het delen van componenten en de afhankelijkheden, terwijl microservices gewoon proberen deze aspecten zoveel mogelijk te minimaliseren.
Microservices hebben doorgaans de volgende kenmerken:
Omdat microservices zijn ontworpen als een verzameling individuele, onafhankelijke services, kunnen ze eenvoudig worden getest als standalone componenten. Problemen binnen de componenten kunnen snel worden geïsoleerd, zodat geen hele systemen en toepassingen moeten worden test, en vervolgens grote hoeveelheden tijd moet worden besteed aan pogingen om specifieke storingen te isoleren.
Om een samenwerking mogelijk te maken, moet de onderlinge verbondenheid tussen microservices worden gehandhaafd. Dit is in wezen een losse verbinding, waarbij veranderingen die in de ene service worden geïmplementeerd geen directe invloed hebben op andere services.
In plaats van gegevensopslag te delen tussen services, behoudt elke component zijn eigen gegevensopslag. Dit helpt het onbedoeld koppelen van verschillende services voorkomen, en zorgt ervoor dat veranderingen geen ongewenst effect hebben op andere onafhankelijke services.
Individuele services worden veranderd en in de productieomgeving ingezet zonder dat er andere services moeten worden gebruikt. Alle implementaties binnen het systeem worden op deze manier beheerd, zodat het verbeteren van een microservice zeer snel kan verlopen.
Microservices maakt gebruik van multidisciplinaire teams, die zijn georganiseerd rond één enkel bedrijfsdoel. Deze teams bestaan vaak uit ontwikkelaars, database-engineers, testers, infrastructuurengineers en anderen, en hebben als doel het ontwikkelen van specifieke producten op basis van meerdere onafhankelijke services.
In microservices is elke onafhankelijke service in staat om verzoeken te ontvangen, te verwerken en te beantwoorden. Dit is een aanzienlijke vereenvoudiging in vergelijking met vele van de traditionelere systemen, waarin complexe lagen van routerings- en bedrijfsregeltoepassingen het proces uiteindelijk kunnen vertragen.
Opdat een microservicesysteem volledig uitvalt, moeten in wezen alle onafhankelijke services tegelijkertijd uitvallen. De systemen zijn gebaseerd op los verbonden services, en daarom kan een systeem zelfs bij een storing in een van zijn services met een bijna optimale capaciteit blijven werken. Omdat de diensten gedecentraliseerd zijn, zou het verlies van één service weinig tot geen invloed mogen hebben op de naburige services.
Omdat microservices modulair van aard zijn, is het relatief eenvoudig om indien nodig nieuwe services toe te voegen. Zo wordt het voor organisaties mogelijk om de huidige systemen aan te passen aan nieuwe toepassingen, en systemen op of af te schalen om aan een veranderende vraag te voldoen.
Bij het ontwikkelen van een nieuwe service hebben organisaties de vrijheid om te kiezen uit verschillende technologische stacks. Tegelijkertijd kunnen nieuwe technologische stacks ook worden gebruikt bij het aanbrengen van wijzigingen in bestaande services.
De modulaire, containergebaseerde aanpak die wordt gebruikt bij de ontwikkeling van microservices zorgt ervoor dat het een natuurlijke partner is van zowel DevOps als van de continue integratie/continue levering (CI/CD). Omdat elke service als eigen eenheid wordt benaderd, kunnen meerdere teams afzonderlijk werken om gelijktijdig functionaliteit te ontwikkelen, via de toepassing van DevOps-principes en de snelle doorvoer van projecten door de CI/CD-pipelines.
Hoewel microservices rechtstreeks met elkaar kunnen communiceren, geven veel bedrijven er de voorkeur aan de integratie van API-gateways om te fungeren als tussenliggende lagen om verzoeken te helpen routeren, extra verificatie te bieden en de beveiliging te verbeteren. API-communicatie kan bijzonder effectief zijn wanneer microservices eerst de status bepalen.
Microservices zijn een verandering van de traditionele ontwikkelingsarchitectuur, die een aantal voordelen bieden in vergelijking met meer conventionele organisatorische benaderingen. Deze voordelen zijn onder meer:
Microservices stellen kleine, onafhankelijke teams in staat om binnen duidelijk gedefinieerde contexten te op te treden. Hierdoor kunnen ze in minder tijd meer verwezenlijken, en met een grotere flexibiliteit reageren op onverwachte veranderingen.
Microservices splitsen complexe toepassingen en systemen op in kleinere, eenvoudigere componenten. Ontwikkelaars kunnen gemakkelijker een onderscheid zien tussen services en de nodige updates en verbeteringen aanbrengen.
Ontwikkelaars zijn niet langer beperkt tot een enkele taal of technologische stack, maar hebben de vrijheid om de beste oplossingen, tools of resources te selecteren voor elke individuele functie, zonder dat ze zich zorgen hoeven te maken over de communicatie tussen de betrokken services.
Omdat op microservices gebaseerde toepassingen zeer modulair zijn, kunnen ze met relatief gemak worden ontwikkeld en ingezet. Teams kunnen zich coördineren om gelijktijdig te werken aan individuele, kleine componenten, en elke component kan onafhankelijk worden ingezet.
In de traditionele toepassingsarchitectuur betekent het voldoen aan de veranderende vraag vaak het schalen van de gehele toepassing. Microservices stellen ontwikkelaars in staat om resources om te leiden naar het schalen van alleen de toepasselijke services en componenten, waardoor de schaalsnelheid wordt verbeterd en de bijbehorende kosten worden verlaagd.
In het geval dat één microservice uitvalt, blijven de naburige microdiensten onaangetast. Dit betekent dat op microservices gebaseerde toepassingen gewoonlijk niet crashen; als een of meer componenten uitvallen, blijft de toepassing zelf werken met verminderde functionaliteit totdat de betrokken service kan worden gerepareerd.
Omdat elke service zelfstandig is en is ontworpen om onafhankelijk een specifieke functie uit te voeren, kunnen ontwikkelaars services hergebruiken en recyclen voor gebruik in een aantal verschillende toepassingen. Componenten kunnen functioneren als ‘bouwstenen’, waardoor de noodzaak om voor elk nieuw project volledig nieuwe codes te creëren aanzienlijk wordt gereduceerd.
De verbeterde flexibiliteit, de grotere herbruikbaarheid en vereenvoudigde implementatie bevorderen allemaal kortere ontwikkelingscycli en een snellere time-to-market. Hierdoor kan het bedrijfsrendement worden verbeterd en kan een meer bevredigende gebruikerservaring worden aangeboden.
De voordelen van microservices brengen ook bepaalde problemen met zich mee. Hier bekijken we een aantal moeilijkheden waarmee organisaties kunnen worden geconfronteerd bij het implementeren van een benadering met microservices:
De overstap naar microservices betekent het identificeren en catalogiseren van alle afhankelijkheden tussen de services. Vanwege de afhankelijkheden kan het voltooien van een enkele build direct leiden tot de noodzaak om een aantal andere builds te implementeren, wat frustrerend en tijdrovend kan zijn.
Een sleutelfactor in microservices is dat elke component zijn eigen, geïsoleerde database heeft. Met elke nieuwe database wordt het beheer echter complexer. Hoe meer services en hoe meer databases worden gebruikt, hoe minder handig het is om de gegevens zelf te beheren.
Wanneer toepassingen met behulp van microservices worden bijgewerkt naar nieuwe versies, bestaat de kans dat hierbij de compatibiliteit met eerdere versies wordt aangetast. De oplossingen - bouwen in voorwaardelijke logica of meerdere live versies oprichten voor verschillende klanten - kunnen op het gebied van onderhoud en beheer te complex zijn.
Microservices zijn ontworpen om de implementatie te vereenvoudigen. Maar de complexiteit bij het werken met een groot aantal onafhankelijke componenten kan overweldigend zijn. Automatisering kan dit probleem helpen oplossen.
Registratie kan moeilijk worden wanneer elke service zijn eigen database gebruikt. Het is wellicht noodzakelijk om gecentraliseerde registratieoplossingen te ontwikkelen. Op dezelfde manier kan de monitoring en het beheer van elke service onhaalbaar zijn zonder een gecentraliseerde weergave en één bron van waarheid.
Met mogelijk honderden microservices die in één toepassing zijn opgenomen is traditionele foutopsporing geen optie.
Hoewel de microservice-architectuur teams een behoorlijke mate van onafhankelijkheid biedt, kan voor de oplossing van problemen die op meer dan één service binnen een toepassing betrekking hebben een gedetailleerde communicatie en coördinatie tussen teams vereist zijn.
Omdat toepassingen met microservices gedistribueerde systemen zijn, valt het wel eens voor dat teams onbewust taken dupliceren. Dit kan resulteren in verspilde moeite en inefficiënte toepassingen.
Naast de hierboven aangesneden moeilijkheden zijn er bepaalde valkuilen waar organisaties zich bewust van moeten zijn wanneer ze overwegen om een microservicearchitectuur te implementeren:
Hoewel microservices een zeer populaire benadering van ontwikkelingsarchitectuur zijn, zijn ze over het algemeen het meest geschikt voor het repareren en reviseren van bestaande toepassingen die al te complex en te moeilijk te onderhouden zijn geworden. Ze zijn lang niet zo effectief wanneer ze als uitgangspunt worden gebruikt. Als de traditionele aanpak geen onbeheersbaar niveau heeft bereikt, is het eigenlijk geen monoliet die aan herstructurering toe is.
Net als bij andere zaken kan een service altijd in kleinere delen worden opgedeeld. En hoewel microservices granulair moeten zijn en moeten bestaan uit beperkte functies die zijn ontworpen om een groter geheel te ondersteunen, bestaat de kans dat dit te ver wordt doorgedreven. In plaats daarvan komen vele bedrijven tot de vaststelling dat als ze beginnen met grotere services, die ze daarna pas opsplitsen in microservices wanneer ze traag worden om te implementeren of te complex worden om te beheren, ervoor helpen zorgen dat de oplossing niet in de weg staat van de mogelijke voordelen.
Een groot, gedistribueerd systeem kan gemakkelijk uit de hand lopen. Om de effectiviteit van microservices te garanderen, moeten organisaties een geavanceerde implementatie- en monitoringautomatisering integreren, samen met beheerde cloudservices. Dit kan helpen om een groot deel van de last van de overgang naar microservices te verlichten.
ServiceNow kan u helpen met de beheeraspecten van services die zijn gebouwd met behulp van microservices en door verbinding te maken met de methodologieën en tools die worden gebruikt in de buildfasen, zoals CI/CD en andere DevOps-oplossingen.
Gezien het potentieel voor grote aantallen microservices en de tijdelijke aard ervan biedt ServiceNow opties voor het automatisch invullen van de CMDB en Service Graph, om relaties bij te houden en de definitie van services te behouden. Dit maakt deel uit van ons aanbod van IT Operations Management, dat ook bredere cloudbeheermogelijkheden inhoudt.
Zoals bij elke code die is ontwikkeld met DevOps-praktijken, is snelheid, m.a.w. het bieden van de snelste weg tussen een ontwikkelaar en een productiesysteem, een gemeenschappelijk doel bij het onderhouden van microservices. Grotere of gereguleerde organisaties moeten echter sterke controles behouden op veranderingen, en daarom hebben we in IT Service Management Professional onze DevOps Change Velocity-functie opgenomen, die gekoppeld is aan de CI/CD-pipeline, informatie verzamelt tijdens het ontwikkelingsproces en deze gebruikt naast eerder gedefinieerde beleidsvormen, om het wijzigingsbeheerproces te automatiseren.
Tot slot is ServiceNow een rijke bron van mogelijkheden die door interne en externe toepassingen op een microservice-achtige manier kan worden gebruikt als aanvulling op de ondersteuning van de integratie met externe microservices als onderdeel van de ServiceNow-workflows.
Het Now Platform bevat kernfuncties waarmee u workflows snel en efficiënt kunt digitaliseren en op grote schaal kunt uitvoeren.