Varför är det så få som lyckas med sin digitala transformation och vad kan man göra för att undvika ett magplask när man dyker ner i den digitala eran? Vad är Mikrotjänster och varför är de så viktiga? I denna artikelserie så tar vi en djupare blick på problemen som kan uppstå och ger dig svaren du letat efter för att lyckas.
Varför är det så få som lyckas med sin digitala transformation och vad kan man göra för att undvika ett magplask när man dyker ner i den digitala eran? Vad är Mikrotjänster och varför är de så viktiga? I denna artikelserie så tar vi en djupare blick på problemen som kan uppstå och ger dig svaren du letat efter för att lyckas.
Del 4: Mikrotjänster- vad är det egentligen och varför det kan hjälpa din organisation?
Mikroservice eller Mikrotjänster på svenska är en av de hetaste trenderna inom applikationsarkitektur – men hur hände det och varför ska du hänga på trenden? Du kanske har klarat dig bra hittills och det känns dyrt och svårt att byta arkitektur. I artikel ger vi dig svar på dessa frågor.
Historia
När man byggde applikationer förr i tiden var det för installation och användning på en enskild dator. I kombination med att de första applikationerna som skapades i slutet av 90-talet var relativt simpla jämfört med vad vi har i dag, resulterade i att man skrev in alla funktioner i själva applikationskoden. I takt med att applikationer blev mer och mer komplexa uppstod det problem. Source-koden växte sig större, mer invecklad och tillslut så pass rörig att det var omöjligt att navigera.
Monolitisk arkitektur
Detta sättet att skriva applikationer kallas idag för monolitisk arkitektur. För att slippa rörig source-kod började man att dela in och organisera koden i olika moduler. Varje unik uppgift som applikationen skulle göra fick en egen modul. Men när man sen installerade applikationer på datorn slogs allt samman till en enda lång kod igen. Installationen utfördes fortfarande via monolitisk arkitektur.
I skiftet från applikationer byggda för skrivbordsdatorer till webbapplikationer installerades den monolitiska koden på en server istället för en unik dator. Det fungerade bra i början, tills att även webbapplikationer började växa sig populära och komplicerade. Problemen uppstod när dessa komplicerade webbsidor behövde bli skalbara och klara av stora fluktueringar i trafik.
Ett exemple
Ta till exempel en sida för e-handel, om det pågår en rea-kampanj eller högtids-säsong kommer trafiken att öka på sajten. Vid ökad trafik behövs fler servrar som skickar ut applikationen via HTML till besökarnas webbläsare. När trafiken går ner igen sjunker också antalet servrar som behövs. Det är här problemen började växa fram. Det är dyrt att ha många servrar, om du ska göra ändringar i koden behöver du installera om hela den stora klumpiga koden igen på alla servrar och testa. Vilket tog tid och resulterade i högre risk för att fel skulle uppstå. Ett annat problem är bara för att trafiken ökar så ökar inte belastningen på alla funktioner i applikationen. Men om du har all kod installerad på varje server kommer du automatiskt lägga ner massor av kraft på att öka kapaciteten på alla funktioner, även om det bara är ett fåtal funktioner som behöver ökad kapacitet.
Lösningen var att dela upp de här stora monolitiska applikationerna till mini applikationer som istället pratade med varandra. Det var så Mikrotjänster arkitektur föddes.
Vad är då Mikroservice arkitektur?
Mikrotjänst arkitektur, vilket är en metod för att bygga en applikation utifrån en uppsättning små tjänster. Varje mikro-tjänst implementerar en specifik domän eller affärsförmåga, var och en är utvecklad autonomt och kan distribueras oberoende. Slutligen bör varje mikrotjänst äga sin relaterade domän datamodell och domänlogik.
För oss är Mikrotjänster lika mycket en organisatorisk och folkorienterad fråga, som det är en fråga om arkitektur. För att lyckas med Mikrotjänster bör man noggrant organisera sig kring affärsmöjligheter. Eftersom slutmålet är användarupplevelse och kundtillfredsställelse, bör team som utnyttjar Mikrotjänsten vara tvärfunktionella team som arbetar för att uppnå en enda funktionalitet
Fördelar med mikrotjänster
Mikrotjänster är utformade för att minimera beroenden mellan varandra, antingen undviker de kommunikation eller gör kommunikationen oberoende av statusen till andra Mikrotjänster. De kommunicerar primärt asynkron med köer, publish and subscribe model eller som händelsestyrd. För att integrera med externa system används ofta API Gateways istället för direkt integration. Molnleverantörer erbjuder sin egen implementering av integrationer och erbjuder ytterligare funktioner som: godkännande och autentisering, svar-cache, lastbalansering, loggning och IP-vitlistning. Det finns en fälla med Gateways eftersom det kan bestå av ett monolitiskt lager. Därför är en bra lösning att installera separat API Gateway-komponent för varje mikrotjänst, vilket skulle säkerställa att teamet som konfigurerar API har end-to-end-kunskap om tjänsten.
Återanvändbar och Kostnadseffektiva
Mikrotjänst arkitektur ger långsiktig smidighet. Mikrotjänster möjliggör en oberoende och autonom livscykel, vilket möjliggör bättre underhåll i komplexa system. Tack vare mikrotjänster kan varje domän skalas, uppdateras och utvecklas separat. Till skillnad från monolitisk arkitektur är mikrotjänster projekt-agnostiska som ger affärsmöjligheter i stället för funktionalitet som är specifikt för ett visst projekt. Detta gör mikrotjänsterna återanvändbara och därmed minskar kostnaderna, eller omvänt, ökar värdet av tjänsterna ni utvecklar. Dessutom är det mycket enklare att bygga upp enskilda tjänster med mikrotjänst arkitektur än monolitisk arkitektur. Detta beror främst på att varje tjänst kan utvecklas, ersättas och skalas individuellt efter behov.
Mikrotjänster är alltså en trend som alla borde hänga på. Det är både bättre för ägaren och kunden, en riktig win-win. I nästa del av denna artikelserie så kommer vi att gå djupare in på ett ämne vi redan har pratat om. Nämligen DevOps och hur du kan utveckla och anpassa med hjälp av Agile Intelligent DevOps och NoOps.
