Hva er micro services?

En micro service en liten web service som er spesialisert til å gjøre én ting. Her forklares det grundigere hva som er egenartet for denne varianten av web services.

Om SOAP og REST

For å forstå hvordan begrepet micro service vokste frem, må vi ta et steg tilbake og se på utviklingen av web services. Det finnes to hovedkategorier av web services: REST og SOAP. I begynnelsen var SOAP den dominerende. Dette fordi den vokste ut av objektorientert programmering. Objektorientert programmering var populært fordi man kunne lage objektet, f.eks. bil, og gi det egenskaper (som farge, motor, dører, pris). SOAP var utviklet av store aktører som IBM, Microsoft og Oracle, med Microsoft i spissen. Dette var i en tid da deres hegemoni var på sitt største. REST, på sin side, var utviklet av forskere i CERN, altså det samme teamet som sto bak WWW. Det tok betydelig med tid før teknologien festet seg i forretningstradisjonen. At den fikk grep, skyldtes primært:

  • Den var mye enklere å bruke og implementere
  • Det var helt åpen og uavhengig av leverandør, og enkelt å benytte på tvers av tjenester
  • Den var intuitiv å forstå og bruke

Om ESB og tette koblinger

Så i den gamle SOAP tiden var integrasjon mye mer overlatt til eksperter. Integrasjoner gjerne samlet i en kjerne som ga sentral kontroll. Disse kjernene ble gjerne kalt Enterprise Service Bus (ESB) eller tjenestebuss. (Disse skiller seg fra UiOs bruk av termen i sin integrasjonsarkitektur, der ESB/tjenestebuss bare betyr at tjenesten er sentralisert). ESB-en tilbød standardiserte integrasjonsgrensesnitt (API), som konsumentene kunne koble seg opp mot. I SOAP var integrasjoner bygget som kommandoer med argumenter, slik man kjenner fra kommandolinjeprogrammer. For å gjøre det enklere å integrere ble det gjerne laget egne API-programmer som kjørte på klienten. På samme måte var det flere API på bussen som delte biblioteker med programkode. Slik kunne man gjenbruke kode og spare utviklingsarbeid. Men det medførte også tette  koblinger. Tette koblinger vil si at hvis man endrer noe i produsent eller API, må det også samtidig endres i konsumenten. Dvs at hvis man f.eks. oppgraderte en database fra  versjon 8 til 9, så måtte man også oppgradere biblioteket i bussen til å reflektere dette. Siden dette biblioteket kunne være delt med et annet API, hvor databasen ennå ikke var oppgradert, måtte det håndteres, eller også ville det API-et knekke. Videre måtte klienten/konsumenten oppgradere sitt bibliotek. Men hvis konsumenten benyttet begge API-er, altså både det som var oppgradert til verskjon 9 og det som ennå var på versjon 8, var dette ofte ofte umulig å samkjøre. Uansett var det komplisert.

REST ikke krever noe API-spesifikk program på konsumenten. Men REST kan ennå benytte delte biblioteker og ha de samme utfordingene i en ESB. En micro service deler ikke biblioteker med andre API. Det er noe av det som gjør den til en micro service. Man kan gjøre endringer uten at det affekterer noen andre API.

Om ESB og voksesmerter

ESB-er hadde/har mye funksjonalitet. De kan se hvor en datapakke skal ved å se på overskrifter, de kan konvertere formater og protokoller, sette sammen data mm. Dette medførte at man etter hvert fikk en lock in situasjon mot sin egen ESB. Den ble veldig dyr å skifte ut. Dessuten medførte kompleksiteten i ESB-en at integrasjoner krevde høy grad av spesialkompetanse, men ble sårbare på turn-over, og det tok lang tid å integrere. Videre har gjerne en ESB mye annen logikk. Dvs. vurderinger som :"Først skal jeg gjøre det, og hvis svaret er A, så skal jeg gjør ditt, mens hvis svaret er B, så skal jeg gjøre datt". Denne type logikk kalles orkestrering. Det er som dirigenten av et orkester, som forteller medlemmene i ensemblet hva de skal gjøre. Et micro service landskap, derimot, er bygget på at alle vet bare hva en selv skal gjøre. Vi sier da at løsningen er koreografert. Dette etter dans, der det ikke er noen dirigent, men hver danser kjenner sin egen rolle. Løsningene kan naturligvis kombineres. Hovedsaken er at man unngår en endringshemmende lock in situasjonen som oppstår, dersom man orkestrerer mye logikk i en programvaretjeneste.

Om sentraliserte komponenter i et micro service landskap

For å lage oversikt og forenkle administrasjon og tilgang, er micro service landskap gjerne samlet bak såkalte en API Manager (også kjent som API Gateway eller API Gatekeeper). Foruten å hjelpe konsumenter med å finne frem til de data denne trenger og utstede adgangsbevis, vil API Gatewayen holde orden på hvem som benytter hvilke data. Slik kan man nå ut til konsumenter i god tid om endringer i API. Når API endres må konsumenten endre i sin ende. Vanligvis løses dette ved versjonering. Det innebærer at man kjører gammelt og nytt API parallelt i en periode (f.eks. 3 eller 6 mnd), hvilket gir konsumenten mulighet til selv å finne et passende tidspunkt å flytte over til det nye API-et.

Oppsummert

En micro service har tre hovedkatekteristika:

  • Den er så liten, intuitiv/selvforklarende, og brukes til et spesielt formål
  • Den har ingen kodeavhengigheter til andre tjenester
  • Den er en del av en koreografert løsning

 

 

 

Publisert 30. mai 2017 12:38 - Sist endret 7. juni 2017 12:44