Sådan erstatter du legacy software med microservice arkitektur trin for trin
Artiklen er en basisindføring i en af flere metoder for at udfase eller migrere funktioner fra legacy software. Mange virksomheder, blandt andre en del af Novicells kunder, benytter allerede nedenstående metoder, men vi opfordrer hermed flere til at komme i gang.
“Almost all the successful microservice stories have started with a monolith that got too big and was broken up.”
Martin Fowler
en af verdens ledende kompetencer på microservices og en fremtrædende forfatter på området
Fra legacy software til microservice arkitektur
I de fleste virksomheder findes der ét stykke software, som ingen tør røre ved. Det er elefanten i IT-afdelingen. Den varme kartoffel på direktionsgangen. Men også hængelåsen til den magiske port, de kalder digital transformation og automatisering i stor skala. Det er software-monolitten, der bare er vokset og vokset indtil ingen ved præcis, hvad den indeholder, og endnu mindre hvordan den nogensinde skal kunne udfases. Årsagen er typisk en eller flere af følgende:
- Den kan være vagt dokumenteret fra start, og de tre udviklere bag løsningen har for længst forladt organisationen.
- Den kan være skrevet i et kodesprog, der sidenhen er dødt.
- Den kører på hardware, der nåede end of life, for en generation siden, og derfor ikke længere bliver vedligeholdt af leverandøren.
- Eller den kan være blevet overmåde kompleks gennem årene, mens forskellige udviklere har lagt kodelinje på kodelinje ind i en voksende pukkel af teknisk gæld.
Legacy softwaren er på én gang forretningskritisk og samtidig en blokering for forretningsudvikling. Den dræner jeres dyre IT-ressourcer, og tynger tungt på jeres konkurrencekraft.
Men hvad gør du ved det?
Først kigger vi på, hvad der kendetegner en legacy software-monolit og hvilke ulemper, der kendetegner den. Derefter forklarer vi, hvordan du gennem tre enkle trin kan udfase legacy softwaren og erstatte den med langt mere fleskible og fremtidssikrede microservices.
Hvad er en software-monolit?
En software-monolit er en softwareløsning, der udfører flere processer omkring et eller flere forretningsdomæner. Monolit er afledt af et geologisk udtryk for en stor massiv klippe. Det henviser til, at softwaren fungerer som en stor massiv enhed. Typisk vil software-monolitten være et stykke skræddersyet software eller et stykke kommerciel (licenstungt) standardsoftware, der er tilpasset til at løse større eller mindre dele af virksomhedens forretningslogik. Det kan fx være:
- ERP-systemet (Enterprise Resource Planning)
- Ecommerce-platformen
- CRM-platformen (Customer Relationship Management)
- CMS´et (content management system)
- eller et hav af branche- og forretningsspecifikke systemer.
Men forretningslogik er dynamisk. Logik i softwaren er typisk statisk.
Når du videreudvikler dit IT-landskab for at bevare et 1-1 forhold mellem forretningsprocesser og processer i softwaren, der løser dem, opstår der teknisk gæld. Teknisk gæld er quick fix løsninger, som laves i systemet, som gør det sværere og dyrere at lave større omlægninger og opdateringer af systemer fremadrettet. Det er en naturlig udvikling, når forretningen vokser og udvikler sig. Men videreudvikling på større software systemer er komplekst, og tilhørende teknisk gæld kan give en række følgeudfordringer, som kan være svære for forretningen at leve med. Derfor er legacy software-monolitter ofte en barriere i mange virksomheder.
3 ulemper ved legacy software-monolitter
1. Lang time-to-market på nye features, produkter og processer
Hvis du laver en kodeændring i en software-monolit, skal hele løsningen deployes, uanset hvor lille ændringen er. Da deploys til større systemer altid vil være store deploys på grund af omfanget af kode, der skal deployes, vil det ofte involvere et vist element af risiko og potentiel nedetid. Det betyder i praksis, at der i mange organisationer vil være langt mellem deploys for at minimere risici. Men med længere tid mellem deploys vil der også være flere og større ændringer, der skal deployes, og det betyder større risiko for modstridende kodelinjer og dermed fejl.
Mange store software-monolitter får således kun deployed ny kode 1-4 gange om året. Det er fordi hele monolittens kode skal deployes hver gang, og det kan betyde nedetid på et stort forretningskritisk system. Desuden er det svært at fejlfinde, når mange nye kodelinjer lægges ind med hvert deploy og potentielt påvirker hinanden, når de lægges i drift.
2. Langsom adoption af ny teknologi
Med en monolit er det svært at idriftsætte og teste et nyt kodesprog, databasetype eller framework, fordi en ændring i systemet påvirker hele systemet. Det låser ikke bare din adoption af ny teknologi og nye systemer, men kan også være en hindring for rekruttering af IT-kompetencer, hvis du sidder med en monolit, der er kodet på en døende teknologi. Vi vender tilbage til, hvordan man i praksis bygger teknologi-heterogenitet ind i landskabet.
3. Svært og dyrt at performance-optimere en software monolit
Det er ikke muligt fokuseret at skalere performance på de elementer af løsningen, der har behov for det, da hele monolitten skal skaleres, når der er brug for øget performance. Ellers opstår der flaskehalse i systemet og mulige nedbrud eller datatab. Det kan være særligt kritisk for ecommerce-applikationer, som oplever meget stærke trafikstigninger i forbindelse med Black Friday og andre kampagner, som kan forårsage nedbrud på hele løsningen. Selvsagt vil de automatiserede skaleringsmuligheder, der ligger i Amazon Web Services eller Microsoft Azure, være svære eller umulige at udnytte optimalt med et sådant setup. Det kan derfor være dyrt at drifte en software-monolit, der altid skal kunne yde til et højt niveau og have en oppetid på mange 9-taller efter kommaet
Nem integraton af nye systemer med en microservice-arkitektur
Idriftsættelse af ny kode eller et nyt system bør være så udramatisk, at det ikke kræver opmærksomhed.
Med en microservice-arkitektur kan du gradvist integrere nye systemer. Uanset om det er systemer, der trænger til udskiftning på grund af forældelse, eller nye systemer, der kræves efterhånden som kravene til dit setup ændres. Det kunne være, at behovet for et PIM-system (Product Information Management) opstår, efterhånden som din ecommerce-forretning modner. Du kan sågar indfase systemet gradvist for at sikre, at overgangen sker så udramatisk som overhovedet muligt.
Hvordan indfases ny software i dit IT-landskab med microservices?
Lad os tage ovennævnte eksempel med et PIM-system, der skal indfases i et ecommerce setup som det centrale system for alle produktdata. Tricket her er IKKE at integrere direkte til det nye PIM-system, men lave en såkaldt facade, som definerer kaldet. Med en facade kommunikerer det øvrige IT-landskab med PIM-systemet via facaden. Det giver et fast element, som services kan integrere op imod, uanset hvad der ligger bag facaden. Det giver mulighed for at fjerne så meget logik som muligt fra integrationen, og dermed lave en løs kobling mellem services og systemer. Den ene service er så at sige ligeglad med, hvor facaden dirigerer kaldet hen, og hvordan det afvikles, så længe svaret passer ind i et fast defineret endpoint, som er facaden. Det er en klar styrke, fordi du som ovenfor beskrevet bygger din infrastruktur op til at optimere mod afvikling og udvikling af infrastrukturen. Det kaldes evolutionary architecture.
Hvordan udfases legacy software med microservices?
Der er flere variationer af nedenstående metode, men for at gøre forklaringen simpel, så lad os holde os til det overordnede princip for udskiftning af en service eller et stykke software. Metoden som vi gennemgår herunder kaldes strangler fig (kvælerfigentræ) metoden. Det kommer af en figensort, der kendetegnes ved at vokse tæt omkring en værtsplante. Figentræet bruger værten til at kravle op ad for at komme op i lyset over trækronerne. Mens planten vokser, omfavner eller ”kvæler” den sin værtsplante, hvoraf navnet er opstået. Nogle værtsplanter lever i symbiose med kvælerfignen, mens andre dør, fordi figentræet gradvist tager lyset fra værtsplanten. Det kan lede til en figenplante, der står tilbage som et hylster, fordi værtsplanten er rådnet væk i midten. Det er her navnet stammer fra, og nu skal du høre hvorfor.
Trin 1: Byg en facade
Første skridt i strangler fig metoden er at bygge en facade, der kan tage imod og dirigere kald til services bag facaden. De fleste kald vil i starten gå til monolitten som så vil afvikle kaldet. Ved at etablere en facade i stedet for blot at kalde servicen direkte, kan der være to eller flere parallelle services, som kan tage imod kald. Software-monolitten er nu ”vært”, som du kan begynde at etablere en strangler fig arkitektur omkring, for nu at holde os til symbolikken.
Nu kan du begynde at flette forretningsprocesser ud af din legacy software og etablere dem som selvstændige services. Det kan være mere eller mindre komplekst, og det kan være hensigtsmæssigt at starte med en service, der ikke er bundet ind i alt for mange andre processer, da det vil være mindst risikofyldt. Selvom værdien af at flette en mere indviklet proces ud er mere åbenlys, kan det være gavnligt at gøre det i trin fra mindre komplekst til mere komplekst for at få prøvet strangler fig metoden og microservices af på lavrisikoprocesser. Det ser således ud:
Ved at gøre det sådan, kan du risikofrit etablere en service i dit produktionsmiljø uden at forbinde den til noget. Du kan nu begynde at afvikle testkald til den nye service, og du får sikkerhed for, at servicen opfører sig som den skal i produktionsmiljøet.
Trin 2: Omdirigér kald til den nye microservice
Når du har sikret dig, at servicen løser en afgrænset opgave i monolitten tilfredsstillende, kan du omdirigere relevante kald i facaden fra legacy softwaren og afvikle produktionskald til den nye service i stedet.
Trin 3: Forsæt med at etablere selvstændige microservices
Og sådan fortsætter du. En proces ad gangen, som du flytter ud af din legacy software og etablerer som en selvstændig microservice.
Hvornår stopper migrationen mod en ny arkitektur?
Måske er det dit mål helt at udfase legacy software og lade den nye strangler fig-arkitektur stå alene. Eller det kan være, at du lader legacy softwaren stå tilbage på lige fod med den nye arkitektur, så den blot fungerer som én service blandt mange.
At bevæge sig væk fra en monolitisk infrastruktur er ikke et mål i sig selv, men ofte et ønske, der opstår som følge af en række prioriteringer, som ikke kan løses med en tæt koblet infrastruktur. Hvis du bevæger dig frem som beskrevet her, så er du godt på vej mod at bygge et nyt IT-landskab, der giver dig en eller flere af de unikke fordele, som en microservice-arkitektur tilbyder.