Atlassian: van software-spaghetti naar stabiele cloud

Atlassian, bekend van tools als Jira, Confluence en Bitbucket, draait op een interne Platform-as-a-Service (PaaS) genaamd ‘Micros’. Wat ooit begon als een gestroomlijnde manier om AWS-diensten te beheren, groeide uit tot een monster met meer dan 2.000 microservices, 5.000 dagelijkse deployments en miljoenen functies zo meldt het bedrijf in een blog.

Deze exponentiële groei leidde tot wat ingenieurs in de blogpost omschrijven als ‘dependency tangles’ (verstrikte afhankelijkheden). Het gevaarlijkste voorbeeld hiervan zijn circulaire afhankelijkheden: Service A heeft Service B nodig om te starten, maar Service B kan niet draaien zonder Service A.

Het kip-en-eiprobleem

Een concreet voorbeeld uit 2021 illustreert de kwetsbaarheid. Atlassian gebruikte hun eigen dienst Artifactory (een register voor software-pakketten) om applicaties uit te rollen via het Micros-platform. Echter, het Micros-platform zelf was voor zijn eigen updates en werking óók afhankelijk van Artifactory.

"Als beide diensten tegelijk zouden uitvallen, zit je in een onmogelijke situatie," leggen de ingenieurs uit. Je kunt het platform niet herstellen omdat je niet bij de softwarepakketten kunt, en je kunt de softwarepakketten niet herstellen omdat het platform platligt.

Project CPR: De ‘Layer Cake’-strategie

Om dit op te lossen startte Atlassian het CPR-programma. De kern van de oplossing was het herstructureren van de infrastructuur in een zogenaamd ‘Layer Cake’-model (taartpunt-model).

Het principe is simpel maar strikt:

• De infrastructuur wordt verdeeld in lagen, van fundamenteel (AWS, netwerken) tot hoog niveau (Jira, Trello).
• Een laag mag alleen afhankelijk zijn van lagen onder zich.
• Harde afhankelijkheden van hogere lagen of dezelfde laag zijn verboden.

Om dit te realiseren moesten honderden ‘kritieke risico's’ worden geëlimineerd. Een belangrijk onderdeel was de introductie van de Source Control Pillar (SCP). In een noodscenario bleek dat ingenieurs soms niet eens bij hun eigen broncode (in Bitbucket) konden als het netwerk plat lag, omdat Bitbucket zelf afhankelijk was van datzelfde netwerk. De oplossing was een ‘low-level’ mirroring-systeem dat kritieke code direct naar een kale AWS-omgeving kopieert, zodat herstelploegen altijd toegang hebben tot hun tools, zelfs als het eigen platform offline is.

Geen ‘breek het glas’-oplossingen

Een opvallend inzicht uit het project is de afkeer van noodoplossingen die alleen tijdens crises worden gebruikt. "Als je een 'breek het glas'-tool bouwt die je nooit gebruikt, werkt hij waarschijnlijk niet op het moment dat je hem echt nodig hebt," aldus de blog.

In plaats daarvan integreerde Atlassian de noodsystemen in de dagelijkse operatie. De low-level mirroring-tools worden nu dagelijks gebruikt voor standaard deployments, waardoor men zeker weet dat ze functioneren tijdens een echte calamiteit.

Cultuuromslag

Naast de technische ingrepen benadrukt Atlassian de noodzaak van een cultuuromslag. Door middel van grootschalige simulaties (‘tabletop exercises’), waarbij teams een volledige platform-uitval naspeelden, werden ingenieurs zich bewust van de verborgen risico’s in hun ontwerpen.

Het resultaat is volgens Atlassian een platform dat niet alleen stabieler is, maar vooral ‘herstelbaar’. In een wereld waar 100% uptime een utopie is, blijkt de zekerheid dat je na een crash snel en betrouwbaar weer kunt opstarten, de werkelijke waarde van engineering.