OXX liker makrotjenester

Skrevet av Morten Felumb

‍

Tjenesteorientert arkitektur

‍‍

I dag er det utenkelig å lage forretningsapplikasjoner som ikke er tilrettelagt for integrasjoner med andre applikasjoner og systemer. Løsningen skal gjerne bestå av løst koblede tjenester som gjør det enkelt å skalere, utvide og distribuere funksjonalitet.

‍

Vi har blitt så vant til at alt kan kobles sammen at vi tar det for gitt, spesielt i web-bransjen. De åpne standardene er modne, og skybasert infrastruktur kombinert med robuste sikkerhetsmekanismer gjør det mulig å opprette tjenesteintegrasjoner på tvers av de fleste systemer.

‍

Men selv om teknologien er på plass er det utfordrende å bygge en tjenestearkitektur som lar oss oppnå forretningsmålene til riktig pris.

‍

Mikrotjenester er vanskelige greier‍

‍‍

Prinsippet med mikrotjenester er at mange små og løst koblede tjenester spiller sammen på tvers av teknologier og miljøer. Hver tjeneste er kun ansvarlig for en liten og klart avgrenset oppgave. Teknologiske byggeklosser som kan settes sammen til hva som helst. Evangelistene lover uendelig skalerbarhet, kort utviklingstid og uslåelig tilpasningsdyktighet.

‍

Dette er enkelt og lekkert på tegnebordet, men blir ofte komplisert å håndtere i praksis. Mange mikrotjeneste-prosjekter feiler på grunn av urealistiske forventninger.

‍

ChatGPT lister opp noen utfordringer

‍‍

• Systemoversikt og eierskap. Etter hvert som antallet mikrotjenster øker, og brukes i ulike sammenhenger, blir det vanskelig å holde oversikten. Hvem bestemmer hvordan systemet skal fungere og hvordan fordeles eierskap og ansvar.
  ‍
• Datahåndtering og konsistens. Utfordrende å sørge for god datakvalitet på tvers av løst koblede systemer. Synkroniseringsprosesser er langsomme og ressurskrevende.
  ‍
• Sikkerhet og tilgangskontroll. Tjenestene må implementere et felles sett av regler og mekanismer som sørger for at data sikres mot uautorisert tilgang og angrep. Endringer må koordineres på tvers av alle tjenestene.
  ‍
• Versjonering og breaking changes
  Tillegg av ny funksjonalitet er ofte uproblematisk, men endring av eksisterende endepunkter og datastrukturer krever nye API-versjoner. Ettersom det ofte ikke er mulig å oppgradere alle tilknyttede tjenester og applikasjoner samtidig blir det nødvendig å støtte flere versjoner samtidig.

‍

‍Hva er Makrotjenester?

‍

‍Makrotjenester er et relativt nytt begrep som illustrerer punktet mellom monolittisk arkitektur og mikrotjenester. De fleste er enige om at monolittisk arkitektur bare bør velges i spesielle situasjoner, og stadig flere mener det er vanskelig og kostbart å bygge og vedlikeholde mikrotjenestesystemer. Makrotjenester gjør det mulig å gradvis forme en effektiv tjenestearkitektur, uten å måtte satse på en altoppslukende prosess hvor resultatet er uforutsigbart.

‍

I OXX har vi utviklet makrotjenester i årevis. For oss som har jobbet lenge med utvikling har denne tilnærmingen til tjenestearkitektur vært naturlig. En typisk kunde hadde gjerne et monolittisk system. Vår utfordring ble å modernisere dette med muligheter for parallellskalering og integrasjoner mot andre systemer og applikasjoner. Vi fikk sjelden anledning til å bygge hele systemet på nytt, så det mest rasjonelle var å vurdere hvordan systemet kunne deles opp i logiske moduler, som deretter ble til makrotjenester.

‍

Denne illustrasjonen viser hvordan man kan bryte ned en applikasjon i stadig mindre tjenester, hvor ytterpunktet er serverløse nanotjenester – kun én funksjon per tjeneste.

‍

‍

‍

‍

‍Splitt og hersk når det lønner seg

‍

Ta utgangspunkt i de grunnleggende reglene for objektorientert programmering. Ved å følge SOLID-prinsippene kan man starte med å utvikle en tradisjonell applikasjon, og gradvis skille ut deler av koden til makrotjenester når det virker fornuftig.

‍

Etter hvert som systemet vokser, eller bruksmønsteret endres, kan man velge å splitte noen av makrotjenestene til mikrotjenester - dersom fordelene overgår ulempene. Det er til og med mulig å rulle tilbake fra mikrotjenester til makrotjenester.
‍

Ikke velg arkitektur av prinsipielle årsaker. Legg til rette for rasjonelle valg underveis.

‍

‍

Kilder:

ChatGPT

NordicAPIs.com

Wikipedia

‍