Microservices vs. monolithische architectuur

Organisaties kunnen kiezen voor een monolithische of microservices-architectuur, afhankelijk van een aantal verschillende factoren. Bij de ontwikkeling met behulp van een monolithische architectuur is de hoge ontwikkelingssnelheid het belangrijkste voordeel vanwege de eenvoud van een toepassing op basis van één codebasis.

De voordelen van een monolithische architectuur zijn onder andere:

Eenvoudige implementatie — Eén uitvoerbaar bestand of uitvoerbare map maakt de implementatie eenvoudiger.

Ontwikkeling — Als een toepassing met één codebasis is gemaakt, dan is deze gemakkelijker te ontwikkelen.

Prestaties — In een centrale codebasis en repository kan één API vaak dezelfde taken uitvoeren als meerdere API's met microservices.

Vereenvoudigde testen — Aangezien een monolithische toepassing één centrale eenheid is, kunnen end-to-endtesten sneller worden uitgevoerd dan bij een gedistribueerde toepassing.

Eenvoudige debugging — Als alle code zich op één plek bevindt, kan een aanvraag gemakkelijker gevolgd worden en een issue sneller gevonden worden.

Net als bij Netflix kunnen monolithische toepassingen zeer effectief zijn, tot ze te groot worden waardoor schalen lastig wordt. Voor een kleine verandering in één functie moet het hele platform worden gecompileerd en getest, wat in strijd is met de agile aanpak waar ontwikkelaars tegenwoordig de voorkeur aan geven.

De nadelen van een monoliet zijn onder andere:

Lagere ontwikkelingssnelheid — Een grote, monolithische toepassing maakt de ontwikkeling complexer en langzamer.

Schaalbaarheid — Je kunt afzonderlijke componenten niet schalen.

Betrouwbaarheid — Als er een fout in een module optreedt, kan dit de beschikbaarheid van de hele toepassing beïnvloeden.

Lastige technische implementatie — Eventuele wijzigingen in het framework of de taal hebben invloed op de gehele toepassing, waardoor wijzigingen vaak duur zijn en veel tijd in beslag nemen.

Weinig flexibiliteit — Een monoliet is gebonden aan de technologie die al in de monoliet wordt gebruikt.

Implementatie — Als er een kleine wijziging in een monolithische toepassing doorgevoerd moet worden, dan moet de gehele monoliet opnieuw geïmplementeerd worden.

Een microservices-architectuur, die ook gewoon 'microservices' wordt genoemd, is een architectonische methode die afhankelijk is van een reeks afzonderlijk implementeerbare services. Deze services hebben hun eigen bedrijfslogica en database met een specifiek doel. Bijwerken, testen, implementeren en schalen vindt plaats binnen elke service. Microservices zetten grote zakelijke, domeinspecifieke belangen om in afzonderlijke, onafhankelijke codebases. Microservices zorgen niet voor minder complexiteit, maar maken elke complexiteit zichtbaar en beter beheersbaar door taken om te zetten naar kleinere processen die onafhankelijk van elkaar functioneren en bijdragen aan het geheel.

Het adopteren van microservices gaat vaak gepaard met DevOps, omdat ze de basis vormen voor continue levering waarmee teams zich snel kunnen aanpassen aan de vereisten van de gebruiker.

Atlassian stapte over op microservices in 2018 nadat we te maken kregen met uitdagingen op het gebied van groei en schaal met Jira en Confluence. We ontdekten dat onze monolithische architecturen met één tenant die on-premise draaien niet in staat zouden zijn om te schalen op basis van toekomstige behoeften.

We besloten Jira en Confluence opnieuw te ontwerpen en ze te verplaatsen van een beperkt monolithisch systeem met één tenant naar grenzeloze cloudtoepassingen met meerdere tenants, gehost door Amazon Web Services (AWS). Daarna deelden we ze in de loop van de tijd op in microservices. Het project werd Vertigo genoemd nadat een senior technicus zei: 'Ik vind het idee echt top, maar het maakt me duizelig.” Het was ons grootste infrastructuurproject tot nu toe en het duurde twee jaar om de transitie naar AWS te voltooien, waarbij meer dan 100.000 klanten in iets meer dan 10 maanden werden overgezet zonder serviceonderbrekingen. We deden er ook alles aan om de diensten op te delen in microservices.

Microservices zijn zeker geen wondermiddel maar lossen wel allerlei problemen op voor groeiende software en bedrijven. Aangezien een microservices-architectuur bestaat uit eenheden die onafhankelijk worden uitgevoerd, kan elke service ontwikkeld, bijgewerkt, geïmplementeerd en geschaald worden zonder de andere services te beïnvloeden. Software-updates kunnen vaker worden uitgevoerd met een hogere betrouwbaarheid, meer uptime en betere prestaties. Eerst voerden we eenmaal per week updates uit en doen dit nu zo'n twee tot drie keer per dag.

Naarmate Atlassian groeit, kunnen we dankzij microservices teams en geografische locaties betrouwbaarder schalen, door meer mogelijkheden te bieden voor het leveren van service. Voordat we Vertigo begonnen had Atlassian vijf verschillende ontwikkelingscentra over de hele wereld. Deze gedistribueerde teams werden beperkt door een centrale monoliet, en we moesten ze meer zelfstandigheid bieden. Dit konden we doen dankzij microservices.

De voordelen van Vertigo zijn onder andere een hogere implementatiesnelheid, disaster recovery, lagere kosten en hogere prestaties. Hierdoor kunnen we ons doel sneller bereiken en meer incrementele waarde te bieden aan klanten.

Bovendien maken microservices het voor teams over het algemeen eenvoudiger om code bij te werken en releasecycli te versnellen met continue integratie en continue levering (CI/CD). Teams kunnen experimenteren met code en alles weer terugdraaien als er iets misgaat.

De voordelen van microservices zijn in het kort:

Agility — Stimuleer agile werkwijzen met kleine teams die vaak implementeren.

Flexibel schalen — Als een microservice zijn laadvermogen bereikt, kunnen nieuwe installaties van die service snel worden ingezet in de bijbehorende cluster om de druk te verlichten. We bieden nu grenzeloze opties met meerdere tenants en hebben klanten verspreid over meerdere installaties. Nu kunnen we veel grotere installaties ondersteunen.

Continue implementatie — We hebben nu regelmatige en snellere releasecycli. Hiervoor voerden we eenmaal per week updates uit en nu kunnen we dat zo'n twee tot drie keer per dag doen.

Eenvoudig te onderhouden en testen – Teams kunnen experimenteren met nieuwe functies en alles weer terugdraaien als er iets niet werkt. Hierdoor kan code gemakkelijker bijgewerkt worden en kunnen nieuwe functies sneller gereleased worden. Bovendien is het eenvoudig om fouten en bugs in individuele services te isoleren en op te lossen.

Afzonderlijk te implementeren — Aangezien microservices afzonderlijke eenheden zijn, maken ze een snelle, eenvoudige onafhankelijke implementatie van individuele functies mogelijk.

Technologische flexibiliteit — Microservice-architecturen geven teams de vrijheid om de tools te kiezen die ze willen.

Hoge betrouwbaarheid — Je kunt wijzigingen voor een specifieke service implementeren, zonder dat je je zorgen hoeft te maken dat de hele toepassing wordt uitgeschakeld.

Blijere teams — Atlassian-teams die met microservices werken, zijn een stuk blijer omdat ze zelfstandiger zijn en zelf kunnen maken en implementeren, zonder dat ze weken op de goedkeuring van een pull request hoeven te wachten.

Toen we overstapten van een klein aantal monolithische codebases naar meerdere gedistribueerde systemen en diensten die onze producten mogelijk maakten, had dit onbedoelde complexiteit tot gevolg. We hadden aanvankelijk moeite om nieuwe capaciteiten toe te voegen met dezelfde snelheid en hetzelfde vertrouwen als eerder. Microservices kunnen tot meer complexiteit leiden die een te uitgebreide ontwikkeling of snelle en onbeheerde groei kan veroorzaken. Het kan lastig zijn om te bepalen hoe verschillende componenten zich tot elkaar verhouden, wie een bepaalde softwarecomponent bezit of hoe je voorkomt dat afhankelijke componenten worden verstoord.

We hebben met Vertigo een gemeenschappelijke functionaliteit gebouwd die de motor vormt achter onze bestaande producten en de toekomstige producten die we overnemen en ontwikkelen. Als je een bedrijf hebt met één product, zijn microservices mogelijk niet nodig.

De nadelen van microservices zijn onder andere:

Te uitgebreide ontwikkeling — Microservices zorgen voor meer complexiteit in vergelijking met een monolithische architectuur, omdat er meer services op meer plaatsen zijn die door meerdere teams worden gecreëerd. Als de ontwikkeling niet goed wordt beheerd, leidt dit tot een lagere ontwikkelingssnelheid en lagere operationele prestaties.

Exponentiële infrastructuurkosten — Elke nieuwe microservice kan kosten met zich meebrengen voor testsuites, implementatiedraaiboeken, hostinginfrastructuur, monitoringtools en meer.

Meer organisatorische overhead — Teams moeten een aanvullend communicatie- en samenwerkingsniveau toevoegen om updates en interfaces af te stemmen.

Uitdagingen bij debuggen — Elke microservice heeft zijn eigen set logs, waardoor debuggen ingewikkelder wordt. Bovendien kan één bedrijfsproces op meerdere machines worden uitgevoerd, wat debuggen nog ingewikkelder maakt.

Gebrek aan standaardisatie — Zonder een gemeenschappelijk platform kan er sprake zijn van een proliferatie van talen, logstandaarden en monitoring.

Onduidelijke eigenaren — Naarmate er meer services worden geïntroduceerd, geldt dat ook voor het aantal teams dat deze services beheert. Na verloop van tijd wordt het lastig om te bepalen voor welke services een team nodig is en met wie contact opgenomen kan worden voor support.

Veel projecten beginnen aanvankelijk als monoliet en evolueren naar een microservicearchitectuur. Naarmate er nieuwe functies aan een monoliet worden toegevoegd, kan het omslachtig worden als veel ontwikkelaars aan één codebasis werken. Codeconflicten komen vaker voor en het risico dat updates van één functie bugs introduceren in een niet-gerelateerde functie neemt toe. Wanneer deze ongewenste patronen zich voordoen, is het misschien tijd om over te stappen naar microservices.

Hieronder volgen een aantal best practices die we van onze migratie hebben geleerd:

In januari 2016 hadden we in totaal zo'n 15 microservices. Nu hebben we er meer dan 1300. We hebben 100.000 klanten overgezet naar de cloud, daarbij een nieuw platform opgezet, onze cultuur aangepast en daardoor nieuwe tools gekregen. Onze teams zijn blijer en zelfstandiger, en we hebben een betere DevOps-cultuur.

Microservices zijn misschien niet voor iedereen weggelegd. Een oudere monoliet werkt misschien perfect, en een aanpassing is mogelijk niet de moeite waard. Naarmate organisaties echter groeien en de vraag naar hun toepassingen toeneemt, kan een microservices-architectuur waardevol zijn.

Aangezien de trend voor veel organisaties microservices met gedistribueerde architecturen is, ontwikkelde Atlassian Compass om bedrijven te helpen de complexiteit van gedistribueerde architecturen te beheren terwijl ze schalen. Compass is een uitbreidbaar ontwikkelaarsplatform dat verspreide informatie over engineeringoutput en teamsamenwerking samenbrengt op één centrale, doorzoekbare locatie.