Spør ti infrastrukturteam om de har en cloud exit-strategi, og ni vil si ja. Spør hva den består av, og du får som regel en wiki-side skrevet under en leverandørgjennomgang, som lister opp hvilke tjenester som er proprietære og hvilke som er portable. Det er et inventar, ikke en strategi. Den reelle testen er mindre komfortabel: hvis leverandøren din doblet prisene, endret jurisdiksjon, eller suspenderte kontoen din en tirsdag morgen, hvor mange uker til du betjener trafikk et annet sted - og hvem i teamet ditt kan svare på det uten å åpne et regneark?
Det regulatoriske presset her er reelt, men det er ikke den interessante delen. Data Act fjerner byttekostnader, som fjerner unnskyldningen til økonomiavdelingen. Schrems II og CLOUD Act fjernet den juridiske for flere år siden. Det som gjenstår er ingeniørvirkelighet, og ingen direktiv fikser det. En tilsynsmyndighet kan gjøre det billigere å forlate på papiret; den kan ikke få deploy-pipelinen din, identitetsmodellen din, DNS-oppføringene dine og gjenopprettingsstien din til å fungere hos en annen leverandør. Det arbeidet er ditt, og det er hele kostnaden.
Hva en cloud exit-strategi faktisk er
En exit-strategi er en målbar egenskap ved arkitekturen din, ikke et dokument. Målingen er brutal: hvor stor andel av den kjørende infrastrukturen din kunne du satt opp hos en annen leverandør, med verktøy du allerede drifter, uten å skrive ny kode? For de fleste team lander det ærlige svaret et sted mellom førti og sytti prosent, og gapet er aldri der de forventet. Det er sjelden applikasjonen. Det er den administrerte databasen, køen, object storage-semantikken, og de elleve små driftsvanene ingen noensinne skrev ned.
Feilmodusen er å tro at det å ha to leverandører beviser noe. Mange selskaper kjører produksjon på én hyperscaler og et glemt testprosjekt et annet sted, og kaller resultatet multi-cloud. Fleksibilitet er ikke tilstedeværelsen av en andre konto; det er evnen til å bruke den. Før én reell arbeidslast - med overvåking, backup, en vaktordning og en gjenoppretting du faktisk har utført - kjører et annet sted enn hovedleverandøren din, har du en andre faktura, ikke et andre alternativ.
De tre tingene som gjør det vanskelig å forlate
Først, datagravitasjon, som er kjedelig og avgjørende. Bytes er billige å kopiere og dyre å flytte konsistent mens et system er live. I det øyeblikket dataene dine bor inne i en proprietær administrert tjeneste, slutter exiten å være en kopiering og blir en omskrivning av alt som snakker med den. Dette er grunnen til at team som holder tilstanden sin i noe de kunne kjørt selv - selv om de velger å ikke gjøre det i dag - bevarer valgmuligheter som team på fullstendig administrerte stacker stille mister i løpet av noen år.
For det andre, operasjonell muskelhukommelse. Teamet ditt kjenner én leverandørs identitetsmodell, én brannmurabstraksjon, én måte å navngi nettverk på, ett konsolloppsett klokken tre om natten. Bytt til en ny leverandør, og alt dette blir ukjent under press. Kostnaden er ikke migreringshelgen; det er de neste seks månedene med hendelser håndtert litt saktere av folk som gjetter. Ingen setter det inn i et migreringsestimat, og det er som regel den største posten på det.
For det tredje, kostnadsfordeling. De fleste team kan ikke fortelle deg hva en enkelt arbeidsbelastning koster i dag, noe som i prinsippet gjør det umulig å sammenligne leverandører. Hvis fakturaen din er ett tall per leverandør og arkitekturen din består av førti tjenester, glir exit-samtalen over i synsing. Før du kan prissette en exit, trenger du forbruk fordelt på tjeneste, prosjekt og miljø, på tvers av hver leverandør du bruker - inkludert de små du har glemt. Det er lite glamorøst grunnarbeid, og det er en forutsetning for enhver annen beslutning her.
Slik unngår du leverandørbinding til skyleverandører i EU
Hvis du vil unngå leverandørbinding i skyen, er EU-markedet i bedre stand enn de fleste team antar. Hetzners pris-ytelse får hyperscaler-fakturaer til å se ut som en avrundingsfeil i feil retning. OVHcloud driver egne datasentre og fiber over hele Europa. Scaleway leverer en genuint moderne utvikleropplevelse fra Frankrike. UpCloud leverer pålitelig compute fra Finland. Ingen av dem erstatter alle hyperscaler-tjenester - men for compute, blokklagring og nettverk, der mesteparten av infrastrukturpengene faktisk går, er de troverdige og svarer utelukkende til EU-lovgivning.
Den ærlige begrensningen er administrerte tjenester. Hvis produktet ditt er bygget på en proprietær serverløs database, en bestemt event bus, eller en maskinlæringsplattform uten noe tilsvarende andre steder, endrer ingen mengde europeisk entusiasme det i løpet av et kvartal. Det nyttige grepet er ikke en heltemodig alt-eller-ingenting-migrering. Det er å vite nøyaktig hvilke arbeidsbelastninger som er portable i dag, kjøre noen av dem der jurisdiksjonen og prisen passer deg, og behandle resten som en bevisst, dokumentert beslutning fremfor et tilfeldig utfall av historien.
Hva en exit-øvelse faktisk innebærer
Behandle det som en restore-øvelse, for det er nettopp det det er. Velg en reell arbeidsbelastning - ikke markedsføringsnettsiden, men noe med tilstand og et runbook. Sett den opp hos en ny leverandør. Rett en liten andel av reell trafikk mot den. Bryt den bevisst, og se om overvåkingen din, tilgangsmodellen din og vaktordningen din fungerer der også. Skriv deretter ned tiden det tok i klokketid, og alt som overrasket deg. En øvelse som ikke gir noen overraskelser, betyr som regel at du valgte noe for enkelt.
Grunnen til at de fleste team aldri øver, er ikke latskap - det er verktøy. Hver ekstra leverandør betyr enda en konsoll, enda en legitimasjonsmodell, enda en faktureringseksport, enda et sett med særegenheter å lære seg - og et lite plattformteam kan ikke absorbere det én gang per sky. Dette er den operasjonelle skatten som stille og rolig gjør en suverenitetssamtale til neste års problem, år etter år. Det er også, nettopp, problemet en kontrollplan skal fjerne fra pulten din.
Det er det vi har bygget Sencai til å være. Én kontrollplan på tvers av elleve leverandører - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamais Linode og Oracle Cloud - pluss dine egne servere via en host-agent. Nettverk, brannmurer og DNS administreres der de faktisk befinner seg, hos leverandøren, slik at en ny leverandør blir en flis i samme grensesnitt fremfor et nytt plattformteam. Forbruk spores per organisasjon med tak, slik at exit-samtalen har tall i seg.
Du kan kjøre dette på dine egne leverandørkontoer, eller kjøpe kapasiteten gjennom oss og beholde én faktura - begge deler støttes, og valget er ditt å endre senere. Uansett hva du velger, er leveransen den samme, og det er det eneste tallet som er verdt å rapportere oppover: hvor lang tid det ville ta deg å kjøre et annet sted. Mål det én gang, og det slutter å være en frykt. Mål det hvert kvartal, og det blir et forhandlingskort - i en forhandling, i en anskaffelsesgjennomgang, og den dagen noe tvinger frem spørsmålet.