På Øredev-konferencen, der løb af stablen i Malmø i sidste uge, gav Tomer Gabel et tilbageblik på de seneste fem-ti år med mikrotjenester. Han er ledende udvikler i den ombruste internationale ejendomsmægler-virksomhed Wework.
Mikrotjenester er dagens finkornede udgave af tidligere tiders tjenesteorienterede arkitektur (SOA), der har brudt fortidens systemer ned i mindre dele, som er til at håndtere.
Det handler i bund og grund om skalering, siger Tomer Gabel. Det er nemmere at optimere små systemer end ét stort monolitisk serversystem. Det betyder også, at et nedbrud et sted ikke nødvendigvis forplanter sig til resten af systemet.
Som eksempel nævner Tomer Gabel et udfald i et Netflix-system, der anbefaler indhold til tjenestens seere.
Den gik ned, men brugerne kunne stadig se deres yndlingsserier og benytte tjenestens andre funktioner.
I gammeldags, monolitiske serversystemer er det ikke helt lige så sikkert, at et nedbrud et sted ikke lægger andre funktioner ned.
Der er andre fordele ved mikrotjenester. Man kan bruge flere sprog og afviklingsmiljøer side om side, og måske, siger Tomer Gabel, er systemerne også nemmere at teste.
Det handler om mennesker
Men det er nu slet ikke disse grunde, der ifølge Tomer Gabel gør mikrotjenester til udvikleres favorit-arkitektur. I virkeligheden handler det nemlig om at skalere organisationen og ikke teknologien.
Det er ganske simpelt for svært at have ét kæmpe udviklingshold, hvor alle arbejder med én monolitisk applikation og datakilde. I stedet bør man have mange små teams, der har hver sit produkt og hver sine målsætninger, og det er meget nemmere at have med at gøre, mener Tomer Gabel.
Men ikke alt er fryd og gammen i mikrotjenesternes verden. Nye ideer giver nye problemer, og gamle kendinge stikker hovedet frem igen.
Over tid bliver tjenesterne og de produkter, de leverer, afhængige af hinanden. Det samme gælder software-teams. Det giver ‘synkroniseringsomkostninger,’ som Tomer Gabel udtrykker det.
De vigtigste målepunkter bliver alle negativt påvirket af synkronisering, hvor en lang række uafhængige tjenester og udvikler-hold skal deltage i den samme dans.
Den gode nyhed er, at mikrotjeneste-arkitektur er velegnet til at ordne disse problemer. Det, vi ønsker, siger Tomer Gabel, er minimalt besvær med synkronisering og maksimal uafhængighed mellem systemerne.
Det simple budskab er, at ‘småt er godt’. Små systemer kan overskues af mennesker. Det udmønter sig i små grænseflader mellem tjenesterne. API’erne skal have den mindst mulige flade.
Undgå bøvl med mikrotjenester
Tomer Gabel har et par gode råd i den anledning. Del aldrig datakilder mellem tjenester, lyder formaningen. En delt database betyder, at SQL er en grænseflade – og en meget stor og uhåndterlig en af slagsen.
Flere stakke – platforme og sprog – er ikke nødvendigt, og ikke ønskværdigt for din virksomhed. Et lille antal stakke minimerer flaskehalse i forhold til produktion af kode og funktionalitet, når udviklerne har de samme færdigheder.
Konkret mener Tomer Gabel, at der ikke er behov for mere end to eller tre stakke i en større virksomhed.
Han har researchet lidt på sagen og er kommet frem til, at Google scorer højest med seks eller syv stakke i eget hus, mens de fleste andre store it-virksomheder ligger på de førnævnte to-tre stykker.
En anden indsigt, som ifølge Tomer Gabel stammer fra den amerikanske datalog Melvin Conway, lyder således: Måden, som en organisation snakker sammen på, har en tendens til at afspejle sig i den struktur, som organisationens software-systemer benytter.
Det kaldes ‘Conways lov’. Og det betyder, at det er vigtigt at have organisationens struktur in mente, da den har betydning for, hvordan tjenesterne og deres relationer udkrystalliseres.
Faretegn er som nævnt datakilder, der deles af flere tjenester, samt ét system, der har flere teams som ejere. Her lyder det barske råd fra Tomer Gabel, at man skal omstrukturere organisationen, hvis man ender i disse situationer.
De øvrige anbefalinger er gamle kendinge, som Tomer Gabel også påpeger: Gå efter mange små og hyppige releases, få devops-dyderne op under neglene, og automatisering er nøglen til et gladere udvikler-liv.
Det, vi ikke lærte
Der er altså høstet mange konstruktive erfaringer om mikrotjenester i de seneste 10 års tid. Men Tomer Gabel spørger retorisk: Hvad har vi ikke lært?
Her peger han på, hvad han kalder for ‘fysikkens love.’ Han refererer til to dataloger, Leslie Lamport og Eric Brewer, der begge har forsket i distribuerede systemer.
Det er det forhold, der karakteriserer mikrotjenesters natur. Nøglen til bedre forståelse af problemet er begrebet ‘concurrency’ – samtidig afvikling af processer. Ellers får man inkonsistens i systemer, der arbejder side om side.
Distribuerede systemer er nemlig svære at tænke på. Og dagens værktøjer og metoder halter bagefter, lyder synspunktet. Værktøjerne bliver dog bedre, og det handler eksempelvis om ‘tracing’, metrikker og aggregering af log-filer.
Men det er ikke nok. Man skal vide, hvad der skal logges, optælles, overvåges, og hvordan det hele giver mening. Det er så at sige systemets KPI’er – key performance indicators, som det hedder på moderne management-sprog – der skal fastsættes.
Løsningen er events
Vi skal altså minimere synkronisering og maksimere uafhængighed. Det, som udviklere og organisationer kæmper med, er sikkerhed, skalering og ‘observability’ – evnen til på en koncis måde at vide, hvad systemet faktisk foretager sig.
Løsningen er klassikere som køer og ‘busser’, men med events – begivenheder – som det centrale element.
Her er idealet, som Tomer Gabel ser det, en model, hvor events udsendes og konsumeres via en bus eller kø, som alle systemerne er koblet til.
Events kan gemmes i den rækkefølge, de opstår, og ligesom i finans-it, hvor en saldo opsummeres ved at sammenregne en sekvens af poster, giver en sekvens af events muligheden for at observere og foretage revision på det slutresultat, som systemet ender med.
I distribuerede systemer er ‘eventual consistency’ (det forhold, at et systems samlede tilstand ikke er kendt på alle tidspunkter) bare et af livets fakta, som er uundgåeligt, hvis man også skal have ‘high availability’ – at mange brugere skal tilgå systemet og foretage transaktioner samtidig.
Her er et revisionsspor vigtigt, hvis fejl skal findes og rettes.
Tomer Gabel mener, at et godt programmeringsmønster i denne sammenhæng er en ‘saga’, der repræsenterer en enkelt forretningsproces på højt niveau; som for eksempel en bruger, der booker en flyrejse.
Processen består af flere kald på et lavt niveau, der fører til, at hver tjeneste opdaterer data. Hvert kald i processen kan udføre en handling, når anmodningen mislykkes, eller sagaen afbrydes.
Sæt dig ind i den gældende viden på området, lyder Tomer Gabels afsluttende formaning til den tætpakkede sal i Malmøs messecenter, der kvitterer med klapsalver.
Tænk over dit event-API – det er hårdt arbejde
På Version2’s opfølgende spørgsmål om, hvorledes man kan minimere et API’s grænseflade, hvis alle tjenester skal kunne modtage alle slags events via en bus, uddyber Tomer Gabel:
»Hvis du har brug for at indfange alle slags events, betyder det som regel, at brugsscenarierne er spredt over flere tjenester. Hver tjeneste er i sig selv stadig lille. Når det er sagt, så er svaret på spørgsmålet om, hvordan man minimerer API’ets grænseflade, at der ikke er nogen ‘magic bullet’. Du skal være disciplineret og tænke meget over, hvorledes API’et fremstilles – der er ikke nogen anden måde at gøre det på.«
Man skal overveje, hvad forholdet mellem fordele og ulemper er, og bruge tid på at tænke over, om man virkelig har brug for en given information eller parameter i et kald.
»Og hvad konsekvenserne er ved at tilføje en parameter. Hvis du føjer noget til dit system, bliver det sværere at ændre eller fjerne på et senere tidspunkt. Derfor er det vigtigt at overveje hver enkelt del, som du tilføjer til din grænseflade. Det er hårdt arbejde.«
Det betyder dog ikke, at bindinger mellem forskellige tjenester er noget skidt.
»Bindinger er det, som giver funktionalitet i dine mikrotjenester. Her hjælper events meget. På konsument-siden betyder det, at du kan vælge de data, som du bruger, uden at producent-tjenesten, der fremsender data, ved noget om det. Det er fordelen ved at producere og konsumere events: Konsumenterne er uafhængige og behøver ikke at fortælle producenten, at de aftager data. Det er en af de teknikker, som er mest fordelagtig i forbindelse med at reducere sammenkobling mellem systemer,« slutter Tomer Gabel.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
