Etter ti år med mikrotjenester gjør sjefsutvikler opp status: Smått er godt, men...

På Øredev-konferansen som gikk av stabelen i Malmø forrige uke, ga Tomer Gabel et tilbakeblikk på de siste fem-ti år med mikrotjenester. Han er sjefsutvikler i den internasjonale eiendomsmeglervirksomheten Wework, som det har vært mye støy omkring.

Mikrotjenester er dagens finkornede utgave av tidligere tiders tjenesteorienterte arkitektur (SOA), som har brutt fortidens systemer ned i mindre deler som er mulig å håndtere.

Det handler i bunn og grunn om skalering, sier Tomer Gabel. Det er enklere å optimalisere små systemer enn ett stort monolittisk serversystem. Det betyr også at om noe er nede ett sted, så forplanter ikke det seg nødvendigvis til resten av systemet.

Som eksempel nevner Gabel et utfall i et Netflix-system som anbefaler innhold til tjenestens seere. Den gikk ned, men brukerne kunne fortsatt se sine yndlingsserier og benytte tjenestens andre funksjoner.

I gammeldagse, monolittiske serversystemer er det ikke like sikkert at et nedbrudd ett sted ikke tar ned andre funksjoner også.

Det er andre fordeler ved mikrotjenester. Man kan bruke flere språk og kjøremiljøer side om side, og kanskje, sier Gabel, er systemene også enklere å teste.

Det handler om mennesker

Men det er slett ikke disse grunnene som ifølge Gabel gjør mikrotjenester til utviklernes favoritt-arkitektur. I virkeligheten handler det nemlig om å skalere organisasjonen og ikke teknologien.

Det er rett og slett for vanskelig å ha et kjempestort utviklingsteam der alle arbeider med én monolittisk applikasjon og datakilde. I stedet bør man ha mange små team, som har hvert sitt produkt og hver sine målsetninger – og det er mye enklere å ha med å gjøre, mener Gabel.

Men ikke alt er fryd og gammen i mikrotjenestenes verden. Nye ideer gir nye problemer, og gamle kjenninger stikker hodet frem igjen.

Over tid blir tjenestene og de produktene de leverer avhengige av hverandre. Det samme gjelder programvareteam. Det gir synkroniseringskostnader, som Tomer Gabel uttrykker det.

De viktigste målepunktene blir alle negativt påvirket av synkronisering, hvor en lang rekke uavhengige tjenester og utviklerteam skal delta i den samme dansen.

Den gode nyheten er at mikrotjenestearkitektur er velegnet til å ordne disse problemer. Det vi ønsker, sier Gabel, er minimale problemer med synkronisering og maksimal uavhengighet mellom systemene.

Det enkel budskap er at «smått er godt». Små systemer er lett for mennesker å få overblikk over. Det betyr små grenseflater mellom tjenestene. API-ene skal ha minst mulig flate.

Unngå problemer med mikrotjenester

Tomer Gabel har et par råd i den anledning. Del aldri datakilder mellom tjenester, lyder formaningen. En delt database betyr at SQL er ett grensesnitt – og av det veldig store og uhåndterlige slaget.

Flere stacker – plattformer og språk – er ikke nødvendig, og ikke ønskelig for din bedrift. Et lite antall stacker minimerer flaskehalser med hensyn til produksjon av kode og funksjonalitet, når utviklerne har de samme ferdigheter.

Konkret mener Gabel at det ikke er behov for mer enn to eller tre stacker i en større virksomhet.

Han har forsket litt på saken, og kommet frem til at Google scorer høyest med seks eller sju stacker i eget hus, mens de fleste andre store IT-virksomheter ligger på de tidligere nevnte to-tre stykk.

En annen innsikt som ifølge Tomer Gabel stammer fra den amerikanske dataforskeren Melvin Conway, lyder slik: Måten en organisasjon snakker sammen på, har en tendens til å avspeile seg i den strukturen som organisasjonens programvaresystemer benytter.

Det kalles «Conways lov». Og det betyr at det er viktig å ha organisasjonens struktur in mente, da den har betydning for hvordan tjenestene og deres relasjoner utkrystalliseres.

Faretegn er som nevnt datakilder som deles av flere tjenester, samt ett system som har flere team som eiere. Her lyder det barske rådet fra Gabel, at man bør omstrukturere organisasjonen hvis man havner i slike situasjoner.

De øvrige anbefalinger er gamle kjenninger, som Gabel også påpeker: Gå etter mange små og hyppige lanseringer, få devops-dydene i fingrene – og automatisering er nøkkelen til et lykkeligere utviklerliv.

Det vi ikke lærte

Det er altså høstet mange konstruktive erfaringer om mikrotjenester de siste 10 årene. Men Tomer Gabel spør retorisk: – Hva har vi ikke lært?

Her peker han på det han kaller for «fysikkens lover». Han refererer til to dataforskere, Leslie Lamport og Eric Brewer, som begge har forsket på distribuerte systemer.

Det er dette som karakteriserer mikrotjenesters natur. Nøkkelen til bedre forståelse av problemet er begrepet «concurrency», det vil si samtidig kjøring av prosesser. Ellers får man inkonsistens i systemer som jobber side om side.

Det er nemlig vanskelig å tenke ut distribuerte systemer på nytt. Og dagens verktøy og metoder kommer haltende etter, er synspunktet. Verktøyene blir riktignok bedre, og det handler for eksempel om «tracing», beregninger og aggregering av logg-filer.

Men det er ikke nok. Man skal vite hva som skal logges, telles og overvåkes, og hvordan det hele gir mening. Det er så å si systemets KPI-er – key performance indicators, som det heter på moderne ledelsesspråk – som skal fastsettes.

Løsningen er events

Vi skal altså minimere synkronisering og maksimere uavhengighet. Det som utviklere og organisasjoner kjemper med, er sikkerhet, skalering og «observability» – evnen til å på en konsis måte å vite hva systemet faktisk foretar seg.

Løsningen er klassikere som køer og busser, men med events – begivenheter – som det sentrale elementet.

Her er idealet, slik Gabel ser det, en modell der man sender ut events som konsumeres via en buss eller kø, som alle systemene er koblet til.

Events kan lagres i den rekkefølgen de oppstår, og som innenfor finans-IT hvor en saldo oppsummeres ved å regne sammen en sekvens med poster, gir en sekvens av events muligheten for å observere og foreta revisjon på sluttresultatet som systemet ender med.

I distribuerte systemer er «eventual consistency» (det at et systems samlede tilstand ikke er kjent på alle tidspunkter) bare ett av livets faktum, noe som er uunngåelig hvis man også skal ha «high availability» – at mange brukere skal ha adgang til systemet og foreta transaksjoner samtidig.

Her er et revisjonsspor viktig hvis feil skal finnes og rettes.

Tomer Gabel mener at et godt programmeringsmønster i denne sammenheng er en «saga», som representerer en enkelt forretningsprosess på høyt nivå, som for eksempel en bruker som booker en flyreise.

Prosessen består av flere kall på et lavt nivå, som fører til at hver tjeneste oppdaterer data. Hvert kall i prosessen kan utføre en handling når anmodningen mislykkes eller sagaen avbrytes.

Sett deg inn i den gjeldende viten på området, lyder Gabels avsluttende formaning til den tettpakkede salen i Malmøs messesenter – som kvitterer med applaus.

Tenk over ditt event-API, det er hardt arbeid

På version2s oppfølgingsspørsmål om hvordan man kan minimere et APIs grenseflate, hvis alle tjenester skal kunne motta alle slags events via en buss, utdyper Gabel:

– Hvis du har bruk for å fange opp alle slags events, betyr det som regel at bruksscenariene er spredt over flere tjenester. Hver tjeneste er i seg selv fortsatt liten. Når det er sagt, så er svaret på spørsmålet om hvordan man minimerer API-ets grensesnitt at det ikke er noen «magic bullet». Du skal være disiplinert og tenke mye over hvordan API-et lages – det er ikke noen annen måte å gjøre det på.

Man skal overveie hva forholdet mellom fordeler og ulemper er, og bruke tid til å tenke over om man virkelig har bruk for en gitt informasjon eller parameter i et kall.

– Og hva konsekvensene er ved å tilføye et parameter. Hvis du føyer noe til systemet ditt, blir det vanskeligere å endre og fjerne på et senere tidspunkt. Derfor er det viktig å overveie hver enkelt del som du tilføyer til grensesnittet ditt. Det er hardt arbeid.

Det betyr likevel ikke at bindinger mellom forskjellige tjenester er dårlig.

– Bindinger er det som gir funksjonalitet i mikrotjenestene dine. Her hjelper events mye. På konsumentsiden betyr det at du kan velge de data som du bruker, uten at produsent-tjenesten som sender data, vet noe om det. Det er fordelen ved å produsere og konsumere events. Konsumentene er uavhengige og behøver ikke å fortelle produsenten at de bruker data. Det er en av de teknikkene som er mest fordelaktige i forbindelse med å redusere sammenkobling mellom systemer, avslutter Tomer Gabel.

Saken ble først publisert på danske Version2/Ingeniøren, og gjøres tilgjengelig på norsk for abonnenter av Digi Ekstra gjennom vår samarbeidsavtale med Teknologiens mediehus/Ingeniøren.