Monolitt eller microservices?

Få tekniske valg har blitt så betente som monolitt mot microservices. Microservices har i mange miljøer blitt sett på som det moderne, selvsagte valget, og monolitten som noe man må unnskylde. Virkeligheten er mer nøktern. For de fleste organisasjoner er en godt bygd monolitt ikke bare tilstrekkelig, men det klokere valget. Her er beslutningen avdramatisert, uten arkitekturmote.

Hva forskjellen faktisk innebærer

En monolitt er et system som bygges, testes og produksjonssettes som én enhet. All koden bygges samlet. Det gjør den enkel å forstå, kjøre lokalt og feilsøke: Alt finnes på ett sted.

Microservices, eller mikrotjenester, deler i stedet systemet opp i mange små, selvstendige tjenester som kjører hver for seg og kommuniserer over nettverket. Hver tjeneste kan utvikles, produksjonssettes og skaleres uavhengig. Det høres befriende ut, og for den riktige organisasjonen er det det. Men uavhengigheten har en pris som sjelden nevnes i begeistringen.

Den reelle prisen for microservices

Når microservices selges inn, handler det om skalerbarhet, uavhengige team og teknisk frihet. Det som utelates, er driftsregningen, og den er betydelig.

• Drift og overvåking. Hver tjeneste trenger egen produksjonssetting, logging og overvåking. Ti tjenester betyr ti ting som kan gå i stykker hver for seg, midt på natten.
• Nettverket som feilkilde. Kall som i en monolitt bare er et funksjonskall, blir nå nettverkstrafikk som kan være treg, mislykkes eller komme i uventet rekkefølge.
• Koordinering mellom team. Dette er den største og mest undervurderte kostnaden. Flere tjenester og team må holde grensesnitt og versjoner i takt. Det som var en samtale over pulten, blir en kontrakt mellom systemer.

Poenget er ikke at dette er umulig å håndtere. Store organisasjoner gjør det hver dag. Poenget er at det er reelt arbeid og reell kompleksitet, og at den kostnaden må kunne begrunnes med et faktisk behov, ikke med at arkitekturen er på moten.

Den moderne anbefalingen: modulær monolitt først

Pendelen har svingt tilbake, og rådet fra erfarne folk er i dag tydelig: Start med en modulær monolitt, og skill ut tjenester når organisasjonen krever det.

En modulær monolitt gir deg det beste fra begge verdener til å begynne med. Du bygger tydelige interne moduler med rene grenser, den samme ordenen og separasjonen som microservices lover, men produksjonssetter alt som én enhet og slipper nettverket mellom delene. Skulle en modul senere trenge å stå på egne ben, kan den skilles ut nettopp fordi grensene allerede er trukket.

Skaleringsmyten

Det sterkeste argumentet for microservices er skalering, og samtidig det mest misforståtte. Sannheten er at de aller fleste systemer aldri når den trafikken som ville ha gjort oppdelingen verdt det.

Et konkret eksempel: Et selskap bygde tolv microservices fra start «for å kunne skalere», for et produkt som ennå ikke var lansert. De brukte måneder på infrastruktur og koordinering i stedet for på funksjoner, og da trafikken kom, kunne én eneste monolitt ha håndtert den uten å blunke. En monolitt skalerer nemlig langt ved rett og slett å kjøre i flere kopier bak en lastbalanserer.

Når microservices faktisk er riktig

Dette betyr ikke at microservices er feil, bare at de oftere løser et organisatorisk problem enn et teknisk. Den reelle gevinsten kommer når dere har mange team som må kunne jobbe og produksjonssette uavhengig av hverandre uten å tråkke i hverandres kode. Da er det verdt prisen å dele opp systemet, for alternativet er at alle venter på alle.

Andre reelle grunner er deler med helt ulike behov: en tung beregning som må skaleres for seg, eller en komponent med krav som ikke skal smitte over på resten. Poenget er at beslutningen skal drives av et behov dere faktisk har, ikke av en tenkt fremtid. Og siden en modulær monolitt kan deles opp senere, taper dere sjelden noe på å vente til behovet er reelt.

La problemet velge arkitekturen

Den nøkterne holdningen er at arkitektur er et middel, ikke et mål. Spør hvilket problem dere prøver å løse før dere velger form. Er svaret «vi trenger kanskje å skalere en dag», holder det lenge med en velstrukturert monolitt. Er svaret «fem team snubler over hverandre hver dag», kan oppdelingen være verdt strevet.

Riktig arkitektur er den som passer organisasjonen deres og den faktiske belastningen dere har, ikke den som ser mest moderne ut på et arkitekturdiagram. Vil dere ha et nøytralt blikk på hva akkurat systemet deres trenger, drøfter vi i Weapp gjerne arkitekturen og kan gå gjennom valgene med dere før dere bygger.