Systeemarchitectuur: de blauwdruk achter grote technologie
Elke keer dat je een app opent, geld overmaakt of een video streamt, draait er op de achtergrond een ingewikkeld bouwwerk van servers, software en verbindingen dat naadloos moet samenwerken. Systeemarchitectuur is het vakgebied dat zich bezighoudt met het ontwerpen van dat bouwwerk: welke onderdelen zijn er nodig, hoe communiceren ze met elkaar, en hoe zorg je dat het geheel blijft werken als het aantal gebruikers groeit of er iets stukgaat.
Een handige vergelijking is stadsplanning. Een stedenbouwkundige bepaalt niet zelf welke bakstenen worden gebruikt, maar wel waar de wegen, waterleidingen en elektriciteitskabels lopen, hoe wijken op elkaar aansluiten en wat er gebeurt als één wijk plotseling veel drukker wordt. Een systeemarchitect doet hetzelfde, maar dan voor digitale systemen: niet de precieze programmeercode is de focus, maar de grote lijnen van hoe onderdelen zoals databases, servers en gebruikersinterfaces samenhangen.
Wat is het precies?
Een systeem bestaat meestal uit meerdere componenten: afzonderlijke bouwstenen die elk een taak uitvoeren, zoals het opslaan van gegevens, het verwerken van betalingen of het tonen van een webpagina. Componenten praten met elkaar via interfaces, vaste afspraken over hoe gegevens worden uitgewisseld, vergelijkbaar met een stopcontact dat altijd dezelfde vorm heeft ongeacht welk apparaat je erin steekt.
Architecten werken vaak met lagen: een laag voor wat de gebruiker ziet (de interface), een laag voor de bedrijfslogica (de regels en berekeningen) en een laag voor gegevensopslag. Door deze lagen te scheiden kan een team de ene laag aanpassen zonder de andere te breken.
Een belangrijke keuze is de architectuurstijl. Bij een monolithische architectuur zit alle functionaliteit in één groot, samenhangend programma. Dat is overzichtelijk bij kleine systemen, maar wordt lastig te onderhouden als het groeit: een kleine wijziging kan onverwachte gevolgen hebben elders in de code. Bij microservices wordt het systeem juist opgesplitst in veel kleine, zelfstandige onderdelen die elk apart kunnen worden aangepast, getest en opgeschaald. Dat geeft flexibiliteit, maar voegt ook complexiteit toe: al die kleine onderdelen moeten wel met elkaar blijven communiceren, en dat gebeurt vaak over een netwerk, wat trager en foutgevoeliger is dan communicatie binnen één programma.
Veel moderne systemen zijn bovendien gedistribueerd: ze draaien niet op één machine, maar op tientallen, honderden of duizenden computers tegelijk, vaak verspreid over meerdere datacenters en landen. Dat maakt systemen robuuster tegen uitval van één machine, maar introduceert nieuwe problemen, zoals wat er gebeurt als twee delen van het systeem tijdelijk geen contact met elkaar hebben.
Architectuurontwerp draait uiteindelijk om trade-offs: afwegingen tussen bijvoorbeeld snelheid en betrouwbaarheid, of tussen eenvoud en flexibiliteit. Er bestaat geen universeel beste architectuur; de juiste keuze hangt af van wat een systeem moet doen en onder welke omstandigheden.
Wat wil men ermee bereiken?
Het belangrijkste doel is schaalbaarheid: een systeem moet kunnen blijven werken als het aantal gebruikers of de hoeveelheid gegevens sterk toeneemt, zonder dat alles opnieuw gebouwd hoeft te worden. Daarnaast streeft men naar betrouwbaarheid: het systeem moet blijven functioneren, ook als losse onderdelen falen, bijvoorbeeld door een serverstoring.
Onderhoudbaarheid is een derde doel: nieuwe ontwikkelaars moeten het systeem kunnen begrijpen en aanpassen zonder dat alles vastloopt. Een goed doordachte architectuur bespaart op de lange termijn tijd en geld, terwijl een slecht ontworpen systeem steeds duurder wordt om te onderhouden, iets dat in de sector bekendstaat als technical debt (technische schuld): kortetermijnkeuzes die op termijn extra werk opleveren.
Tot slot spelen veiligheid en kosten een grote rol. Architecten moeten nadenken over hoe gevoelige gegevens worden beschermd en hoe rekenkracht en opslag efficiënt worden ingezet, want elke server die draait kost geld en energie.
Voorbeelden uit de praktijk
Een bekend voorbeeld is Amazon, dat rond 2002 intern besloot dat alle teams hun software alleen nog via strikt gedefinieerde interfaces mochten laten communiceren, in plaats van rechtstreeks in elkaars code te werken. Deze aanpak, later informeel het "Bezos API-mandaat" genoemd, wordt vaak gezien als een vroege stap richting wat we nu een service-georiënteerde architectuur noemen en legde mede de basis voor Amazon Web Services (AWS).
Netflix verhuisde tussen ongeveer 2008 en 2016 stap voor stap van een eigen datacenter met één groot programma naar een architectuur van honderden microservices die draaien op de cloudinfrastructuur van AWS. Deze migratie, uitgebreid gedocumenteerd door Netflix zelf, wordt vaak aangehaald als een van de bekendste praktijkvoorbeelden van grootschalige architectuurverandering.
Google ontwikkelde interne systemen zoals Borg (een systeem voor het beheren van enorme aantallen rekentaken over duizenden machines, voor het eerst publiek beschreven in een onderzoekspaper uit 2015) en Spanner (een wereldwijd gedistribueerde database, beschreven in 2012). Beide zijn schoolvoorbeelden van architectuur die is ontworpen om te werken op een schaal van vele datacenters tegelijk.
Bij CERN, het Europese laboratorium voor deeltjesfysica, ondersteunt het Worldwide LHC Computing Grid sinds de start van de Large Hadron Collider in 2008 de verwerking van enorme hoeveelheden meetgegevens door honderden samenwerkende rekencentra over de hele wereld te verbinden.
NASA ontwerpt voor zijn Mars-missies, zoals de Perseverance-rover die in 2021 landde, boordsystemen die moeten blijven functioneren ondanks extreme vertraging in communicatie met de aarde (tot ruim twintig minuten enkele reis) en zonder mogelijkheid tot snelle reparatie, wat vraagt om architecturen met sterke nadruk op zelfstandige foutafhandeling.
Hoe ver is de techniek?
Systeemarchitectuur is geen nieuwe wetenschap; de basisprincipes bestaan al decennia en worden voortdurend bijgesteld. Wat wel sterk verandert, is de omgeving waarin architecten werken. De opkomst van cloud-native ontwerpen, waarbij software vanaf het begin wordt gebouwd om te draaien op gehuurde cloudinfrastructuur in plaats van eigen servers, heeft de afgelopen tien tot vijftien jaar veel bestaande aannames op zijn kop gezet.
Een recentere trend is serverless computing, waarbij ontwikkelaars geen servers meer beheren maar losse stukjes code laten draaien die alleen actief zijn (en kosten) wanneer ze daadwerkelijk gebruikt worden. Ook edge computing, het dichter bij de gebruiker uitvoeren van berekeningen in plaats van in een ver datacenter, wint terrein, vooral voor toepassingen die met minimale vertraging moeten reageren, zoals bepaalde vormen van sensordata-verwerking.
Toch blijft de praktijk weerbarstig. Veel organisaties kampen met legacy-systemen: oude, vaak matig gedocumenteerde software die nog altijd cruciale taken uitvoert maar lastig te vervangen is zonder risico. Het omzetten van een monolithisch systeem naar microservices klinkt eenvoudiger dan het is; verkeerd uitgevoerd leidt het tot een nog complexer en minder betrouwbaar geheel dan waar men mee begon. Er is dan ook geen consensus dat microservices altijd de betere keuze zijn; voor kleinere organisaties kan een goed onderhouden monoliet juist verstandiger zijn.
Wie werken eraan?
Grote technologiebedrijven als Google, Amazon, Microsoft en Netflix behoren tot de partijen die het meest zichtbaar publiceren over hun architectuurkeuzes, vaak via technische blogs en onderzoekspapers, omdat zij systemen bouwen op een schaal die weinig andere organisaties bereiken.
Op het gebied van standaarden en methodologie speelt The Open Group een rol met TOGAF (The Open Group Architecture Framework), een veelgebruikt raamwerk voor het structureren van architectuurwerk binnen organisaties. Het Software Engineering Institute van Carnegie Mellon University in de Verenigde Staten doet al decennia onderzoek naar softwarearchitectuur en publiceert methoden en analyses die breed worden gebruikt in het vakgebied. De IEEE Computer Society onderhoudt onder meer de ISO/IEC/IEEE 42010-norm, een internationale standaard voor het beschrijven van systeemarchitectuur.
Daarnaast dragen individuele vakexperts en universiteiten wereldwijd bij aan het vakgebied, onder meer via conferenties en publicaties waarin nieuwe ontwerppatronen en lessen uit de praktijk worden gedeeld.