Hvorfor simpel arkitektur altid vinder

For et par år siden blev jeg hentet ind for at kigge på et produkt, der ikke leverede. Teamet havde taget en fungerende monolit — en Rails-app med en Postgres-database, der lavede et par tusinde requests i minuttet — og brugt atten måneder på at splitte den op i fjorten services. De havde Kafka. De havde Kubernetes. De havde et service mesh. Det, de ikke havde, var et fungerende checkout-flow.

Deres arkitekturdiagram var smukt. Deres on-call-rotation var en horror-story. Den oprindelige product owner, der havde specced rebuildet til at starte med, havde sagt op seks måneder inde. Bureauet, der havde solgt dem rebuildet, var rykket videre til næste kunde.

Vi slettede ni services i den første måned. Omsætningen steg. Sider loadede hurtigere. Teamet begyndte at levere igen. Intet af det var klogt. Det var bare mindre.

Kompleksitet er ikke gratis, og den betales ikke én gang. Den betales hver dag, af hver person der skal ræsonnere over systemet. Den vokser eksponentielt.

Hver yderligere service er en ny deploy-pipeline, en ny runbook, et nyt sæt dashboards, et nyt sted en 2-om-natten-page kan komme fra. Hver distribueret transaktion er en ny mulighed for en halvt-skrevet tilstand. Hvert network-hop er latency, du ikke kan optimere væk, fordi netværket ikke er din kode.

Omkostningen er sjældent synlig på arkitekturdiagrammet. Den dukker op i velocity-grafen seks måneder senere og i den udvikler, der i stilhed opdaterer sin LinkedIn ved måned ni.

Simpelt betyder ikke naivt, og det betyder ikke usofistikeret. Det betyder at vælge den mindst komplekse løsning, der opfylder det krav, du rent faktisk har i dag, med en klar vej til det krav, du måske har i morgen.

I praksis ser det som regel sådan her ud:

• Én deploy-unit, indtil andet er bevist. En modulær monolit med klare interne grænser slår et distribueret system, du ikke har organisationen til at drive.
• Kedelig infrastruktur. Postgres. En kø-tabel før en kø-service. En cron før en workflow-engine.
• Kode, en kompetent mid-level kan læse på sin første dag uden en rundvisning.
• Standarder frem for konfiguration. Hver config-knap er en fremtidig bug-rapport.

Simpelt er ikke altid det rigtige svar. Der er reelle øjeblikke, hvor omkostningen ved at forblive simpel er højere end omkostningen ved at splitte op. De ærlige signaler er:

• Uafhængige skaleringsprofiler, der reelt divergerer — fx en lille synkron API foran en tung asynkron ML-pipeline.
• Uafhængige fejl-domæner, hvor én del af systemet skal blive ved med at servere, når en anden er nede (betalinger vs. anbefalinger).
• Uafhængige teams store nok til at eje og drive en service fra start til slut, inklusive on-call-rotation.

Hvis ingen af disse er sande i dag, har du ikke et microservices-problem. Du har et jeg-vil-have-microservices-på-mit-CV-problem, og det er meget dyrt at løse.

Før du tilføjer et nyt stykke infrastruktur — en kø, en cache, en anden service, en event-bus — så besvar fire spørgsmål højt, på skrift, foran de mennesker, der skal drive den:

1. Hvilket konkret problem, observeret i produktion, løser det her?
2. Hvad er det simpleste, der kunne løse det inde i det eksisterende system?
3. Hvem er on-call for denne nye ting kl. 3 om natten, og har de accepteret?
4. Hvordan sletter vi det, hvis vi tager fejl?

Kan du ikke svare på dem, træffer du ikke en arkitektonisk beslutning. Du dekorerer.