Microservices en microservices-architectuur
Ontdek de voor- en nadelen van microservices en hoe ze verschillen van monolieten.
Nog niet zo lang geleden was een monolithische architectuur, een enkele, autonome eenheid, de voorkeursmethode voor het bouwen van softwaretoepassingen. Deze aanpak werkte goed voor veel ontwikkelaars totdat applicaties steeds complexer werden. Wanneer een wijziging in een klein deel van de code wordt aangebracht in een monolithisch systeem, moet het hele systeem opnieuw worden opgebouwd, moeten tests worden uitgevoerd op het hele systeem en moet een geheel nieuwe versie van de applicatie worden geïmplementeerd.
Toen kwamen microservices, een aanpak waarbij softwaresystemen worden opgesplitst in kleinere eenheden die onafhankelijk van elkaar worden ontwikkeld en geïmplementeerd. De microservices-architectuur werd gestimuleerd door de DevOps-beweging die regelmatig updates wil leveren, zoals nieuwe functies, bugfixes en beveiligingsverbeteringen. Het werd in veel gevallen ook een manier voor bedrijven om oude applicaties te herschrijven in een moderne programmeertaal en updates van een technologiestack.
Microservices zijn een verzameling kleine eenheden die continu grote, complexe toepassingen leveren en implementeren.
Wat zijn microservices?
Een microservices-architectuur, ook wel gewoon microservices genoemd, is een manier om een toepassing te bouwen als een reeks onafhankelijk inzetbare services die gedecentraliseerd en onafhankelijk van elkaar zijn ontwikkeld. Deze services zijn losjes met elkaar verbonden, onafhankelijk inzetbaar en gemakkelijk te onderhouden. Een monolithische applicatie is gebouwd als een enkele, ondeelbare eenheid. Met microservices wordt die eenheid opgesplitst in een verzameling onafhankelijke eenheden die samen het grotere geheel vormen. Microservices zijn een integraal onderdeel van DevOps, omdat ze de basis vormen voor continue leveringspraktijken waarmee teams snel kunnen inspelen op de vereisten van de gebruiker.
Een microservice is een webservice die verantwoordelijk is voor één stuk domeinlogica. Meerdere microservices vormen samen een applicatie, waarbij elk een stukje functionaliteit biedt voor een domein. Microservices communiceren met elkaar via API's, zoals REST of gRPC, maar hebben geen kennis van de interne werking van de andere services. Deze harmonieuze interactie tussen microservices is de microservices-architectuur.
Met een microservices-architectuur kunnen ontwikkelaars zich organiseren in kleinere teams die gespecialiseerd zijn in verschillende services, met verschillende stacks en losgekoppelde implementaties. Jira wordt bijvoorbeeld aangedreven door meerdere microservices die elk specifieke mogelijkheden bieden, waaronder issues zoeken, issuedetails bekijken, opmerkingen, issuetransities en meer.
Kenmerken van microservices
Er is geen officiële definitie van een microservices-architectuur, maar er zijn wel een paar patronen of kenmerken die belangrijk zijn.
Onafhankelijke componenten
De basis van een microservices-architectuur is een component. Dit kan een pakket software, webservice of resource, applicatie of module zijn die een reeks gerelateerde functies bevat. Of zoals Martin Fowler het uitlegt: "softwarecomponenten zijn dingen die je onafhankelijk van elkaar kunt vervangen en upgraden."
In een microservices-architectuur kan elke component worden ontwikkeld, geïmplementeerd, beheerd, gewijzigd en opnieuw worden geïmplementeerd zonder de functie van andere services of de integriteit van een toepassing in gevaar te brengen.
Componenten worden gebruikt met andere componenten om een klantervaring of zakelijke waarde te leveren. De meest voorkomende componenten zijn services en bibliotheken, maar het kunnen CLI-tools, mobiele apps, front-end modules, datapipelines, machine learning-modellen en vele andere concepten zijn die kunnen worden toegepast binnen een microservices-architectuur.
Schone interfaces
Zodra afzonderlijke componenten zijn vastgesteld, hebben ze een aanzienlijke hoeveelheid logica nodig om met elkaar te communiceren via een communicatiemechanisme zoals RPC, REST via HTTP of een systeem dat gebaseerd is op gebeurtenissen. Deze mechanismen kunnen een synchrone of asynchrone methode vormen en microservices kunnen een combinatie van beide gebruiken.
Het belangrijkste aspect is dat elke microservice een duidelijk, intuïtief contract moet bieden waarin wordt beschreven hoe een consument die service kan gebruiken. Dit gebeurt meestal via een API die naast de service wordt gepubliceerd.
Je bouwt het, je voert het uit
De DevOps-filosofie van "jij bouwt het, jij voert het uit" benadrukte dat je een architectuur niet kunt veranderen in microservices zonder na te denken over hoe de teams zijn gestructureerd. DevOps brengt incentives voor functionele rollen (ontwikkeling, QA, release engineering, operations) samen in één team met een gedeeld doel om software van hoge kwaliteit te bouwen. DevOps-praktijken zoals CI/CD, geautomatiseerde tests en functievlaggen versnellen de implementatie en zorgen ervoor dat de stabiliteit en beveiliging van het systeem behouden blijft. Bovendien kan elk team zijn eigen microservices bouwen en implementeren zonder andere teams te beïnvloeden.
De evolutie van de cloud heeft het bouwen, implementeren en bedienen van microservices eenvoudiger gemaakt. Teams zijn blij met de technieken voor infrastructuurautomatisering zoals continue integratie, continue levering en geautomatiseerde tests.
Servicegerichte architectuur versus microservices
Servicegerichte architectuur (SOA) en microservices zijn twee soorten webservicearchitecturen. Net als microservices bestaat een SOA uit herbruikbare, gespecialiseerde componenten die onafhankelijk van elkaar werken. Het onderscheid tussen de twee architectuurtypen is de bureaucratische classificatie van servicetypen.
Een SOA heeft vier standaard servicetypen:
- Business
- Enterprise
- Applicatie
- Infrastructuurservices
Deze typen bepalen de gerelateerde domeinspecifieke verantwoordelijkheid van de onderliggende services. Microservices hebben daarentegen slechts twee servicetypen: functioneel en infrastructuur.
Beide architecturen bevatten dezelfde reeks standaarden in verschillende lagen van een onderneming. Het bestaan van een microservices-architectuur is afhankelijk van het succes van een SOA-patroon. Een microservices-architectuurpatroon is dus een subset van SOA. Hier ligt de nadruk vooral op de runtime-autonomie van elke service.
Voordelen van microservices
Agility
Omdat kleine, onafhankelijke teams doorgaans een service binnen microservices bouwen, worden teams gestimuleerd om agile praktijken te gebruiken. Teams kunnen zelfstandig werken en snel schakelen, waardoor de ontwikkelingscyclus sneller verloopt.
Flexibel schalen
Omdat microservices per ontwerp worden gedistribueerd en in clusters kunnen worden geïmplementeerd, zorgen ze ervoor dat bedrijven dynamisch en horizontaal kunnen schalen, over servicegrenzen heen. Als een microservice zijn laadvermogen bereikt, kunnen nieuwe installaties van die service snel worden ingezet in de bijbehorende cluster om de druk te verlichten.
Regelmatige releases
Een van de belangrijkste voordelen van microservices zijn regelmatige en snellere releasecycli. Dit is een belangrijk element van continue integratie en continue levering (CI/CD) en hierdoor kunnen microservices-teams experimenteren met nieuwe functies en deze snel terugdraaien als er iets niet werkt. Hierdoor kan code gemakkelijker bijgewerkt worden en kunnen nieuwe functies sneller gereleased worden.
Flexibele technologie
Microservices-architecturen volgen niet per se een vaste aanpak met één toolchain, maar bieden teams de vrijheid om hun eigen tools te selecteren.
Focus op kwaliteit
De scheiding van zakelijke uitdagingen in onafhankelijke microservices betekent dat het serviceteam dat eigenaar is van die service, zich bezighoudt met het hoogwaardige product dat is voltooid en kan worden geleverd.
Hoge betrouwbaarheid
Door functionaliteiten van elkaar te scheiden, verminderen microservices het risico dat een volledige applicatie of codebasis crasht bij het releasen van een update. Het is eenvoudig om fouten en bugs in individuele services te isoleren en op te lossen. Je kunt wijzigingen alleen implementeren voor een specifieke service, zonder de hele toepassing te verwijderen. Dit zorgt voor veel meer betrouwbaarheid.
Uitdagingen van microservices
Ontwikkelingswildgroei
De overgang van een monoliet naar microservices betekent meer complexiteit. Er zijn meer services op meer locaties die door meerdere teams zijn ontwikkeld. Hierdoor is het lastig om te zien hoe verschillende componenten zich tot elkaar verhouden, wie een bepaalde component bezit, en hoe je een negatieve impact op afhankelijke componenten voorkomt. Als de wildgroei onbeheerd blijft, resulteert dit in een lagere ontwikkelingssnelheid en slechte operationele prestaties. Naarmate een systeem groeit, is er een ervaren operations-team nodig om constante herimplementaties en regelmatige wijzigingen in de architectuur te beheren.
Gebrek aan duidelijk eigenaarschap
In een microservices-architectuur kan het soms lastig zijn om te zien wat van wie is. Een DevOps-team kan een combinatie van API's, componentbibliotheken, monitoringtools en Docker-images uitvoeren zodat gebruikers een toepassing kunnen implementeren. Het is belangrijk om inzicht te hebben in informatie over componenten, zoals hun eigenaren, resources en evoluerende relaties tussen andere componenten. Nauwkeurige communicatie en coördinatie tussen verschillende teams is vereist, zodat alle betrokkenen gemakkelijk de vereiste kennis kunnen vinden om een product te begrijpen.
Hogere infrastructuurkosten
Elke nieuwe microservice die aan een productimplementatie wordt toegevoegd zal kosten met zich meebrengen voor testsuites, implementatiedraaiboeken, hostinginfrastructuur, monitoringtools en meer.
Meer organisatie-overhead
Er is meer communicatie en samenwerking nodig om updates en interfaces tussen microservices-architectuurteams te coördineren.
Debuggen
Het kan een uitdaging zijn om een toepassing te debuggen die meerdere microservices bevat, elk met een eigen set logs. Een enkel bedrijfsproces kan op verschillende tijdstippen op meerdere machines draaien, wat het debuggen nog ingewikkelder maakt.
Incident response
Het is belangrijk om de juiste informatie over de respons van microservice-incidenten te hebben, zoals wie de microservice gebruikt, waar de microservice is geïmplementeerd, hoe de microservice is geïmplementeerd en met wie je contact opneemt als er iets misgaat.
Microservices en DevOps: twee handen op één buik
Omdat microservices steeds complexer en afhankelijker van elkaar worden, zijn de DevOps-praktijken van implementatie, monitoring en levenscyclusautomatisering een integraal onderdeel van microservices-architecturen. Daarom worden microservices vaak beschouwd als de eerste stap om een DevOps-cultuur te omarmen om het volgende mogelijk te maken:
- Automatisering
- Verbeterde schaalbaarheid
- Beheerbaarheid
- Agility
- Snellere levering en implementatie
Belangrijkste technologie en tools voor een microservices-architectuur
Containers, Docker en Kubernetes
Een container is gewoon de verpakking van een toepassing en al zijn afhankelijkheden, waardoor deze gemakkelijk en consistent kan worden geïmplementeerd. Omdat containers geen overhead hebben van hun eigen besturingssysteem, zijn ze kleiner en lichter dan traditionele virtuele machines. Ze kunnen sneller op en neer schalen, waardoor ze een perfecte match zijn voor de kleinere services binnen microservices-architecturen.
Met de wildgroei aan services en containers is het orkestreren en beheren van grote groepen containers essentieel. Docker is een populair containerplatform en runtime waarmee ontwikkelaars containers kunnen bouwen, implementeren en uitvoeren. Het runnen en beheren van containers op schaal is echter een uitdaging als je alleen Docker gebruikt. Kubernetes en andere oplossingen zoals Docker Swarm, Mesos, HashiCorp Nomad en meer helpen om containerisatie op schaal aan te pakken.
Containerisatie en de inzet van containers is een nieuw patroon van een gedistribueerde infrastructuur. Docker en Kubernetes verpakken een service in een complete container die snel kan worden geïmplementeerd en verwijderd. Deze infrastructuurtools vormen een aanvulling op de microservices-architectuur. Microservices kunnen in containers worden geplaatst, en eenvoudig worden geïmplementeerd en beheerd met behulp van een containerbeheersysteem.
API-gateways
De individuele services in een microservices-architectuur communiceren met elkaar via goed gedefinieerde API's. Een API-gateway fungeert als een reverse proxy door API-calls te accepteren, de servicers te verzamelen om ze te verwerken en resultaten te retourneren. API-gateways bieden een abstractie die één API-eindpunt bedient, ook al worden API's bediend door meerdere microservices. API-gateways kunnen ook zaken zoals snelheidsbeperking, monitoring, authenticatie, autorisatie en routering naar de juiste microservice consolideren.
Berichten en streaming van gebeurtenissen
Vanwege het gedistribueerde karakter van microservices hebben teams een manier nodig om statuswijzigingen en andere gebeurtenissen te delen. Berichtsystemen communiceren tussen microservices, waardoor sommige microservices gebeurtenissen kunnen verwerken als onderdeel van hun primaire interface. Wijzigingen aan Confluence-pagina's resulteren bijvoorbeeld in een gebeurtenis waarbij een herindex wordt geactiveerd voor zoekopdrachten en meldingen voor personen die de pagina bekijken.
Loggen en monitoren
Met microservices is het soms lastig om een issue te identificeren en op te lossen in meerdere services. Daarom zijn observabiliteitstools belangrijk voor loggen, monitoren en traceren. Hierdoor zie je hoe microservices zich gedragen en kun je mogelijke problemen identificeren, problemen oplossen en debugging-fouten verhelpen.
Continue integratie/continue levering
Een van de belangrijkste voordelen van microservices zijn regelmatige en snellere releasecycli. Dit is een belangrijk element van CI/CD en hierdoor kunnen microservices-teams experimenteren met nieuwe functies en deze snel terugdraaien als er iets niet werkt. Hierdoor kan code gemakkelijker bijgewerkt worden en kunnen nieuwe functies sneller gereleased worden.
Portal voor ontwikkelaars
Naarmate gedistribueerde architecturen complexer worden, kunnen ontwikkelingsteams profiteren van een tool die informatie over technische output en teamsamenwerking consolideert op één plek. Atlassian Compass is bijvoorbeeld ontworpen om de wildgroei aan microservices in te dammen door gegevens en inzichten te bieden in DevOps-toolchains.
De toekomst van microservices
Containerisatie en de inzet van containers is een algemeen patroon van een gedistribueerde infrastructuur. Tools zoals Docker en Kubernetes verpakken een service in een complete container die snel kan worden geïmplementeerd en verwijderd. Deze nieuwe infrastructuurtools vormen een aanvulling op de microservices-architectuur, omdat microservices kunnen worden verpakt in een container, en eenvoudig kunnen worden geïmplementeerd en beheerd met behulp van een containerbeheersysteem.
De implementatie van microservices moet worden gezien als een reis in plaats van het onmiddellijke doel voor een team.
Het kan handig zijn om klein te beginnen om de technische vereisten van een gedistribueerd systeem te begrijpen en afzonderlijke componenten op te schalen. Vervolgens kun je er geleidelijk meer functies uithalen naarmate je ervaring en kennis opdoet.
Navigeer door je microservices met Compass
Bij het werken met een microservicearchitectuur beheert Atlassian Compass de complexiteit van een gedistribueerde en schalende architectuur. Compass is een uitbreidbaar ontwikkelaarsplatform dat verspreide informatie over engineeringoutput en teamsamenwerking samenbrengt op één centrale, doorzoekbare locatie. Naast het beperken van de wildgroei aan microservices met de Component Catalog, helpt Compass je om best practices en de status van je software te bepalen met Scorecards. Ook biedt het gegevens en inzichten in je DevOps-toolchain met behulp van extensies die ontwikkeld zijn op het Atlassian Forge-platform.
