Remi over software architectuur: bouw vandaag wat morgen nog werkt.

Wat is software architectuur?

De eerste vraag die we onszelf stellen bij een nieuw project is nooit: welk framework gebruiken we? We beginnen altijd met: hoe moet dit systeem er over vijf jaar uitzien? Dat is precies de vraag waar software architectuur over gaat.

Definitie en reikwijdte.

Software architectuur is de reeks fundamentele keuzes over de structuur van een softwaresysteem: welke componenten zijn er, hoe zijn ze opgedeeld, hoe communiceren ze met elkaar en hoe gaat het systeem om met schaalbaarheid, beveiliging en onderhoudbaarheid?

Die keuzes maak je vroeg in het proces. En dat is precies waarom ze zo waardevol zijn: ze geven richting aan alles wat daarna komt.

Het verschil met software design.

Architectuur en design opereren op verschillende niveaus. Architectuur gaat over de grote lijnen: hoe is het systeem opgebouwd, welke lagen zijn er, hoe communiceren subsystemen. Design gaat over de invulling van die componenten: klassen, interfaces, patronen binnen een module. Wij zien het zo: een goede architectuur legt het fundament waarop goed design kan floreren. Als dat fundament stevig staat, krijgen developers de ruimte om echt goed werk te leveren.

Waarom architectuurkeuzes er vroeg toe doen.

Slechte architectuurkeuzes stapelen zich op als technical debt: de verborgen schuld die ontstaat wanneer eerdere keuzes later meer complexiteit opleveren dan verwacht. Je betaalt die schuld zelden in één keer. De kosten zitten in de tijd die een developer nodig heeft om een nieuwe feature te bouwen zonder bestaande dingen te breken. In de terughoudendheid om aan bepaalde delen van de codebase te komen. In releases die spannend zijn in plaats van routine.

Het mooie is: zodra je die patronen herkent, kun je er gericht mee aan de slag. Dat begint bij het in kaart brengen van de architectuur.

Wanneer je architectuur om aandacht vraagt.

Herken je dit?

• Nieuwe functionaliteit kost disproportioneel veel tijd

• Bugfixes creëren nieuwe bugs

• De onboardingtijd voor nieuwe developers loopt op

• Elk releasemoment voelt als een evenement

Dan is de kans groot dat het een architectuurvraagstuk is. En dat is een oplosbaar vraagstuk.

Drie niveaus van architectuurkeuzes.

Architectuurkeuzes zijn geen platte lijst van patronen waar je er één uit pikt. Ze lopen langs drie logische niveaus, die je in die volgorde doorloopt: eerst richt je het landschap in, dan de applicatie zelf, dan pas de infrastructuur eronder. Wie die volgorde omdraait, bouwt op een fundament dat hij nog niet kent.

Niveau 1: de inrichting van het landschap.

De eerste vraag is de grootst mogelijke: hoe ziet het hele systeem eruit? Hoeveel applicaties zijn er, hoe verhouden ze zich tot elkaar en hoe groeien ze mee?

Monolithische architectuur: de kracht van eenvoud.

Een monoliet is een applicatie waarbij alle functionaliteit in één codebase zit en als één geheel wordt uitgerold. Het heeft een onterecht slecht imago. Een monoliet is eenvoudig te begrijpen, eenvoudig te debuggen en eenvoudig te deployen. Voor kleine teams en producten in een vroege fase is het bijna altijd de juiste keuze. Minder overhead, meer snelheid, minder coördinatie.

Wij zijn grote voorstanders van monoliet-first als startpunt. Niet uit gemakzucht, maar omdat je de complexiteit van microservices pas nodig hebt als je systeem groot genoeg is om er daadwerkelijk van te profiteren.

SOA en de modulaire monoliet: de tussenstap die vaak wordt overgeslagen.

Tussen monoliet en microservices zit een belangrijk tussenstation dat regelmatig wordt overgeslagen: de modulaire monoliet. SOA (Service Oriented Architecture) is een verwante maar bredere stijl, waarbij services over een netwerk communiceren en los van elkaar draaien. Een modulaire monoliet is één deployable eenheid die intern is opgedeeld in modules. De grens zit in deployment: bij SOA zijn services al los; bij een modulaire monoliet nog niet.

Het principe: één codebase, maar intern opgedeeld in logische, zelfstandige modules met duidelijke grenzen. Elke module heeft zijn eigen verantwoordelijkheid en communiceert met andere modules via een gedefinieerde interface, niet via directe afhankelijkheden door de codebase heen.

Dat onderscheid is waardevol. Wanneer het systeem groeit en de behoefte aan onafhankelijke schaalbaarheid of deployment toeneemt, kunnen individuele modules worden losgetrokken en als aparte services worden ingezet. De transitie naar microservices wordt zo een gecontroleerde stap, geen herschrijving.

Microservices: schaalbaarheid met complexiteit.

Bij microservices is de applicatie opgedeeld in kleine, onafhankelijke services die elk één verantwoordelijkheid hebben. Ze communiceren via API's of een message bus, een systeem dat berichten tussen services aflevert, zoals RabbitMQ of Kafka.

Het grote voordeel: services kunnen onafhankelijk worden geschaald, gedeployed en vervangen. De keerzijde: de operationele complexiteit neemt enorm toe. Microservices zijn de juiste keuze als je grote teams hebt die onafhankelijk van elkaar willen deployen, of als verschillende onderdelen sterk uiteenlopende schaalvereisten hebben.

Martin Fowler, autoriteit op het gebied van softwarearchitectuur, refactoring en microservices, beschrijft het in zijn artikel MonolithFirst zo: begin geen nieuw project met microservices, ook niet als je verwacht dat het systeem groot genoeg wordt om er ooit van te profiteren. Bijna elk succesvol microservices-systeem begon als een monoliet. Die wijsheid onderschrijven wij volledig.

Niveau 2: de inrichting van de applicatie.

Nadat het landschap staat, kijken we naar hoe de applicatie zelf van binnen werkt. Hoe reageren componenten op elkaar? Hoe stroomt informatie door het systeem?

Event-driven architectuur.

In een event-driven systeem reageren componenten op gebeurtenissen in plaats van op directe aanroepen. Stel je voor: een geplaatste bestelling triggert een event. De voorraadmodule, de mailservice en de facturatie component reageren elk op dat event, onafhankelijk van elkaar.

Sterk punt: losse koppeling tussen componenten. Dat maakt het systeem flexibel en goed uitbreidbaar. De uitdaging zit in het redeneren over de toestand van het systeem op een bepaald moment. Event-driven architectuur past goed bij systemen met hoge throughput, asynchrone verwerking en meerdere onafhankelijke afnemers van dezelfde data.

Niveau 3: de infrastructuur.

Pas nadat het landschap en de applicatie staan, kijken we naar hoe en waar we het draaien. Infrastructuurkeuzes vloeien voort uit eerdere architectuurkeuzes, niet andersom.

Hosting: shared of eigen omgeving.

De meest concrete infrastructuurkeuze is vaak ook de meest praktische: draait het platform op een gedeelde server, of op een eigen VPS (Virtual Private Server)? Een gedeelde omgeving is goedkoper en eenvoudiger te beheren. Een eigen VPS geeft meer controle, betere isolatie en voorspelbaarder gedrag onder belasting.

Bij Cube hanteren we strikte scheiding van omgevingen als standaard. Wat die scheiding precies inhoudt, verschilt per platform: soms is logische scheiding binnen een gedeelde server voldoende, soms is fysieke isolatie noodzakelijk. Die afweging maken we op basis van de beveiligings- en beschikbaarheidseisen van het systeem.

Serverless en cloud-native.

Serverless betekent niet dat er geen servers zijn, maar dat je er geen eigen servers beheert. Functionaliteit wordt gedeployed als losse functies die schalen op basis van gebruik. Cloud-native is een bredere term voor architecturen die optimaal gebruik maken van cloudinfrastructuur: containers zoals Docker, orkestratie zoals Kubernetes en managed services.

Beide benaderingen bieden interessante mogelijkheden, zeker voor systemen met sterk wisselende belasting. Welke optie past, hangt af van de keuzes die in niveau één en twee al zijn gemaakt. Meer over hoe wij hosting en infrastructuur inrichten, lees je op onze hosting & infrastructuur pagina.

Hoe kies je het juiste patroon?.

Er is geen universeel beste architectuur. Er zijn keuzes die passen bij bepaalde contexten. We maken die keuzes altijd op basis van vier factoren.

• Teamgrootte: kleine teams werken efficiënter met een monoliet. Grotere teams profiteren van de onafhankelijkheid van microservices, maar betalen ook de coördinatieprijs.

• Verwachte schaal: weet je al dat je systeem honderdduizenden gelijktijdige gebruikers moet aankunnen? Dan heeft een cloud-native of microservices-aanpak voordelen. Weet je dat nog niet? Dan is vooruitlopen op schaalproblemen die er misschien nooit komen, zonde van je budget.

• Snelheid naar markt: een monoliet is sneller te bouwen. Als time-to-market cruciaal is, weegt dat zwaar mee.

• Budget: microservices en serverless vragen meer infrastructuurexpertise en DevOps-inspanning. Dat vertaalt zich altijd naar kosten.

De rol van de software architect in een project.

Een software architect is niet iemand die tekeningen maakt en daarna aan de kant staat. Bij Cube is de architect actief betrokken bij development: mee-reviewen, sparren met het team, bijsturen waar nodig. Wat we als architect doen: de consistentie van technische keuzes bewaken over het hele systeem, functionele eisen vertalen naar technische structuur, anticiperen op schaalproblemen voordat ze zichtbaar worden en grenzen bewaken aan de omvang van technical debt die het systeem met zich meedraagt.

Wat we bewust niet doen: elk implementatie detail bepalen. Goede architectuur schept kaders waarbinnen developers hun beste werk kunnen leveren. Geen dwangbuis, maar een stevig fundament.

Hoe wij bij Cube architectuurkeuzes maken.

We volgen geen architectuurmodes. We kiezen wat past bij het probleem, het team en de tijdshorizon. Wat we altijd doen: de architectuur documenteren. Zodat elk toekomstig teamlid begrijpt waarom keuzes zijn gemaakt. Niet alleen wat het systeem doet, maar waarom het zo is opgezet. Dat bespaart maanden aan onboarding en voorkomt dat waardevolle context verloren gaat.

We voeren ook code reviews en technische architectuur-assessments uit voor bestaande systemen waarbij de opbouw een groeibelemmering is geworden. Soms is de conclusie dat er gerepareerd moet worden. Soms dat er opnieuw gebouwd moet worden. Altijd eerlijk, altijd met een concreet plan.