Microservices er et af de senere års mest hypede koncepter inden for systemudvikling. Der findes ikke en autoritativ definition, men typisk forstås microservices som små, uafhængige processer, der hver løser en meget specifik opgave (Single Responsibility Principle) inden for en veldefineret ramme.
Den samlede løsning består af et antal microservices, der er så løst koblede, at man nemt kan udrulle, opdatere, udskifte eller helt slette dem, uden at man er tvunget til at opdatere det samlede system, som det ofte vil være tilfældet i en monolitisk arkitektur. Derudover understøtter microservices agil udvikling, da udviklingen nemmere kan brydes ned i mindre og overskuelige opgaver.
– Principperne bag microservices er rigtigt gode, men det svære er bare at finde ud af, hvilken specifik opgave den enkelte microservice skal løse, og hvordan vi sikrer, at vores microservices ikke vokser til nye monolitter, siger Jeppe Cramon, softwarearkitekt og udvikler hos TigerTeam, blogger og hyppig taler på softwareudviklingskonferencer.
For hårde koblinger
Konceptet er ikke nyt og har historisk set været i spil i forskellige forklædninger helt tilbage til de tidlige objektorienterede programmeringssprog som SmallTalk og i kommunikationsstandarden CORBA. SOA (Service Orienteret Arkitektur) har også som overordnet princip at bundle en række services til en samlet løsning, men har fået et dårligt ry på grund af mange forfejlede implementeringer.
– Princippet med at bygge småt, så man nemt kan udskifte de enkelte dele, giver mange fordele. Men bygger man for småt, ender man med at få for mange hårde koblinger mellem de enkelte services, og så er man lige vidt. Det var det, der skete i mange løsninger baseret på lagdelt SOA, forklarer Jeppe Cramon.
Et eksempel på, at man bygger for småt, kan være, at man lader én service levere et kundenavn, en anden kundens adresse, en tredje kundens telefonnummer og så videre, da det blandt andet giver udfordringer med hensyn til konsistens og reliability.
Kompleksitet i interaktionen
En anden overordnet problemstilling ved at bygge (for) småt består i, at den kompleksitet, man forsøger at komme væk fra i det traditionelle monolitiske system, blot flyttes ud i interaktionen mellem de enkelte services. Hvis man baserer sin løsning på RPC-kald mellem services over netværket, står man hurtigt med de samme koblingsudfordringer, krydret med udfordringer fra et distribueret system som for eksempel reliability, latency, bandwidth og sikkerhed – problemstillinger, man ikke på samme måde skal tage højde for i et monolitisk system. Dertil kommer, at monitorering og fejlfinding på en løsning, der består af et meget stort antal distribuerede services, kan blive meget kompleks. I værste fald kan man ende med at have implementeret en distribueret monolit.
For Jeppe Cramon er det derfor afgørende, at man i analyse- og designfasen får skabt et sundt fundament for løsningen. Her er det vigtigt at blive helt skarp på, hvad en service er, og hvilke services der skal stilles til rådighed.
– For mig er en service ”den tekniske autoritet for en given forretningsevne (business capability)”, hvor ”forretningsevne” skal forstås som de kerneforretningsevner, en given virksomhed har, siger han og giver som eksempel et forsikringsselskabs forretningsevner såsom salg, policeadministration, fordringshåndtering, risikovurdering og så videre.
Pointen er, at hvis man skal opnå stabile services, bliver man nødt til at lade dem spille sammen med stabile koncepter i virksomheden eller domænet. En service definerer således en logisk afgrænsning og indkapsler forretningsevnen gennem dens fysiske implementering, der for eksempel kan opfyldes ved hjælp af en eller flere microservices. Indkapslingen af forretningsevnens detaljer er det, der er med til at sikre løs kobling og uafhængighed mellem services.
Derfor bør man udvikle services, der er så små som muligt, men samtidigt store nok til, at de kun i minimalt omfang afhænger af andre microservices for at kunne udføre deres arbejde. Services kan på den måde betragtes som selvstændige systemer og microservices som autonome implementeringskomponenter, der tilsammen sørger for, at det givne system kan levere den ønskede funktionalitet.
Koblinger inden for servicen
Microservices handler om at deploye softwarekomponenter uafhængigt af hinanden, men ifølge Jeppe Cramon skal man ikke med vold og magt splitte ting ad, som naturligt er koblet til hinanden - så microservices behøver ikke nødvendigvis være specielt små.
– Don’t split the atom! Der er nogle ”naturlove” i software, som man ikke kan komme uden om, hvis der skal være sammenhæng i løsningen. Hvis man arbejder med en servicearkitektur, er det meget vigtigt, at den nødvendige information og logik findes inden for en given service og ikke skal skabes ved service-til-service-kald, siger Jeppe Cramon.
Han ser UI Composition som en bedre måde at skabe de nødvendige koblinger på, så de ikke opstår mellem services. Her er det i brugergrænsefladens layout, at de enkelte services bliver bragt ind i en for brugeren logisk sammenhæng, ved at de bidrager med deres egne afkoblede UI-komponenter.
Conway's Law
Ud over de rent design- og systemmæssige udfordringer peger Jeppe Cramon på en organisatorisk udfordring: Løsninger baseret på microservices bliver også ramt af Conway's Law, som siger, at virksomheder uvægerligt vil udvikle systemer, der afspejler virksomhedens egen organisation.
– I de fleste virksomheder bliver de enkelte udviklingsteams dannet omkring et system eller et projekt og ikke omkring services, som for mig ville være det optimale, siger han og fortsætter:
– En af de afgørende grunde til, at SOA fejlede, var, at de fleste overså, at for at opnå alignment mellem forretningen og it bliver man nødt til at kigge på hele organisationen og ikke kun på teknikken. For mig er microservices blot en Service Oriented Delivery-tilgang. Så alt det, der gik galt for SOA, kan lige så hurtigt gå galt for microservices, hvis man ikke kigger på naturens love og indretter sig efter dem.