Written by:
Last Published:
01. september 2026
•
Infrastruktur er dyrt. Økonomiafdelingen markerer kvartalsregningen. Du kigger på posten (primært leverandørlicenser) og tænker: Hvad nu hvis vi bare skrev det hele om?
Handler et casestudie om modernisering af legacy-systemer altid om dyre omskrivninger? Nej.
En maritim kommunikationsplatform, Sedna, beviste det. Gennem en trinvis tilgang, der holdt teamet slankt og risikoen håndterbar, skar de infrastrukturudgifterne med 80 %. Ingen flerårig omskrivning. Ingen udskiftning af alt det gamle til fordel for noget helt nyt. I stedet en gennemgribende refaktorering af de systemer, der gjorde mest ondt.
Det er dette, de CTO'er, vi kender, rent faktisk har brug for at høre. Ikke enterprise-konsulenternes drejebøger eller "best practices" destilleret fra tusindvis af virksomheder. Du har brug for at høre den virkelige historie: hvad der ændrede sig, hvorfor det virkede, og hvad du bør gøre først.
Lad os tale om Sednas tilgang, de tekniske beslutninger, der betød noget, og hvordan du gennemfører din egen modernisering uden at sætte hele virksomheden på spil.
Kort fortalt: Legacy-modernisering er processen med at refaktorere forældede systemer (typisk monolitter med teknisk gæld eller platforme, der er stærkt afhængige af leverandører) for at reducere omkostninger, forbedre skalerbarhed og genvinde teknisk autonomi. Det er ikke en total omskrivning, men en strategisk opgradering.
Tænk på det som at renovere et gammelt hus i stedet for at rive det ned. Du forstærker fundamentet, udskifter ledningsnettet og bevarer selve strukturen. Bygningen forbliver beboelig under hele processen. Du behøver ikke flytte ud, mens ombygningen står på.
I softwaremæssige termer betyder det, at man tager de systemer, som ens team er afhængige af (typisk dem, der er dyre at vedligeholde eller køre), og moderniserer dem trinvist. Du kan udskifte et dyrt tredjepartsværktøj med egen kode, eller du kan flytte arbejdsbelastninger fra dedikeret infrastruktur til serverless. Måske kan du blot rydde op i den tekniske gæld, der har hobet sig op gennem fem år.
Dette er vigtigt, fordi det adskiller sig fra, hvad de fleste virksomheder forsøger. En fuld omskrivning forudsætter, at du har tid og budget til at sætte alt andet på pause. En "lift-and-shift" til skyen forudsætter, at din arkitektur passer direkte ind i AWS. Modernisering er mere støjsvag og iterativ. Det giver dig mulighed for at bevise værdien, før du forpligter dig til milliardinvesteringer i næste fase.
Sedna udviklede maritime kommunikationsprodukter (Stream og Pulse), der hjælper teams inden for shipping og forsyningskæder med at koordinere. (Se hele casestudiet.) Det involverede et voksende produkt, et voksende team, voksende kompleksitet... og en voksende regning.
Smertepunktet var Tray.io, en tredjepartsplatform til workflow-integration, som udførte vigtigt arbejde, såsom at forbinde eksterne systemer, behandle data og orkestrere den forretningslogik, der kørte mellem tjenesterne. Men i takt med at virksomheden skalerede, steg licensomkostningerne også. Flere workflows betød højere gebyrer, mere kompleksitet betød mere indviklede Tray.io-konfigurationer, og en større vedligeholdelsesbyrde for det centrale ingeniørteam.
Men her er fælden: arbejdsgangene lå uden for kodebasen. De eksisterede i Tray.io's brugerflade, så udviklerne kunne ikke versionsstyre dem, teste dem i CI/CD eller gennemgå dem i pull requests. Hvis noget gik i stykker, kunne driftsteamet ikke bare rulle en udrulning tilbage, men man var nødt til at logge ind på leverandørens platform og fejlfinde direkte i produktionen.
Så Sedna stod over for det spørgsmål, som de fleste virksomheder i vækst møder: Skal vi bare acceptere omkostningerne og komme videre, eller skal vi bruge seks måneder på at løse det?
De valgte det sidste. Men de kastede sig ikke direkte ud i en fuld migrering. De optimerede først.
Den første fase af Sednas modernisering var strategisk optimering (strømlining af eksisterende Tray.io-arbejdsgange og eliminering af unødvendig kompleksitet før enhver omskrivning). Dette betalte sig selv hjem og mindskede risikoen ved migreringen.
De fleste virksomheder springer dette trin over. De ser omkostningerne, ser en potentiel løsning og satser alt. Det gjorde Sedna ikke. De brugte fire uger på at gennemgå deres Tray.io-arbejdsgange, fjerne overflødige trin, konsolidere lignende mønstre og presse platformen maksimalt.
Gevinsten var øjeblikkelig. Licensomkostningerne faldt blot ved at drive en mere effektiv forretning. Udviklingsteamet fik praktisk erfaring med arbejdsgangene (hvad der fandtes, hvad der var i stykker, og hvad der rent faktisk betød noget). Og vigtigst af alt fik de et bevis på konceptet. Da ledelsen så de tidlige besparelser, blev forretningsgrundlaget for fase 2 indlysende.
Dette er den første regel for modernisering: optimer før du migrerer. Det koster mindre, mindsker risikoen for den næste fase og giver dig ofte nok luft i budgettet til, at du ikke er i kriseberedskab, mens du genopbygger centrale systemer.
Sedna byggede en skræddersyet løsning hostet på AWS ved hjælp af Lambda-funktioner til orkestrering af arbejdsgange, hvilket erstattede Tray.io's leverandørplatform med egen kode, der blev udrullet via CI/CD og Terraform. Resultatet var fuldt kodeejerskab, versionsstyring, testbarhed og en reduktion af infrastrukturudgifterne på 80 %.
Migreringen blev udført med omhu. Sedna hentede specialister ind (en backend-udvikler og en full-stack-udvikler fra Imaginary Cloud) sammen med deres kerneteam for at flytte arbejdsgange fra Tray.io til AWS Lambda trin for trin.
Her er arkitekturen: hver Tray.io-arbejdsgang blev til et sæt Lambda-funktioner. AWS Step Functions orkestrerede pipelinen (håndtering af genforsøg, fejlhåndtering og tilstandsovergange). Selve funktionerne var ren JavaScript, gemt i Git, versionsstyret og testet ligesom enhver anden kode.
Denne ændring gav tre umiddelbare fordele:
- For det første, omkostninger. En serverless-model betyder, at du betaler for udførelsestid, ikke for faste licenser.
- For det andet, ejerskab. Arbejdsgange ligger nu i din kodebase, kan gennemgås i pull requests og testes før produktion.
- For det tredje, hastighed. Når udviklingsteamet vil lancere en ny funktion, bliver de ikke bremset af at skulle vente på en Tray.io-arbejdsgang designet af en driftsmedarbejder.
Resultatet var en reduktion på 80 % af, hvad Sedna brugte på leverandørlicenser og relateret infrastruktur. Men vigtigere end selve tallet var, at teamet havde genvundet sin autonomi.
Omkostningsreduktion ved modernisering af legacy-systemer kommer typisk fra tre håndtag: eliminering af dyre tredjepartsværktøjer, flytning af arbejdsbelastninger til serverless-økonomi og omfordeling af ingeniørkapacitet fra vedligeholdelse til nye funktioner.
Da forståelsen af disse håndtag er grundlaget for at opbygge din egen moderniseringsstrategi, vil vi gennemgå dem ét efter ét.
Tray.io udførte et vigtigt stykke arbejde, men det var også en fast omkostning, der skalerede med kompleksiteten. Flere arbejdsgange betød højere omkostninger. Og mere avanceret brug betød et dyrere abonnement. Platformen blev en begrænsning for, hvor meget integration virksomheden havde råd til.
Ved at migrere til AWS Lambda skiftede Sedna fra at "betale for funktioner" til at "betale for udførelse". En arbejdsgang, der kører 100 gange om dagen, koster næsten ingenting. En arbejdsgang, der kører en gang i timen, koster næsten det samme. Du betaler for det forbrugte compute, ikke for en leverandørs produktniveau.
Dette er det første håndtag: Gennemgå hvilke tredjepartsværktøjer der er dyre og proprietære kontra billige og standardiserede. Din identitetsudbyder? Sandsynligvis pengene værd. Din orkestrering af arbejdsgange? En kandidat til at blive flyttet in-house.
Lambdas prismodel kan umiddelbart virke afskrækkende. Det føles dyrt pr. kørsel, men det er yderst fordelagtigt ved store mængder. Hvis du kører tusind workflow-eksekveringer om dagen, er Lambda billigere end en dedikeret server.
Pointen er denne: Serverless eliminerer de faste infrastrukturudgifter. Du betaler ikke for computerkraft, uanset om dine workflows kører eller ej. En tirsdag morgen, hvor der er stille, betaler du stort set intet. En fredag eftermiddag, når integrationerne kører for fuld kraft, skaleres omkostningerne i takt med efterspørgslen.
For Sedna betød det et skift i omkostningsstrukturen fra månedlige licenser til cloud-betaling efter forbrug. Resultatet? En besparelse på 80 %.
Her er det skjulte håndtag, som økonomiafdelinger ofte overser. Da workflows lå i Tray.io, skulle driftsteamet administrere, overvåge, fejlfinde og opdatere dem, hver gang integrationerne ændrede sig.
Med Lambda bliver alt dette kerneteamets ansvar. Og fordi det ligger i Git, er versionsstyret og testbart, er det faktisk mindre arbejde. Ingeniørteamet gik fra at "vedligeholde en leverandørplatform" til at "eje en kodebase". Teamets tid gik fra at være reaktiv – altså at fikse ødelagte integrationer – til at være proaktiv ved at levere nye funktioner.
Sednas engagement omfattede én backend-udvikler og én full-stack-udvikler i cirka seks måneder, hvilket er en reel omkostning. Men gevinsten var varig, da kerneteamet blev permanent frigjort.
Sedna migrerede deres workflow-orkestrering fra Tray.io til AWS Lambda ved hjælp af JavaScript og Kotlin, containeriserede funktioner for portabilitet og byggede CI/CD-pipelines med Terraform. Skiftet fra en leverandørplatform til egen kode gav dem ejerskab og skalerbarhed.
Lad os dykke ned i, hvordan de rent faktisk gjorde det, for det tekniske mønster er afgørende.
Tray.io-workflows var monolitiske (store konfigurationer, der udførte flere ting i rækkefølge). Lambda-workflows er granulære. Hvert trin bliver til en funktion.
Forestil dig dette: Kundedata ankommer. En Lambda-funktion validerer dataene. Hvis de er gyldige, indlæser en anden funktion dem i databasen. Hvis de er ugyldige, logger en tredje funktion fejlen og giver besked til driftsteamet. AWS Step Functions orkestrerer denne pipeline ved at beslutte, hvilken funktion der skal køre næste gang baseret på outputtet fra den forrige.
Hvorfor dette mønster? Testbarhed. Hver funktion er lille, har én opgave og kan enhedstestes isoleret. En udvikler kan køre npm test lokalt og verificere logikken før udrulning. Hvis du prøver det med et Tray.io-workflow, ender du med at skulle fejlfinde i produktion.
Backend: JavaScript på Lambda. Ren Node.js uden leverandørspecifikke frameworks. Hvis Sedna nogensinde får brug for at migrere væk fra AWS, kan funktionerne køre overalt, hvor Node.js understøttes.
Infrastruktur: AWS Lambda til beregning, Step Functions til orkestrering, RDS eller DynamoDB til data, API Gateway til eksterne integrationer.
Deployment: Terraform til infrastructure-as-code (reproducerbar, versionsstyret). GitHub Actions til CI/CD. Når en udvikler pusher en opdatering til et workflow, kører pipelinen tests, og hvis de godkendes, deployes der til produktion.
Overvågning: CloudWatch til logs, X-Ray til distribueret sporing. Når et workflow fejler, kan driftsteamet præcist se, hvilken funktion der fejlede, og hvorfor.
Her er de udfordringer, Sedna stødte på og løste.
Cold starts. Lambda-funktioner tager et øjeblik om at starte, når de aktiveres efter inaktivitet. For workflows, der skal reagere øjeblikkeligt, betyder det noget. Sedna afbødede dette med provisioned concurrency på kritiske stier. Man betaler lidt ekstra for at holde funktionerne varme. Det er det værd for latency-følsomme integrationer.
Tilstandshåndtering. Workflows er tilstandsbevarende. De skal huske, hvilket trin de er nået til, og hvilke data de behandler. Lambda er tilstandsløs. AWS Step Functions håndterer dette ved at gemme workflow-tilstanden i sin egen database. Det er pålideligt, men det er endnu en tjeneste, man skal sætte sig ind i.
Fejlhåndtering. I Tray.io var workflow-fejl ofte lydløse eller uigennemskuelige. I Lambda skal man eksplicit definere logik for genforsøg, dead-letter queues og fejlmeddelelser. Sedna indbyggede dette i deres Step Functions-skabelon. Hvert workflow får den samme strategi for genforsøg (tre forsøg, eksponentiel backoff), medmindre andet er angivet.
Test før produktion. Det er her, Lambda for alvor skinner. Sednas team skriver nu tests til workflows ligesom til enhver anden kode. Før et deploy kører de hele pipelinen mod staging-data. Det er langsommere end Tray.io's brugerflade, men det er langt mere pålideligt.
Før du antager, at Lambda er løsningen på alt, lad os tale om begrænsningerne.
Langvarige processer. Lambda har en timeout på 15 minutter. Hvis din arbejdsgang stadig kører efter 15 minutter, har du brug for en anden arkitektur (Fargate, Kubernetes, traditionelle VM'er).
Arbejdsbelastninger med høj volumen og ekstremt ensartet mønster. Hvis du behandler 10 millioner hændelser om dagen med en fuldstændig forudsigelig belastning, kan en dedikeret server eller en Kubernetes-klynge være billigere end serverless. Regnestykket ændrer sig, når din arbejdsbelastning er så ensartet, at du altid betaler for din minimumskapacitet.
Applikationer med høj grad af tilstand (stateful). Lambda er tilstandsløs (stateless). Hvis din arbejdsgang skal vedligeholde en kompleks tilstand på tværs af trin, flytter du den byrde over på en database eller en ekstern lagerløsning. Det virker, men det øger kompleksiteten.
Sednas arbejdsgange, såsom integrationer mellem eksterne systemer, var perfekte til Lambda. Sporadiske, kortvarige og hændelsesstyrede. Hvis din profil er anderledes, bør du dykke ned i prissammenligningen.
De fleste moderniseringsprojekter går i stå på grund af menneskelige beslutninger, såsom "rip-and-replace" uden test, ignorering af ny leverandørafhængighed, undervurdering af teamets kapacitet, "scope creep" og manglende succeskriterier. Faseopdelte tilgange med klare milepæle forhindrer alle fem.
Fristelsen er stor: "Lad os skrive det hele om i [ny teknologi]." Det føles renere, hurtigere og mere tilfredsstillende end gradvis refaktorering.
Sedna afviste dette. Fase 1 (optimering) validerede forretningscasen og mindskede risikoen for fase 2. Da ledelsen så de tidlige besparelser, var argumentet for migrering indlysende. Da teknikteamet stødte på implementeringsproblemer, havde de konkrete data til at justere kursen.
Hvis du springer direkte ud i en fuld omskrivning, satser du virksomhedens fremtid på et tidsestimat lavet af folk, der aldrig har gjort præcis dette før. Start småt, test en enkelt arbejdsbelastning, og bevis, at det virker.
Du slap af med afhængigheden af Tray.io, men nu er du afhængig af AWS.
Dette er en reel bekymring, men den er håndterbar. Sednas tilgang: containerisér funktionerne (Docker), brug standardbiblioteker (Node.js, ingen AWS SDK i kernelogikken), og undgå AWS-specifikke tjenester, hvor det er muligt. Hvis AWS nogensinde bliver problematisk, kan funktionerne køre på Google Cloud Run eller Azure Functions med minimale ændringer.
Forskellen på god og dårlig afhængighed er portabilitet. God afhængighed betyder, at du bruger en tjeneste (AWS Lambda), som flere udbydere tilbyder. Dårlig afhængighed betyder, at hele din forretningslogik afhænger af et leverandørspecifikt API, som du ikke kan genskabe andre steder.
Dit kerneteam har travlt, fordi de leverer funktioner, retter fejl og svarer kunder. Nu vil du også have dem til at modernisere infrastrukturen?
Det virker ikke, og du risikerer at ende med halvfærdig kode, overskredne deadlines og et kerneteam, der er for stresset til at tænke klart. Sedna hentede i stedet specialister fra Imaginary Cloud ind i seks måneder. De arbejdede sammen med kerneteamet, opbyggede mønstrene, og derefter overtog kerneteamet ansvaret.
Hvis I gør dette in-house uden ekstern hjælp, så afsæt et budget til det. Dedikér ingeniører til moderniseringen. Bed ikke folk om at gøre det ved siden af deres øvrige opgaver.
Sedna holdt fokus. Fase 1 optimerede den eksisterende Tray.io-opsætning. Fase 2 migrerede workflows til Lambda. Det var det. Først efter begge faser var gennemført, tilføjede de nye funktioner (workflow-versionering, understøttelse af alle teams, funktion til afsendte beskeder).
Hvert nyt element i projektets omfang øger risikoen. Hold din modernisering fokuseret. Du kan godt levere funktioner og tekniske forbedringer i samme sprint, men lad dem ikke blive filtret sammen.
Definér på forhånd: Hvad måler I? Omkostning pr. workflow? Latens? Fejlrate? Timer brugt på vedligeholdelse?
Sedna havde klare måltal. Omkostningsreduktion (mål: 70 %, opnået: 80 %). Tid til implementering af et nyt workflow (før: flaskehals i driften, efter: samme dag). Fejlrate (opretholdt, derefter forbedret). Når du kan henvise til disse tal, har du beviset til det næste moderniseringsinitiativ.
Start med en 4-ugers audit: kortlæg alle legacy-systemer, identificér omkostningsdrivere og teknisk gæld, og prioritér efter effekt og risiko. Pilotér derefter en enkelt arbejdsbyrde ved at bevise omkostningsbesparelser og teknisk gennemførlighed, før I skalerer.
Hvis du mener det seriøst med modernisering, er her den konkrete køreplan, som Sedna fulgte, tilpasset jeres kontekst.
Gør dette først. Spring det ikke over.
Lav en liste over alle legacy-systemer, tredjepartsværktøjer og integrationer, som jeres forretning er afhængig af. Registrér følgende for hvert punkt: årlige omkostninger, timer brugt på vedligeholdelse og kritikalitet (kan vi undvære det? Blokerer det for produktfunktioner?).
Gennemfør denne audit på tværs af engineering, drift og økonomi. Du vil blive overrasket over, hvad du finder – såsom gamle kontrakter, der stadig betales, værktøjer ingen kan huske formålet med, eller infrastruktur, der kører den samme arbejdsbyrde to gange, fordi ingen har dokumenteret det.
Leverance: En prioriteret liste over kandidater til migrering. Brug denne matrix: omkostningseffekt (høj/medium/lav) vs. teknisk risiko (høj/medium/lav). Start med høj omkostning + lav risiko. Undgå høj omkostning + høj risiko, indtil du har bevist, at tilgangen virker.
Resultat ved udgangen af uge 4: Opbakning fra ledelsen. I ved, hvad I moderniserer, og hvorfor.
Mens I planlægger migreringen, så pres det eksisterende system. Fjern overflødige workflows (som i Sednas tilfælde), refaktorér dyre forespørgsler, opgradér forældede afhængigheder, og slet kode, som ingen har rørt i to år.
Denne fase er ikke prangende, men det er her, de fleste virksomheder finder 20–30 % i omkostningsbesparelser uden nogen form for risiko. Og det beviser over for forretningen, at modernisering er en reel mulighed.
Leverance: Første omkostningsreduktion. Tidlig fremdrift. Bevis på, at dit team kan eksekvere.
Mens du optimerer, skal du planlægge migreringen af din pilot-arbejdsbyrde.
Vælg en arbejdsbyrde med højt afkast, men lav risiko. For Sedna var dette workflow-orkestrering: vigtigt for forretningen, men isoleret fra kerneproduktet. Lad være med at bruge din hoveddatabase eller dit autentificeringslag som pilotprojekt. Vælg noget, der er selvstændigt.
Proof of concept: Migrér ét workflow fra start til slut. Mål: omkostninger, latenstid, fejlrate, tidsforbrug for teamet. Virker den nye tilgang? Er den billigere? Er den hurtigere? Dokumentér mønsteret.
Team: Seniorarkitekt og specialister (hvis du henter ekstern hjælp) plus ét kerneteammedlem. Personen fra kerneteamet lærer mønsteret og overtager ansvaret, når specialisterne er færdige.
Leverance: En valideret tilgang. Omkostningsmodel. Tidsplan for fase 2. Bevis for, at dette vil fungere i praksis.
Resultat ved udgangen af uge 12: Grønt lys til at migrere alt det resterende.
Replikér pilotmønsteret på tværs af alle arbejdsbyrder. Etapevis udrulning: shadow (nyt system kører sideløbende, output ignoreres), derefter canary (5 % af trafikken går til det nye system, 95 % til det gamle), og til sidst fuld overgang (al trafik til det nye system).
Kør det gamle og det nye system sideløbende i to uger. Hvis noget går galt, er rollback øjeblikkelig – du skal blot skifte trafikken tilbage. Dette sikkerhedsnet er den kortsigtede operationelle kompleksitet værd.
Leverance: Alle arbejdsbyrder migreret. Omkostningsmål nået. Nul produktionshændelser.
Modernisering er ikke slut, når du har migreret alt. Den er først slut, når du har optimeret det nye system og høstet gevinsterne.
Overvåg CloudWatch, omkostningsallokering og performance-baselines. Finjustér: reserveret kapacitet til forudsigelige arbejdsbelastninger, arkitektoniske justeringer baseret på produktionsmønstre samt funktionsønsker, der nu er mulige (Sedna tilføjede workflow-versionering og understøttelse af nye beskeder her).
Dokumentér hvad der virkede, hvad der ikke gjorde, og mønstre til den næste modernisering.
Uge 4: Go/no-go baseret på audit. Er der en tilstrækkelig økonomisk gevinst til at retfærdiggøre indsatsen? Er teamet enige?
Uge 12: Go/no-go baseret på pilotresultater. Virkede den nye tilgang? Er den billigere? Har teamet tillid til løsningen?
Hvis svaret er nej, har du ikke fejlet. Du har lært. Justér og prøv igen. Sedna kunne have opdaget, at deres pilot ikke virkede, og skiftet tilgang. Den virkede, så fase 2 var en selvfølge.
Det afhænger af omfanget. Sednas to-fasede tilgang tog omkring seks måneder (optimering + migrering). Et større system kan tage 12–18 måneder. Nøglen er ikke hastighed, men at levere værdi i hver fase frem for en altomfattende omskrivning, der tager to år og lander uden nogen form for buffer.
Ved at køre i faser betaler hver fase for den næste. Optimering i fase 1 kan finansiere migrering i fase 2. Migrering i fase 2 giver teamet tid til at levere funktioner i fase 3. Du satser ikke milliarder på forhånd. Du investerer trinvist.
Du kører det nye system parallelt med det gamle, indtil du er tryg. Hvis produktionen svigter, skifter du øjeblikkeligt tilbage til det gamle system. Du har ikke slettet noget. Sedna holdt Tray.io kørende i to uger efter Lambda-migreringen som et sikkerhedsnet.
Parallel drift er operationelt tungere (du kører begge systemer, overvåger begge og skal potentielt fejlfinde i begge). Men det er den forsikring, der får ledelsen til at sove roligt om natten. Det er det værd.
Modellér ROI tidligt. Optimering i fase 1 betaler ofte for fase 2. Vis ledelsen: nuværende årlige licensomkostninger, forventede besparelser, tilbagebetalingstid og sekundære fordele (hurtigere levering af funktioner, lavere driftsbyrde). Sednas omkostningsreduktion på 80 % gjorde business casen indlysende – tilbagebetaling på tre måneder og overskud i årene derefter.
Hvis du ikke kan lave en ROI-case, er moderniseringen ikke presserende nok. Sæt den på køreplanen, optimér hvor det er billigt, og genbesøg planen næste kvartal.
Det afhænger af teamets ekspertise. Hvis dit team har indgående kendskab til serverless og AWS, er en intern løsning hurtigere og billigere. Hvis ikke, mindsker ekstern hjælp risikoen for tidsplanen og accelererer læringsprocessen.
Den Managed Teams -model, som Sedna benyttede (specialister integreret i kerneteamet i en defineret periode), er en gylden middelvej. Du får eksekveringshastighed, vidensdeling og varige kompetencer i dit team. Målt på antallet af medarbejdere er det ofte billigere end at ansætte fuldtidsingeniører til et seksmåneders projekt.
En hybridløsning fungerer fint. Migrér de dyreste og mest problematiske arbejdsbelastninger til serverless, og behold stabile arbejdsbelastninger med høj volumen på infrastruktur, der allerede er optimeret til den belastning. Undgå alt-eller-intet-tankegangen.
Et almindeligt mønster er at migrere integrationer og baggrundsopgaver til Lambda (serverless er fantastisk til dette), mens databaser og kernetjenester holdes på administreret infrastruktur. Du opnår omkostningsreduktion og forbedrede muligheder uden risikoen ved en komplet arkitekturomskrivning.
Containerisér dine funktioner (Docker-containere er bærbare). Brug administrerede databaser med standard-API'er (ikke Aurora-specifikke funktioner). Undgå AWS-specifikke frameworks i din kerneforretningslogik.
Sednas Lambda-funktioner er ren JavaScript, der bruger standard Node.js-biblioteker. AWS SDK-kaldene er isoleret i infrastrukturkoden. Hvis virksomheden en dag beslutter at skifte til Google Cloud, fungerer funktionerne på Cloud Run med minimale ændringer. Infrastrukturkoden skal omskrives, men selve logikken er bærbar.
Modernisering af legacy-systemer er ikke binært: enten omskriv alt eller acceptér stigende omkostninger. Det er en strategisk eftermontering.
Sednas omkostningsreduktion på 80 % kom fra tre ting: eliminering af leverandørafhængighed (Tray.io-licenser fjernet), skift til serverless-økonomi (betal for eksekvering, ikke fast kapacitet) og frigørelse af teamet til at levere nye funktioner (workflows er nu i kode, testbare og hurtige at implementere).
Læringen for CTO'er: Start med det, der gør mest ondt: omkostninger, hastighed, pålidelighed. Optimér derefter først for at mindske risikoen og skabe momentum. Migrér derefter. Og optimér igen. Hver fase retfærdiggør den næste.
De fleste af jer betaler for meget for legacy-systemer, der er for langsomme at ændre. Hvis det er jeres situation, er dette jeres tilladelse til at handle på modernisering. Kør en audit. Vælg et pilotprojekt. Bevis, at det virker. Og skaler derefter.
Den besparelse på 80 %, som Sedna opnåede, er ikke magi. Det er disciplin: en faseopdelt tilgang, klart afkast, støtte til teamet og modet til at handle, når business casen er solid.
Det er jeres tur.
Er du klar til at modernisere dine legacy-systemer? Kontakt Imaginary Cloud for at drøfte din moderniseringsplan. Vi hjælper dig med at opnå varige omkostningsbesparelser og teknisk selvstændighed.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
Inês Silva er projektleder med over fire års erfaring med at skrive om softwarelevering, agile metoder og teknisk ledelse. Da hun startede sin karriere som udvikler, bringer Inês en reel og dyb teknisk forståelse med ind i ledelsesarbejdet. Hun elsker at bygge bro mellem den overordnede forretningsstrategi og den daglige tekniske eksekvering, og hun brænder for at dele praktiske råd, der hjælper teams med at samarbejde bedre og levere fantastiske produkter.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
