Microservices-fælden

De fleste microservices-samtaler starter på samme måde. En grundlægger, en CTO eller en head of platform sidder over for mig og siger en version af: "Vi vokser, så vi har brug for microservices."

De har næsten aldrig brug for microservices. De har brug for et refactor, et par klare modulgrænser, en database der ikke misbruges, og en ærlig samtale om, hvem der er on-call. Det, de blev solgt, var en arkitektur. Det, de rent faktisk har, er et ansættelsesproblem, et coupling-problem eller et udrulningsproblem klædt ud som en arkitektur.

Pitchet er let at falde for, fordi dele af det er sande:

• Uafhængige services, der kan udvikles, udrulles og skaleres separat.
• Teams, der kan vælge det rigtige værktøj til deres service.
• Fejl isoleret til en lille del af systemet.

Regningen, ingen prissætter til dig på forhånd:

• Netværket er ikke din kode. Hvert kald, der plejede at være et funktionskald, er nu en request, der kan time ud, prøve igen og fyre dobbelt.
• Data skal leve et sted. Enten splitter du din database (og mister joins, transaktioner og referentiel integritet), eller du beholder én (og mister halvdelen af pointen med microservices).
• Schema-drift er for evigt. To services på to udgivelses-cyklusser vil komme ud af synk. Du vil skrive en contract test-suite, og du vil hade den.
• Observability er nu et produkt. Tracing, log-korrelation og request-ID'er bliver ikke-til-forhandling-infrastruktur, ikke en nice-to-have.
• Eventual consistency er et UX-problem. Brugere bemærker, når deres kurv er tom i tre sekunder, efter de lagde noget i den.

Næsten alt det, folk vil have fra microservices — rene grænser, parallelt arbejde, evnen til at ræsonnere over en chunk af systemet i isolation — kan du få fra en velstruktureret monolit. Med én database, én udrulning og ét sæt dashboards.

Mønsteret er ligetil:

• Bounded contexts som moduler. Hvert modul ejer sine tabeller, eksponerer et typet interface og rækker aldrig ind i et andet moduls storage.
• Én transaktion på tværs af moduler, når forretningen har brug for det, i stedet for distribuerede sagaer, du re-debugger resten af dit liv.
• Baggrundsarbejde via en tabel-baseret kø, indtil du har en reel grund til at introducere en broker.
• Strikse modul-til-modul-API-tests, så grænserne er reelle, ikke vibes-baserede.

Når du reelt skal udtrække en service, udtrækker du et modul. Grænsen er der allerede, testene er der allerede, og teamet ved, hvad de skærer ud.

De ærlige signaler, der retfærdiggør omkostningen ved at gå distribueret, er:

• Du har mere end ét team, der reelt ejer en slice fra start til slut, inklusive on-call.
• To dele af systemet har forskellige SLA'er. En 99,99 % checkout kan ikke dele udrulningsvindue med en 99 % recommendation engine.
• Du har brug for fejlisolation. Når analyse-pipelinen brænder, skal storefronten blive ved med at sælge.
• Du har reelt divergerende skaleringsprofiler. Én workload er CPU-bound og snakkesalig, den anden er hukommelses-tung og stille.

"Vi vil måske gerne en dag" er ikke på denne liste. Det er "den nye seniorudvikler er vant til det" heller ikke.

Hvis du allerede har arvet et microservices-rod, så big-bang det ikke tilbage til en monolit. Brug det modsatte af, hvordan du kom dertil: en strangler fig i revers. Vælg de to services, der snakker mest sammen. Flyt dem ind i én proces. Slet inter-service-kaldene. Gentag.

Rækkefølgen betyder noget. Start med de services, der deler data, ikke dem der deler en UI. Latency-gevinsterne er øjeblikkelige, de operationelle gevinster vokser, og du stopper med at betale for netværket som en database.