Een monoliet? Nee, dat hebben wij niet meer!

Zoek eens op monolithische applicaties in je favoriete zoekmachine en de kans is groot dat de eerste pagina(s) met links allemaal gaan over het omzetten van een Monolithische applicatie naar microservices. Een groot aantal van deze links zijn artikelen die ook nog eens geplaatst zijn met commerciële doeleinden en eindigen steevast met het aanbod om te helpen bij de transitie van monolithische applicaties naar een microservice landschap.

Het is niet voor niets dat dit een veelbesproken onderwerp is, monolithische applicaties kunnen voordelen met zich mee brengen, maar vooral als applicaties groeien zullen de nadelen groter worden dan de voordelen.

De applicatiemonoliet is eigenlijk één applicatie, meestal met een centrale database. Zeker als het gaat om kleinere applicaties heeft een monoliet veel voordelen: het is makkelijker te ontwikkelen, testen en in productie te nemen, het is overzichtelijk en het beheer is eenvoudig. Zodra een applicatie gaat groeien en er met meer mensen of teams aan gewerkt wordt, worden de nadelen snel zichtbaar: de applicatie wordt complex, nieuwe features worden steeds lastiger te testen en releasen en het duurt daardoor steeds langer voordat er nieuwe versies in productie komen. Daarnaast is het ook steeds lastiger om de applicatie te schalen voor meer gebruikers en betere stabiliteit.

Het opsplitsen van de monolithische applicatie naar een microservicelandschap is dus een logische eerste stap. Maar, zoals ik in de inleiding al schreef: er zijn meer varianten van de monoliet. Varianten die ontstaan nadat een applicatie monoliet is opgesplitst, maar ook varianten die er los van staan. Tijd om daar wat voorbeelden bij te geven.

Na een periode van hard werken hebben de teams het voor elkaar: de monolithische applicatie is opgesplitst, elke microservices heeft zijn eigen database, nieuwe features kunnen weer worden toegevoegd. Het proces rondom het ontwikkelen is echter hetzelfde gebleven: teams ontwikkelen features, ronden deze af binnen een sprint en aan het einde van de sprint worden de features van alle teams samen klaargezet om getest en gereleased te worden. Misschien omdat bestaande build- en releaseprocedures nog in gebruik zijn, maar vaker ook omdat er te veel afhankelijkheden zijn tussen de verschillende microservices of delen van de code. Het resultaat is in ieder geval nog steeds geen zuivere opsplitsing en wat we zien ontstaan is de monolithische build!

Een andere, veelvoorkomende monoliet is de monolithische release. Ook hier zijn afhankelijkheden losgetrokken, maar worden componenten uiteindelijk gezamenlijk gereleased. Het kan zijn dat dit wordt gedaan om procesmatige redenen, een QA-team moet bijvoorbeeld nieuwe features testen of een product owner moet features goedkeuren. Het resultaat is nog steeds een monoliet. Er zijn geen autonome services met zelfstandige test- en releaseprocessen en het ontwikkelteam kan nog steeds niet autonoom opereren.

De eerder genoemde monolieten zijn vaak het gevolg van het opsplitsen van de applicatiemonoliet. Er zijn echter ook andere varianten die daar niet direct mee te maken hebben.

Bij het monolithische model wordt er uitgegaan van een enkele domeintaal en representatie (single view of the world). Voor kleinere organisaties werkt dat waarschijnlijk nog wel maar voor grotere organisaties met verschillende gebruikersgroepen zal dat grote beperkingen met zich mee brengen. Het boek Domain Driven Design van Eric Evans gaat hier dieper op in, hoe je software kunt maken die een betere afspiegeling is van de werkelijkheid, het belang van domeintaal en het opsplitsen van verschillende domeinen.

Organisaties proberen vaak onderdelen te standaardiseren, zoals build- en releasescripts herbruikbaar te maken. Alles om teams zoveel mogelijk werk uit handen te nemen en de “cognitive load” te verlagen, zoals ook veelvuldig beschreven in Team Topologies. Dit monolithisch denken zorgt echter ook voor veel belemmeringen. Engineers worden niet meer uitgedaagd om te doen waar ze goed in zijn, nl. problemen oplossen met de beste technieken en technologieën. Monolithisch denken kan leiden tot verminderde motivatie, minder experimenteren, slechte keuzes in oplossingen en andere problemen zoals ook beschreven in Accelerate.

Een laatste, misschien wel verrassende variant is de monolithische werkvloer. Iedereen kent wel de kantoortuin, grote ruimtes waar iedereen door-, bij- en met elkaar werkt. Het ziet er vaak mooi uit en op papier klinkt het effectief. Maar in de praktijk werkt het vaak anders. Zoals ook beschreven in Team Topologies is uit onderzoek¹ gebleken dat face-to-faceinteractie met meer dan 70% afneemt terwijl de digitale communicatie juist toeneemt. Het idee is niet om alle mensen zo dicht mogelijk bij elkaar te zetten (de monoliet) maar om er juist over na te denken mensen doelgericht te laten samenwerken en communiceren. In Team Topologies zijn zelfs specifieke hoofdstukken over “team-first” kantoorlay-out en verschillende vormen van teaminteractie geschreven.

Veel organisaties maken dezelfde groei door, van monolithische applicatie naar een ander landschap. De migratie naar een ander landschap brengt alleen niet altijd wat er van verwacht werd. Het helpt om verder te denken dan alleen de applicatiemonoliet! Is je organisatie goed ingericht om met deze veranderingen om te gaan of moet je veel verder gaan met het aanpassen van je werkwijze?

Eigenlijk gaat het niet zo zeer om de monoliet zelf, maar over de onderliggende problematiek. Veel vaker gaat het over autonomie en eigenaarschap. Teams moeten zelfstandig keuzes kunnen maken en echt eigenaar zijn van hun software. Niet alleen als het gaat om nieuwe features, maar ook eigenaar van releases, beheer en feedback van gebruikers. Autonomie en daarbij ook vertrouwen is zo belangrijk dat zelfs de inrichting van de werkvloer bij kan dragen aan het succes.

Vanuit het nadenken over de monoliet kom je automatisch bij andere onderwerpen uit. Denk hierbij aan Devops, Testen, Software Ontwikkeling, Agile werken, etc. Mocht je door de bomen het bos niet meer zien, of gewoon van gedachten willen wisselen over monolieten, neem dan gerust contact met mij op!

• Team Topologies: Organizing Business and Technology Teams for Fast Flow
• Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations