Monoliet of Microservices: Wat het MKB Werkelijk Nodig Heeft

Om de zoveel jaar wordt een architectuur populair en aanbevolen aan bedrijven waarvoor ze nooit is bedacht. Microservices zijn het duidelijkste recente voorbeeld. Ze lossen echte problemen op — voor organisaties die die problemen hebben.

Ben je een bedrijf van onder de vijftig mensen, dan heb je ze vrijwel zeker niet, en dit artikel gaat over waarom, en waar de echte uitzonderingen zitten.

Wat de woorden betekenen

Een monoliet is één applicatie. Eén codebase, één deployment, meestal één database. Verander je iets, dan zet je het geheel uit. Zo is software altijd gebouwd, en het woord kreeg een neerbuigende klank die het niet verdient.

Microservices splitsen de applicatie in kleine, onafhankelijke diensten, elk met een eigen codebase, deployment en vaak een eigen database. Ze praten met elkaar over het netwerk.

Wat microservices je opleveren

Drie dingen, en precisie loont, want de voordelen worden meestal te vaag genoemd.

Onafhankelijk uitrollen door onafhankelijke teams. Rollen veertig engineers in zes teams allemaal naar één applicatie uit, dan staan ze in de rij achter elkaar en blokkeert één slechte wijziging iedereen. Splitsen laat elk team leveren zonder af te stemmen. Dit is de echte reden dat grote organisaties microservices aannemen, en het is eerst een organisatorisch voordeel en pas daarna een technisch.

Onafhankelijk schalen. Gebruikt één onderdeel veel meer resources dan de rest — video-encoding, of een zoekindex — dan schaal je dat alleen, in plaats van twintig kopieën van alles te draaien.

Technologie-isolatie. Eén dienst kan in een andere taal worden geschreven, of een andere database gebruiken, zonder de rest mee te slepen.

Wat ze kosten

De kosten worden minder vaak genoemd en ze zijn fors.

Een functieaanroep wordt een netwerkaanroep. In een monoliet is het ene stuk code dat het andere aanroept ogenblikkelijk en kan het niet halverwege mislukken. Over het netwerk kan het traag zijn, aflopen, of slagen terwijl het antwoord verloren gaat. Al die gevallen zijn nu overal van jou.

Debuggen wordt veel lastiger. Een bug over vier diensten betekent vier sets logs, en je hebt distributed tracing nodig om één verzoek door het systeem te volgen. Dat is infrastructuur die je voortaan draait.

Dataconsistentie wordt een ontwerpprobleem. Eén database en één transactie gaven je consistentie gratis. Verdeeld over diensten schrijf je compenserende logica en leef je ermee dat dingen even niet kloppen.

Beheer vermenigvuldigt. Vijftien diensten hebben vijftien pijplijnen nodig, vijftien sets monitoring en alerts, vijftien upgradepaden voor afhankelijkheden. Dat is een baan, en heeft niemand die, dan gebeurt het niet.

De vuistregel die standhoudt: microservices ruilen ontwikkelcomplexiteit in voor operationele complexiteit. Een goede ruil met een platformteam, een slechte met drie ontwikkelaars.

Wat het mkb moet bouwen

Voor vrijwel elk klein en middelgroot bedrijf is het antwoord een goed gestructureerde monoliet. Eén applicatie, als één geheel uitgerold, maar intern georganiseerd met heldere grenzen tussen de gebieden van het bedrijf.

Dat laatste maakt het werkbaar. Het falen dat mensen zich herinneren als "de monoliet" is meestal niet het uitrolmodel — het is een applicatie zonder interne structuur, waar alles overal in grijpt. Dat is een discipline-probleem, en het over een netwerk verdelen lost dat niet op; het maakt de knoop alleen slechter zichtbaar.

Bouw de grenzen eerst binnen de applicatie. Moet je hem ooit echt splitsen, dan zijn juist die schone interne grenzen wat dat mogelijk maakt.

De echte uitzonderingen

Er zijn gevallen waarin iets afsplitsen ook voor een klein bedrijf juist is. Zoek naar een onderdeel dat werkelijk anders is:

• Een werklast met totaal andere resourcebehoefte — zware beeld- of videoverwerking, een machine-learningmodel, een langlopende taak. Die apart draaien voorkomt dat hij je website uithongert.
• Een deel dat onafhankelijk en onvoorspelbaar moet schalen — een publieke API met pieken, bijvoorbeeld.
• Iets met andere beschikbaarheidseisen — als betalingen door moeten draaien terwijl de rest een deploy kan verdragen.
• Een werkelijk apart product dat toevallig een login deelt.

Let op de vorm: het zijn één of twee diensten die om een specifieke reden van een monoliet worden afgesplitst. Dat is iets heel anders dan beginnen met vijftien diensten omdat het de moderne manier is.

Praktisch advies

Begin met een monoliet. Altijd. Je weet nog niet waar de grenzen liggen. Vroeg splitsen is gokken, en een verkeerde grens is veel duurder te repareren dan een ontbrekende.

Investeer vanaf het begin in interne structuur. Heldere modules, expliciete interfaces tussen gebieden, niet rechtstreeks in de data van een ander module graaien. Dat kost aan het begin bijna niets en is achteraf vrijwel niet in te bouwen.

Splits wanneer iets specifieks je daartoe dwingt, niet volgens een schema. Het signaal is concreet: dit deel heeft andere schaling nodig, of een bepaald team zit echt vast, of één werklast destabiliseert de rest.

Wees eerlijk over je operationele capaciteit. Heeft niemand bij jou piketdienst, dan kun je geen gedistribueerd systeem verantwoord draaien. Dat is geen kritiek maar een randvoorwaarde, en daarbinnen ontwerpen is vakmanschap, geen compromis.

De samenvatting

Microservices zijn een oplossing voor organisatorische schaalproblemen die opduiken bij een omvang die de meeste bedrijven nooit bereiken. Heb je minder dan vijftig mensen, dan bedient een goed gestructureerde monoliet je op vrijwel elke as beter: goedkoper te bouwen, makkelijker te debuggen, sneller te wijzigen en veel minder te beheren.

Bouw de grenzen. Sla het netwerk ertussen over tot iets specifieks je dwingt het toe te voegen.