Blogg
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Ett de nya modeorden idag kan man väl säga, men vad är det egentligen ? Lyssnade på ett föredrag om detta på javaforum igår som var intressant.
Jag tycker Martin Fowler ger en ganska bra beskrivning
Microservice architectures will use libraries, but their primary way of componentizing their own software is by breaking down into services. We define libraries as components that are linked into a program and called using in-memory function calls, while services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call.
Martin Sjöblom som pratade på javaforum gick ett steg längre och kallade Martin Fowler för sin gud.
Vi har ju under många år jobbat med att skapa tjänstebaserade API-er till hela system men nu handlar det då om att skapa tjänstebaserade gränssnitt mellan olika mindre komponenter inne i systemet. Ungefär som SOA fast i mindre skala.
Vilka fördelar vill man uppnå ?
Oberoende deployment. Ändra ett beroende i maven/gradle för en komponent i din monolit-lösning så får du bygga om och deploya hela din applikation. I en microservice-arkitektur kan du deploya om bara en enskild komponent.
Mer distinkta gränssnitt till en komponent. Personligen har lite svårt att omedelbart förstå den synpunkten, designen respektive dokumentationen av ett API kan ju vara bra eller dålig antingen man använder det som ett library eller service.
Komponenter kan utvecklas med olika teknologi och av olika team. Javisst så är det ju.
Skalbarhet - istället för att behöva duplicera hela monologen över många servrar kan man duplicera bara de komponenter som används mest.
Finns det några nackdelar ? Martin Sjöblom nänmde tex att om man delar upp sin applikation i många fristående komponenter och var och en av dem har en förväntat tillgänglighet på x så blir tillgängligheten på den externa tjänsten de ingående komponenternas dito multiplicerade med varandra och är det många så sjunker det ganska drastiskt.
Remote-anrop mellan fristående komponenter kostar mer än motsvarade inom processen.
Strävan efter att skapa fristående, oberoende, återanvändbara komponenter med glasklar ansvarsfördelning och intuitiva gränssnitt har väl funnits sedan vi började utveckla mjukvara. Kommer microservices att förenkla, förbättra detta ? Kanske, det finns många som hävdar det. Men jag tror fortfarande att den största utmaningen är att hitta vad en komponent skall göra och/eller vilka komponenter man skall ha.