Întreabă zece echipe de infrastructură dacă au o strategie de exit din cloud și nouă vor spune da. Întreabă din ce constă și de obicei primești o pagină de wiki scrisă în timpul unei revizuiri de vendor, listând ce servicii sunt proprietare și ce servicii sunt portabile. Ăsta e un inventar, nu o strategie. Testul real e mai puțin confortabil: dacă furnizorul tău și-ar dubla prețurile, și-ar schimba jurisdicția sau ți-ar suspenda contul într-o dimineață de marți, câte săptămâni ai avea nevoie ca să servești trafic din altă parte - și cine din echipa ta poate răspunde la asta fără să deschidă o foaie de calcul?
Presiunea de reglementare aici e reală, dar nu e partea interesantă. Data Act elimină taxele de schimbare a furnizorului, ceea ce ia departamentului financiar scuza. Schrems II și CLOUD Act au eliminat scuza juridică cu ani în urmă. Ce rămâne e realitatea inginerească, iar nicio directivă nu rezolvă asta. Un regulator poate face ieșirea mai ieftină pe hârtie; nu poate face ca pipeline-ul tău de deployment, modelul tău de identitate, înregistrările DNS și calea ta de restore să funcționeze la un al doilea furnizor. Acea muncă e a ta, și reprezintă întregul cost.
Ce înseamnă de fapt o strategie de ieșire din cloud
O strategie de ieșire este o proprietate măsurabilă a arhitecturii tale, nu un document. Măsurătoarea e directă: ce procent din infrastructura ta activă ai putea ridica la un alt furnizor, folosind unelte pe care deja le operezi, fără să scrii cod nou? Pentru majoritatea echipelor, răspunsul onest se situează undeva între patruzeci și șaptezeci la sută, iar diferența nu e niciodată acolo unde se așteptau. Rareori e vorba de aplicație. E vorba de baza de date gestionată, de coadă, de semantica object storage-ului și de cele unsprezece obiceiuri operaționale mărunte pe care nimeni nu le-a scris vreodată.
Greșeala e să crezi că a avea doi furnizori dovedește ceva. Multe companii rulează producția pe un singur hyperscaler și un proiect de test uitat undeva altundeva, apoi numesc rezultatul multi-cloud. Opționalitatea nu înseamnă existența unui al doilea cont; înseamnă capacitatea de a-l folosi efectiv. Până când un workload real - cu monitoring, backup-uri, o rotă de gardă și un restore pe care chiar l-ai efectuat - nu rulează altundeva decât la furnizorul tău principal, ai o a doua factură, nu o a doua opțiune.
Cele trei lucruri care fac plecarea dificilă
Primul: data gravity, care e plictisitor și decisiv. Copierea de biți e ieftină, dar mutarea lor consistentă cât timp sistemul e live e costisitoare. În momentul în care datele tale stau într-un serviciu gestionat proprietar, ieșirea încetează să mai fie o copiere și devine o rescriere a tot ce comunică cu ele. De aceea echipele care își păstrează starea în ceva ce ar putea rula ele însele - chiar dacă aleg să nu o facă azi - păstrează opțiuni pe care echipele de pe stack-uri complet gestionate le pierd, discret, în câțiva ani.
Al doilea: memoria musculară operațională. Echipa ta cunoaște modelul de identitate al unui singur furnizor, o singură abstractizare de firewall, un singur mod de a denumi rețelele, un singur layout de consolă la ora trei dimineața. Mută-te la un al doilea furnizor și fiecare dintre acestea devine nefamiliar sub presiune. Costul nu e weekend-ul de migrare; sunt următoarele șase luni de incidente gestionate puțin mai lent de oameni care ghicesc. Nimeni nu trece asta într-o estimare de migrare, deși e de obicei cea mai mare linie din ea.
Al treilea: atribuirea costurilor. Majoritatea echipelor nu-ți pot spune cât costă azi un singur workload, ceea ce face compararea furnizorilor imposibilă în principiu. Dacă factura ta e un singur număr per furnizor, iar arhitectura ta are patruzeci de servicii, discuția despre ieșire degenerează în presupuneri. Înainte să poți calcula costul unei ieșiri ai nevoie de cheltuieli defalcate pe serviciu, proiect și mediu, la fiecare furnizor pe care îl folosești, inclusiv cei mici pe care i-ai uitat. E o muncă de bază neglamuroasă, dar e o precondiție pentru orice altă decizie de aici.
Cum eviți vendor lock-in-ul cloud în UE
Dacă vrei să eviți vendor lock-in-ul cloud, piața UE stă mai bine decât presupun majoritatea echipelor. Raportul preț-performanță al Hetzner face ca facturile hyperscalerelor să pară o eroare de rotunjire în direcția greșită. OVHcloud operează propriile centre de date și fibră optică în toată Europa. Scaleway oferă o experiență de dezvoltator cu adevărat modernă, din Franța. UpCloud livrează compute de încredere din Finlanda. Niciunul dintre ei nu înlocuiește toate serviciile unui hyperscaler - dar pentru compute, block storage și networking, unde se duce de fapt cea mai mare parte a banilor pe infrastructură, sunt opțiuni credibile și răspund exclusiv în fața legislației UE.
Limita onestă sunt serviciile gestionate. Dacă produsul tău e construit pe o bază de date serverless proprietară, un event bus specific sau o platformă de machine learning fără echivalent altundeva, niciun entuziasm european nu schimbă asta într-un trimestru. Mișcarea utilă nu e o migrare eroică, totul-sau-nimic. E să știi exact care workload-uri sunt portabile azi, să rulezi o parte dintre ele acolo unde jurisdicția și prețul ți se potrivesc, și să tratezi restul ca pe o decizie deliberată, documentată, nu ca pe un accident al istoriei.
Ce presupune de fapt un exercițiu de ieșire
Tratează-l ca pe un exercițiu de restore, pentru că exact asta este. Alege un workload real - nu site-ul de marketing, ceva cu stare și un runbook. Ridică-l la un al doilea furnizor. Direcționează o fracțiune din traficul real către el. Sparge-l deliberat și vezi dacă monitoring-ul, modelul de acces și rota de gardă funcționează și acolo. Apoi notează timpul real scurs și tot ce te-a surprins. Un exercițiu care nu produce nicio surpriză înseamnă de obicei că ai ales ceva prea ușor.
Motivul pentru care majoritatea echipelor nu exersează niciodată nu e lenea, ci uneltele. Fiecare furnizor în plus înseamnă o altă consolă, un alt model de credențiale, un alt export de facturare, un alt set de particularități de învățat - iar o echipă mică de platformă nu poate absorbi asta pentru fiecare cloud în parte. Aceasta e taxa operațională care transformă discret o discuție despre suveranitate în problema anului viitor, an de an. Este, de altfel, exact problema pe care un control plane ar trebui să o ia de pe biroul tău.
Exact asta am construit ca Sencai să fie. Un singur control plane pentru unsprezece furnizori - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode de la Akamai și Oracle Cloud - plus propriile tale servere, printr-un agent instalat pe host. Rețelele, firewall-urile și DNS-ul sunt gestionate acolo unde există de fapt, la furnizor, astfel încât un al doilea furnizor devine o casetă în aceeași interfață, nu o a doua echipă de platformă. Cheltuielile sunt urmărite per organizație, cu plafoane, așa că discuția despre ieșire are și cifre în ea.
Poți rula asta pe propriile conturi la furnizori, sau poți cumpăra capacitatea prin noi și păstra o singură factură - ambele sunt suportate, iar alegerea rămâne a ta, oricând o poți schimba. Oricum ai proceda, rezultatul e același, și e singura cifră care merită raportată mai sus: cât timp ți-ar lua să rulezi altundeva. Măsoar-o o dată și încetează să mai fie o frică. Măsoar-o în fiecare trimestru și devine pârghie - într-o negociere, într-o revizuire de achiziții și în ziua în care ceva forțează întrebarea.