Containere bringer jer et godt stykke af vejen, for selve programmet kan køre mange steder. Data, identitet, databaser og netværk bliver dog tilbage hos udbyderen, og det er ofte dér, tiden går. Containere er en styrke i en exit-plan, så længe ingen siger, at de er hele planen.
Artiklen er til ledelsen, der får at vide, at “vi kører i containere, så vi kan flytte, når vi vil”. Udsagnet er delvist rigtigt. Her er det, I skal bede om at se, før I regner med det.
Hvad der er bundet
En container er en pakke med et program og det, programmet skal bruge for at køre. Kubernetes er det udbredte værktøj, der styrer mange containere på én gang. Infrastruktur som kode betyder, at servere, netværk og opsætning er beskrevet i tekstfiler, så miljøet kan bygges igen.
Teknologisk Institut nævner i sin guide til IKT-virksomheder portabilitet via containere og tænker exit ind som et designprincip. Guiden er skrevet til leverandører af IT, og filnavnet siger “endeligt udkast”, så den er en sekundær kilde. Pointen holder for en almindelig virksomhed, der får lavet software: portabilitet i skyen kommer af valg, der er truffet undervejs.
Det, der binder, ligger rundt om containeren. Søger I på “kubernetes vendor lock in”, finder I netop den diskussion, og vendor lock-in betyder afhængighed af en bestemt leverandør. Et miljø kan være fuldt containeriseret og alligevel hænge fast i udbyderens database, kø, identitet eller lager.
Hvad der kan komme ud
Selve containerne er det letteste. Efter Kommissionens vejledende FAQ om Data Act (dataforordningen) kan virtuelle maskiner og containere regnes som jeres digitale aktiver, hvis jeres ret til at bruge dem ikke afhænger af udbyderen. Billeder af containere kan gemmes hos jer eller et neutralt sted, og konfiguration i tekstfiler kan ligge i jeres eget system til versionsstyring. Har I det, er der noget at tage med.
Hvad der mangler
Fire ting bliver tilbage, når containerne er flyttet:
- Data. En container er let. Databasen, der ligger bag den, er ofte tung og skal flyttes med overførselstid, nedetid og kontrol, se hvor lang tid tager overførslen.
- Identitet og hemmeligheder. Hvem må hvad, og hvor ligger nøgler og adgangskoder? De er ofte koblet til udbyderens egne tjenester, se login som afhængighed.
- Styrede tjenester. Hvis jeres Kubernetes er udbyderens styrede udgave, bruger opsætningen typisk udbyderens lager, netværk og lastbalancering. De dele skal laves om.
- Viden. Drift af containere kræver mennesker, der kan det. Har I købt det som en tjeneste, skal nogen kunne overtage. Se tilbage i egen drift.
Infrastruktur som kode hjælper med at gentage en opsætning, men koden er ofte skrevet til én udbyder. Den er en beskrivelse, der skal oversættes, og det er værdifuldt i sig selv, men en anden opgave end et tryk på en knap.
Hvad der skal testes
Påstanden kan afprøves med en lille indsats:
- Vælg én tjeneste, der ikke er den vigtigste.
- Bed teknikerne starte den et andet sted, fx hos en anden udbyder eller på en lokal server, kun ud fra det, der ligger i jeres egen versionsstyring.
- Notér alt, der skulle hentes eller laves i hånden.
- Flyt en kopi af databasen med, og se, om tjenesten faktisk virker.
Listen fra punkt 3 er resultatet. Den viser forskellen mellem påstanden og virkeligheden. Læg kriterierne fast før prøven, se hvad er en bestået test, og lav prøven adskilt fra produktionen, se gendannelse et andet sted.
Hvad planen skal rumme
Planen skal skelne mellem det, der er flytbart, og det, der skal laves om. Skriv for hver tjeneste: hvor koden og billederne ligger, hvilke af udbyderens tjenester den bruger, hvor data ligger, hvordan hemmeligheder håndteres, og hvem der kan drive den. Skriv også, hvem der ejer opsætningen. Laver en leverandør det for jer, skal aftalen sige, at koden er jeres, og at I kan hente den.
Er I selv softwarehus, er spørgsmålet et andet, og det handler om jeres egen produktarkitektur. Cloud og hosting til et SaaS-produkt tager den side.
Hvad det kræver, og hvad det koster at lade være
Prøven kræver en tekniker i nogle dage. Vurder, hvor meget det ville kræve at gøre tjenesterne mere flytbare, og sammenlign med, hvad bindingen giver. Portabilitet koster arbejde, og det kan være fornuftigt at acceptere en binding, fordi udbyderens tjeneste sparer drift hver dag. Et lavt og et højt skøn i timer hører med, og begge dateres.
Risikoen ved at lade være er en plan bygget på en antagelse. Den dag, en kunde eller bestyrelse spørger, har I kun et udsagn. Brug egne tal til at se, hvad det betyder, at en tjeneste står stille, mens arbejdet laves under pres. Prøven giver noget i dag: en mere ærlig tidsplan, bedre dokumentation af miljøet og lettere genopbygning efter et nedbrud.
Det skal I lade være med
- At se containere som hele planen · data og identitet følger ikke med.
- At jage fuld portabilitet for enhver pris · nogle bindinger er det værd.
- At tro på et udsagn uden en prøve · en lille prøve siger mere end antagelsen.
Det skal planen kunne vise
- ☐ Hvor kode, billeder og konfiguration ligger, og hvem der ejer dem.
- ☐ Hvilke af udbyderens tjenester hver løsning bruger.
- ☐ Hvor data ligger, og hvordan de flyttes.
- ☐ En prøve med én tjeneste og en liste over manuelle trin.
- ☐ Hvem der kan drive løsningen efter en flytning.
- ☐ Hvilke bindinger ledelsen har accepteret.
Kilder
- Teknologisk Institut: Digital suverænitet, din guide til at komme rigtigt fra start, marts 2026: skrevet til IKT-virksomheder. Sekundær kilde.
- Europa-Kommissionen: FAQ om Data Act, version 1.4: afsnit 53. Vejledende.
Senest gennemgået: november 2026.
Næste skridt
Bed teknikerne om at starte én tjeneste et andet sted ud fra det, I selv ligger inde med. Brug listen over manuelle trin, når ledelsen skal afgøre, hvilke bindinger den vil acceptere.
Læs også: Exit-plan for AWS · Exit-plan for Azure
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
