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