Microservices, microservices, microservices

Jag var på QCon New York nyligen och ett framstående tema var Microservices. Många stora mjukvaruföretags använding av arkitekturen har mognat. Microservices är intimt sammankopplat med två andra megatrender, DevOps och kontainer-teknologier.

Arkitekturen har starka fördelar när stora team levererar en stor plattform. De olika teamen kan utveckla och leverera de olika delarna utan att vara lika beroende av varandra. Det möjliggör täta releaser och ett arbetsätt som passar företag som driver och utvecklar sin verksamhet med mjukvara.

När man sätter igång med en Microservice-arkitektur finns det många saker att ta ställning till:

**Polygloyta system**
Då en applikation är uppdelad i flera mindre applikationer och tjänster kan dessa vara implementerade i olika ramverk och språk. Detta är en enorm styrka, man kan välja de verktyg som passar bäst för att lösa ett specifikt problem. Tänk dock på följande:

– Använder man olika språk går det inte att dela kod. Vissa saker som är plattformsspecifika, såsom säkerhet och loggning kan vara mycket bra att kunna dela.
– Använder man olika språk är det en större tröskel för personer att byta team.
– Man kan få språk-specifika grupperingar som leder till “vi och dom”-situationer – “äh, men det där är det Java-typerna som sköter, prata med dem…”.

**Standardisering**
Har man många team som bygger microservices kan det i längden vara bra att sätta upp standarder:

– Loggning och övervakning är bra att ha standardiserat, så att man kan följa anrop i systemet. Det kan bli svårt att göra om olika team väljer att göra annorlunda.
– Produktionssättningar och hantering av miljöer har nytta av att standardiseras, så att man enklare t.ex. kan uppdatera olika komponenter.
– Uppdelning av repositorier för källkod. Ska man ha ett repositorie per tjänst, som potentiellt ger väldigt många repositorier, eller försöka göra uppdelningen så man får färre till antalet?

**Avvägningar**
Som med de flesta andra sakerna handlar det som alltid om avvägningar, vilket sätt passar just din organisation som du jobbar i. Skulle ni ha tillräckligt stor nytta av styrkorna som polyglota system kan ge? Är det viktigt att loggning är harmoniserat och standardiserat?

**Bygga själv**
Molnteknologier utvecklas med rasande fart och kommer ständigt med nya funktioner. Förmodligen lönar det sig inte att bygga ett eget system för provisionering av miljöer, utan använda saker som finns). Är man först med det senaste kanske enda alternativet är att bygga prylar själv – åter igen en avvägning att göra.

**Framtiden**
Automatiserad provisionering av miljöer i molnet börjar bli vanligare och vanligare, nästa steg är att köra “Serverless”. Dvs. att inte mickla med servrar, eller kontainrar, utan bara tillhandahålla kod som skall köras. Amazons produkt heter AWS Lambda och Azure tillhandahåller Functions. Koden som körs triggar på händelser i molntjänsten, t.ex. en fil laddas upp eller modifieras i Azure Blob Storage eller ett meddelande dyker upp på Azure Service Bus.

Oavsett om man väljer en microservices-arkitektur och sedan hur man väljer att implementera den så är det viktiga att man gjort val medvetet så man vet vad man tackar ja till och samtidigt nej till.

/Weikko
Systemarkitekt på Dynabyte