Hva er microservices?

Microservices er et av de mest omtalte begrepene i moderne systemutvikling, og et av de mest misforståtte. Det fremstilles noen ganger som den selvsagte måten å bygge på i dag. Sannheten er mer nyansert. Her ser vi på hva microservices faktisk er, og når de er verdt kostnaden.

Definisjonen

Microservices, eller mikrotjenester, er en arkitektur der et system deles opp i mange små, selvstendige tjenester. Hver tjeneste har sitt eget, avgrensede ansvar (én tar seg av betalinger, en annen av brukerkontoer, en tredje av varsler), og de produksjonssettes hver for seg og kommuniserer med hverandre over nettverket.

Nøkkelordet er selvstendig. Hver tjeneste kan utvikles, rulles ut og skaleres uavhengig av de andre. De er som et lag av spesialister som hver gjør sin del og snakker sammen, i stedet for én stor generalist som gjør alt.

Det høres tiltalende ut, og i riktig sammenheng er det det. Men for å forstå når det passer, må man vurdere det opp mot alternativet.

Kontrasten til monolitten

En monolitt er det motsatte: et system som bygges, testes og produksjonssettes som én enhet, der all koden hører sammen i én kodebase. Der monolitten er en sammenhengende helhet, er microservices et nettverk av deler.

Forskjellen er ikke at den ene er moderne og den andre utdatert. Det er to måter å organisere det samme på, med ulike avveiinger: Monolitten er enkel å bygge, kjøre og feilsøke på ett sted, mens microservices gir uavhengighet til prisen av at helheten spres ut over mange bevegelige deler.

Hva du vinner

Fordelene med microservices er reelle, og de dreier seg om uavhengighet.

• Uavhengige utrullinger. En enkelt tjeneste kan oppdateres og rulles ut uten at hele systemet berøres. En liten feil i varslingstjenesten krever ikke at alt annet testes på nytt og produksjonssettes igjen.
• Skalering per del. Trenger bare én funksjon mye kraft, kan akkurat den tjenesten skaleres for seg, mens resten får være i fred. Det kan være mer ressurseffektivt enn å skalere hele systemet.
• Parallelt arbeid. Ulike team kan eie hver sin tjeneste og jobbe samtidig uten stadig å tråkke i hverandres kode.

For en stor organisasjon med mange team som skal kunne jobbe uavhengig av hverandre, er dette en betydelig gevinst, og ofte den egentlige grunnen til å velge microservices i det hele tatt.

Hva du betaler

Uavhengigheten er ikke gratis, og prisen betales i kompleksitet.

Ti tjenester er ti ting som kan gå i stykker hver for seg, alle med egen overvåking. Det som i en monolitt bare var et funksjonskall, blir nå nettverkstrafikk som kan mislykkes eller bli forsinket. Og fordi flyten slynger seg gjennom flere deler, blir det vanskeligere å se hvor noe har gått galt. Dette er håndterbart (store selskaper gjør det daglig), men det krever arbeid og kompetanse som må være på plass.

Når du ikke bør begynne her

Den viktigste innsikten er at microservices oftere løser et organisatorisk problem enn et teknisk. Har du ikke det problemet, betaler du for en løsning du ikke trenger.

Tommelfingerregelen er tydelig: Små team og tidlige produkter bør sjelden begynne med microservices. Et ungt system som fortsatt leter etter formen sin, eller et som drives av noen få personer, har best av å holdes enkelt. Start med en velstrukturert (gjerne modulær) monolitt, og skill ut tjenester først når et reelt behov tvinger det frem, for eksempel mange team eller deler med helt ulike krav. Å dele opp for tidlig er en av de vanligste og dyreste arkitekturfeilene.

Ønsker dere en nøytral vurdering av hva akkurat systemet deres trenger, drøfter vi i Weapp gjerne arkitekturen sammen med dere før dere bygger.