Go to content
Microservices arkitektur rød header

Lösningsarkitektur

Så bygger ni ett dynamiskt IT-landskap med mikrotjänstarkitektur

Låser ni er verksamhet med arkitekturen?

Med ett evolutionärt förhållningssätt till IT-arkitektur kan ni gradvis integrera nya system. Oavsett om det är system som behöver bytas ut på grund av att de är föråldrade, eller nya system som krävs när kraven på vad systemlandskapen skall innehålla. Det kan t.ex. vara att behovet av ett PIM-system (Product Information Management) uppstår när er e-handelsverksamhet mognar.

Hur ofta implementerar ni ny kod i er IT-setup, i form av produkter, funktioner eller system?

En gång om året? En gång i månaden? Eller en gång i timmen? Om du inte vet kan du nog tänka dig att det är skillnad på att implementera ett års arbete på en gång – eller att göra det kontinuerligt, kanske till och med flera gånger i timmen. Både i förhållande till potentiella fel och medföljande felsökning, och i förhållande till väntetid på utveckling. Det råder ingen tvekan om att de flesta företag föredrar kontinuerliga framsteg och tidiga iterationer som kan kvalitets- och affärstestas mot användare tidigt i processen.

Vad är mikrotjänster?

Mikrotjänster är små fristående mjukvaror, med ett mål: att exekvera kod. Till skillnad från en mjukvarumonolit är exekveringen av processer uppdelad i små oberoende programvaror, som var och en har full autonomi över sin egen process och en tydlig avgränsning av syftet med den specifika processen.

Fördelar med mikrotjänstarkitektur

  • a logic map and a pen icon

    Best Of Breed - programvara - oavsett teknik

    Mikrotjänster tillåter teknologisk mångfald och användning av Best Of Breed - programvara avsett teknik.

  • a raising chart icon

    Byt system kontinuerligt

    Bygg upp er arkitektur på ett sätt som tillåter er att kunna byta ut delar i systemet kontinuerligt med olika frekvens.

  • a magnifying glass diving into three sections icon

    Robusthet – ett fel välter inte lasten

    Genom tydligt definierade gränssnitt kan ett fel separeras från övriga tjänster.

  • a taking off airplane icon

    Prestandaoptimering och skalbarhet

    I motsats till en mjukvarumonolit kan mikrotjänsters prestanda optimeras ända ner till den enskilda tjänsten.

  • a file with a speed watch icon

    Time to market

    Snabb implementering av ny kod och nya funktioner. Med mikrotjänster kan du distribuera den enskilda tjänsten självständigt.

  • people connections icon

    Större effektivitet

    Med mikrotjänster kan ni naturligtvis dela upp ansvaret mellan team, så att mindre team individuellt kan lösa uppgifter från utveckling till driftsättning.

Hur fasar man ut äldre mjukvara med mikrotjänster?

Det finns flera varianter av metoderna nedan, men låt oss hålla oss till de allmänna principerna för ersätta en tjänst eller mjukvara.

 

1 | Bygg en fasad

Det första steget i "strangler fig" metoden är att bygga en fasad som kan ta emot och dirigera anrop till tjänster bakom fasaden. De flesta anrop kommer initialt att gå till monoliten, som sedan hanterar anropen. Genom att etablera en fasad istället för att bara anropa tjänsten direkt kan det finnas två eller flera parallella tjänster som kan ta emot anrop. Mjukvarumonoliten är nu "värden" runt vilken du kan börja etablera en strangler fit arkitektur.

 

2 | Omdirigera anrop till den nya mikrotjänsten

När ni har säkerställt att tjänsten löser en definierad uppgift i monoliten på ett tillfredsställande sätt kan ni dirigera om relevanta anrop i fasaden från den äldre mjukvaran och hantera produktionsanrop till den nya tjänsten istället.

 

3 | Fortsätt att etablera fristående mikrotjänster

Och så fortsätter ni. En process i taget, som ni flyttar ut från er äldre mjukvara och etablerar som en oberoende mikrotjänst.

Utvalda företag som vi har hjälpt med övergångsprocesser / digitala färdplaner för lösningsarkitektur

Vill ni veta mer om era alternativ?