En applikation, der bruger en udbyders egne tjenester til funktioner, køer, hændelser og identitet, kan ikke flyttes, som den er. Den skal bygges om til de byggesten, der findes på det nye sted, og omfanget måles i ugers arbejde for udviklere og arkitekter.
Det er også den type system, hvor en arkitekt kan stå med en beslutning, andre har truffet. Løsningen blev bygget, fordi tjenesterne var lette at tage i brug, og fordi de passede til opgaven. At den samtidig blev knyttet til én platform, var en sidegevinst, ingen skrev ned. Nu skal den, der har overtaget den, vurdere, hvad en flytning kræver.
Hvad der binder
Funktioner uden servere. En udbyders tjeneste til at køre kode uden at administrere servere sætter kode i gang, når noget sker: en fil lander, en besked kommer, et tidspunkt nås. Koden selv er ofte almindelig kode. Bindingen ligger i alt omkring den: hvordan den startes, hvilke rettigheder den har, hvordan den logger, og hvilke andre tjenester den kalder.
Køer og hændelser. Beskeder mellem dele af systemet går gennem udbyderens egne køer og hændelsestjenester med deres egne garantier for rækkefølge, gentagelse og levetid. Et andet produkt kan have andre garantier, og så skal koden tage højde for det.
Identitet til tjenesterne. Når dele af systemet taler sammen, sker det med udbyderens egen model for roller og rettigheder. Den model findes ikke andre steder og skal oversættes til en ny.
Lager og databaser. Objektlager, nøgle-værdi-lager og udbyderens egne databaser bruges direkte fra koden gennem udbyderens biblioteker.
Udrulning og overvågning. Skabeloner til at oprette ressourcerne, pipelines, alarmer og dashboards er skrevet til platformen.
Hvad der findes på det nye sted
Kataloget af færdige tjenester ser anderledes ud hos en europæisk udbyder end hos den platform, systemet er bygget til. Hvad hver af dem tilbyder, står i deres egne kataloger og beskrives under udbyderne efter samme målestok. En tjeneste, der svarer én til én, skal ikke forventes.
Den anden vej er åbne byggesten, I selv driver eller får drevet på en Kubernetes-klynge. Knative er et eksempel: en Kubernetes-baseret platform med komponenter til at bygge og drive arbejdsbelastninger uden faste servere. Det er en byggesten. Den erstatter ingen bestemt udbyders tjeneste, og den kræver, at nogen kan drive klyngen under den. Læs har I overhovedet brug for Kubernetes, før den vej vælges.
Sådan vurderer I ombygningen
Gå systemet igennem del for del, og skriv for hver del:
- Hvilken af udbyderens tjenester bruges, og til hvad?
- Bruges den gennem et standardiseret grænsesnit eller gennem udbyderens eget bibliotek?
- Findes der en tilsvarende tjeneste eller en åben byggesten på det nye sted?
- Hvad skal ændres i koden, i udrulningen og i overvågningen?
- Hvem kan lave ændringen, og hvem kan teste den?
Svarene giver et billede af, hvor meget der er ren flytning, og hvor meget der er udvikling. Del med standardiseret grænsesnit og en tilsvarende tjeneste kan måske flyttes med konfiguration. Del med eget bibliotek og ingen tilsvarende tjeneste skal omskrives.
Overslaget i uger
Ombygning regnes i uger, fordi den kræver udviklere, test og en ny driftsmodel. Sæt et spænd i uger pr. del, fra det hurtige forløb til det trægeste, og afsæt tid til en samlet test af systemet. Overslaget skal også rumme den tid, driftsfolkene bruger på at lære de nye byggesten. Kronebeløbet finder I selv ud fra jeres timepriser.
Et overslag i uger gør det muligt at sammenligne med gevinsten. Er systemet lille og gevinsten stor, kan ombygningen betale sig. Er systemet stort og gevinsten lille, kan det være rigtigt at lade det blive eller vente, til systemet alligevel skal fornyes. Det sidste står i det, der ikke skal flyttes.
Et softwarehus, der driver sit eget produkt på udbyderens tjenester, står med samme spørgsmål set fra produktets side.
Byg om i trin
Ombygning behøver ikke ske på én gang. Kerneprogrammet kan flyttes til containere først, mens funktioner og køer bliver, hvor de er. Bagefter tages én del ad gangen. Det giver et tidsrum med to platforme, og det skal planlægges: forbindelsen mellem dem, hvor data ligger, og hvad udgående datatrafik koster.
Hvad det kræver, og hvad det koster at lade være
Gennemgangen af et system kræver en arkitekt og en udvikler, der kender koden, i nogle dage. Resultatet er en liste over dele, et overslag i uger pr. del og en vurdering af, om ombygningen skal ske nu, senere eller ikke.
Uden gennemgangen kan ombygningen let blive undervurderet, når det er koden alene, der bliver set. Udrulning, overvågning, rettigheder og test opdages undervejs. Projektet trækker ud, og den gamle platform skal betales, så længe det varer. Den anden fejl er at regne systemet for umuligt at flytte og lade det blive uden en vurdering. Så er beslutningen truffet uden at være truffet.
Det skal I lade være med
- At regne med koden alene · udrulning, rettigheder og overvågning kan fylde mere end koden.
- At forvente en tjeneste, der svarer én til én · garantier og grænser er forskellige fra produkt til produkt.
- At bygge om og flytte i samme skridt uden en plan · det giver to projekter, der skal lykkes samtidig.
Det skal valget kunne vise
- ☐ Systemets dele med den tjeneste, hver af dem bruger.
- ☐ For hver del: tilsvarende tjeneste eller byggesten på det nye sted.
- ☐ Overslag i uger pr. del med lav og høj vurdering.
- ☐ Hvem der bygger om, og hvem der tester.
- ☐ Beslutning om nu, senere eller ikke, med begrundelse.
Kilder
- AWS, What is AWS Lambda?, https://docs.aws.amazon.com/lambda/latest/dg/welcome.html, læst 8. november 2026.
- Knative, Documentation, https://knative.dev/docs/, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg det system, der bruger flest af udbyderens egne tjenester, og gennemgå de fem spørgsmål for det.
Læs også: AWS- og Azure-tjenester oversat til europæiske byggesten · Kubernetes gør jer ikke flytbare af sig selv
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
