Wat zijn microservices?

Wat is microservicesarchitectuur?

Bij het bouwen van software is een van de belangrijkste beslissingen die u zult moeten nemen, hoe u uw applicatie structureert. Jarenlang was de standaardaanpak om alles te bouwen als één enkel, uniform systeem (een monolithische architectuur). Maar naarmate bedrijven groeiden en applicaties steeds complexer werden, begon deze aanpak zijn beperkingen te vertonen. Daar komt microservicesarchitectuur om de hoek kijken.

TL;DR

• Microservicesarchitectuur splitst applicaties op in kleine, onafhankelijke services die elk een specifieke bedrijfsfunctie afhandelen.
• Elke service kan verschillende technologieën gebruiken, onafhankelijk schalen en worden geïmplementeerd zonder andere delen van het systeem te beïnvloeden.
• Belangrijke voordelen zijn onder andere teamautonomie, foutisolatie, eenvoudiger onderhoud en de mogelijkheid om specifieke componenten te schalen op basis van de vraag.
• Uitdagingen zijn onder andere toegenomen operationele complexiteit, gedistribueerd systeembeheer en het behouden van dataconsistentie tussen services.
• Meest geschikt voor grote applicaties met meerdere teams, wisselende schaalbehoeften en organisaties die klaar zijn om te investeren in de vereiste infrastructuur en expertise.

De verschuiving van monolithisch denken

Denk eens na over hoe een traditionele monolithische webapplicatie werkt. Stel je een webwinkel voor waar alles op één plek staat: gebruikersaccounts, productvermeldingen, winkelwagentjes, afrekenen, betalingen en voorraadbeheer zijn allemaal gebundeld in één codebase. In deze monolithische opzet moet je de hele applicatie opnieuw implementeren wanneer je het betalingssysteem moet updaten. Wanneer de productzoekmachine veel verkeer genereert, moet je alles schalen, zelfs de onderdelen die het niet nodig hebben.

Met microservices is de situatie compleet anders. In plaats van één groot systeem, bouw je je applicatie als een verzameling kleine, gerichte services die samenwerken. Diezelfde webwinkel zou opnieuw opgebouwd kunnen worden, waarbij elke bedrijfsfunctie een eigen, onafhankelijke service wordt.

Wat zijn microservices?

Elke microservice in uw architectuur heeft een specifieke functionaliteit. Uw webwinkel kan bestaan ​​uit afzonderlijke services voor gebruikersauthenticatie, productcatalogi, winkelwagentjes, orderverwerking, betalingen en verzendlogistiek. Elk is een complete unit met een eigen codebase, database en implementatieschema.

Wat maakt een service echt een microservice? Verschillende bepalende kenmerken onderscheiden deze aanpak:

Elke service wordt volgens een eigen schema geïmplementeerd. Uw betalingsteam kan bijvoorbeeld elke dinsdag updates verzenden zonder te wachten tot het productcatalogusteam klaar is met zijn werk. Of, wanneer er een bug in de zoekfunctionaliteit optreedt, kunt u alleen die service oplossen en opnieuw implementeren. De rest van uw applicatie blijft draaien op de vorige versie, zonder dat de nieuwe wijzigingen worden beïnvloed.

Teams kiezen hun eigen technologiestack. Elke service kan op een andere technologie draaien. De betalingsservice kan bijvoorbeeld op Java draaien, terwijl uw analyseservice Python gebruikt. Er is geen behoefte aan bedrijfsbrede standaardisatie op één taal of database. U kunt kiezen wat het beste werkt voor de unieke vereisten van elke service.

Services weerspiegelen hoe uw bedrijf daadwerkelijk werkt. In plaats van code te organiseren op technische functie (al uw databasecode hier, al uw API-code daar), organiseert u op bedrijfsdomein. Alles met betrekking tot gebruikersprofielen bevindt zich in één service; alles over orderafhandeling bevindt zich in een andere.

Services communiceren zonder sterke afhankelijkheden. Ze communiceren via goed gedefinieerde interfaces, meestal met behulp van REST API's of berichtenwachtrijen. De interne werking van elke service blijft verborgen voor de andere. De betaalservice hoeft niet te weten hoe de voorraadservice zijn gegevens opslaat. Deze hoeft alleen te weten hoe voorraadinformatie moet worden opgevraagd bij het verwerken van een order. Deze losse koppeling tussen services geeft ontwikkelaars veel flexibiliteit, omdat ze de werking van één onderdeel van de app volledig kunnen herbouwen zonder de andere onderdelen te beïnvloeden.

Echte voordelen in de praktijk

De onafhankelijkheid van microservices levert ontwikkelteams concrete voordelen op. Wanneer een service een plotselinge piek in het verkeer ervaart (zoals een productcatalogus tijdens een uitverkoop), kunt u alleen die specifieke service opschalen. U hoeft niet te betalen voor het draaien van extra instances van uw volledige applicatie wanneer slechts één onderdeel meer resources nodig heeft.

Teams kunnen met echte autonomie werken, wat betekent dat ze de technologie, architectuur en implementatie kunnen kiezen, ongeacht wat andere teams beslissen. Uw betalingsteam kan ervoor kiezen om de service in Java te bouwen met een PostgreSQL-database, omdat deze transacties betrouwbaar verwerkt. Uw aanbevelingsteam kan Python met MongoDB gebruiken, omdat dit beter geschikt is voor de flexibele datastructuren die ze nodig hebben. Geen van beide teams wordt geblokkeerd door de keuzes van de ander.

Met microservices blijft de impact beperkt als er iets misgaat. Als uw productreviewservice problemen ondervindt, kunnen klanten nog steeds producten bekijken, artikelen aan hun winkelwagentje toevoegen en aankopen voltooien. U implementeert circuit breakers en fallback-mechanismen om ervoor te zorgen dat problemen op één gebied zich niet door uw hele systeem verspreiden.

Tot slot is er voor ontwikkelaars die zich bij je team voegen een snellere weg naar productiviteit. In plaats van een enorme codebase te moeten begrijpen voordat ze wijzigingen kunnen aanbrengen, kunnen ze zich concentreren op één service die een specifieke bedrijfsfunctie afhandelt. De scope is beheersbaar, de code is gemakkelijker te testen en de feedbackloop is korter.

De uitdagingen van microservices

Het implementeren van een microservicesarchitectuur brengt ook uitdagingen met zich mee. Je ruilt de complexiteit van een grote monolithische applicatie in voor de complexiteit van een gedistribueerd systeem. Netwerkaanroepen tussen services zijn langzamer dan functieaanroepen binnen één applicatie, waardoor ze op manieren kunnen mislukken die lokale code niet overkomt. Daarom heb je strategieën nodig om time-outs, nieuwe pogingen en service-uitval netjes af te handelen.

Databeheer wordt complexer. Elke service heeft doorgaans een eigen database, wat betekent dat je niet kunt vertrouwen op databasetransacties om alles consistent te houden. Je moet patronen implementeren, zoals uiteindelijke consistentie of gedistribueerde transacties, wat zorgvuldig nadenken en testen vereist.

De operationele last neemt ook aanzienlijk toe. In plaats van één applicatie te implementeren, implementeer je tientallen of mogelijk honderden services. Hoewel dit om vele redenen geweldig is, vereist het ook investeringen in automatisering, containerisatie, orkestratieplatforms, uitgebreide monitoring, gecentraliseerde logging en gedistribueerde traceringstools. Zonder deze tools wordt het beheer van een microservicessysteem al snel overweldigend.

Testen wordt ook complexer. U hebt strategieën nodig om afzonderlijke services afzonderlijk te testen, te testen hoe services met elkaar interacteren en het gedrag van uw volledige systeem te valideren. Het simuleren van serviceafhankelijkheden, contracttesten tussen services en het onderhouden van testomgevingen vereisen allemaal extra inspanning.

Design patterns voor microservices

Gelukkig zijn er bepaalde ontwerppatronen voor microservices ontwikkeld, die gestandaardiseerde en herbruikbare oplossingen zijn om deze veelvoorkomende uitdagingen aan te pakken.

• Het API Gateway-patroon biedt één toegangspunt voor clients en verwerkt de routering en aggregatie van aanvragen.
• Het Circuit Breaker-patroon voorkomt opeenvolgende fouten door aanvragen naar services die het moeilijk hebben te stoppen.
• Het Saga-patroon beheert gedistribueerde transacties over meerdere services en garandeert dataconsistentie, zelfs wanneer de bewerkingen servicegrenzen overschrijden.
• Het Service Discovery-patroon stelt services in staat elkaar dynamisch te vinden tijdens het opschalen en afschalen.
• Het Event Sourcing-patroon houdt een volledige geschiedenis van wijzigingen bij, waardoor het gemakkelijker wordt om te begrijpen hoe uw systeem zijn huidige status heeft bereikt.

Deze ontwerppatronen in microservices zijn geen theoretische concepten, maar praktische oplossingen die teams dagelijks gebruiken om betrouwbare gedistribueerde systemen te bouwen. Als u ze begrijpt, kunt u veelvoorkomende valkuilen vermijden.

De overstap maken van monolithische naar microservices

Veel organisaties beginnen met monolithische applicaties en stappen later over op microservices naarmate ze groeien. De overgang van monolithische naar microservices is zelden een complete herschrijving. In plaats daarvan extraheren teams services doorgaans geleidelijk, beginnend met duidelijk gedefinieerde en losjes gekoppelde grenzen.

U kunt beginnen met het identificeren van een functionaliteit die regelmatig verandert of andere schaalbehoeften heeft dan de rest van uw applicatie. Extraheer die functionaliteit in een eigen service terwijl de monoliet intact blijft. Naarmate u ervaring opdoet met het beheren van meerdere services en uw implementatie-infrastructuur uitbouwt, kunt u extra services extraheren in een tempo dat past bij uw team.

Wanneer microservices zinvol zijn

Microservicesarchitectuur is in bepaalde situaties een uitstekende keuze. Grote applicaties die door meerdere teams worden gebouwd, profiteren van de duidelijke grenzen en autonomie die services bieden. Wanneer verschillende onderdelen van uw applicatie sterk verschillende schaalvereisten hebben, wordt de mogelijkheid om die services onafhankelijk te schalen extreem waardevol. Tot slot vinden organisaties die prioriteit geven aan snelle iteratie en willen dat teams snel kunnen handelen zonder releases te coördineren, microservices een uitkomst.

Microservices zijn echter niet altijd de juiste keuze. Het opsplitsen in services voor kleine applicaties die door één team zijn gebouwd, kan onnodig complex aanvoelen. Ook startups die een product-marktfit proberen te vinden, hebben meestal veel baat bij de snelheid en eenvoud van een monoliet. Teams zonder ervaring met het beheer van gedistribueerde systemen zullen een steile leercurve tegenkomen.

De beslissing of een microservicesarchitectuur geschikt is voor uw organisatie, hangt af van uw specifieke context: teamgrootte, technische expertise, schaalbehoeften en organisatorische volwassenheid. Het gaat er niet om de meest moderne of geavanceerde architectuur te kiezen, maar om de architectuur die uw doelen het beste ondersteunt en tegelijkertijd realistisch is over de uitdagingen die u aankunt.

Leer alles over microservices en meer met *onze uitgebreide gids over tools en integraties voor moderne webontwikkeling.*