Strategie odchodu z cloudu
Strategie odchodu z cloudu je zdokumentovaný plán přesunu workloadů, dat a konfigurací od cloud providera pryč - nebo mezi providery - bez dlouhého výpadku, ztráty dat nebo ztráty vyjednávací pozice. Zahrnuje přenositelnost dat, technické závislosti, smluvní výpovědní lhůty a otestovaný časový plán, a buduje se dřív, než je potřeba, ne až během krize.
V praxi je strategie odchodu z cloudu inventura plus plán. Inventura vypíše, co skutečně závisí na současném provideru: obrazy pro výpočetní instance, formáty spravovaných databází, DNS záznamy, konfiguraci firewallu a sítě, IAM politiky a jakákoliv API nebo spravované služby specifické pro daného providera, které aplikace volá přímo. Plán popisuje, jak se každá z těchto věcí extrahuje nebo znovu postaví jinde - v jakém formátu se exportují data, jak dlouho reálně trvá kompletní migrace, jaká je výpovědní lhůta a podmínky předčasného ukončení ve smlouvě, a kdo v týmu to dokáže provést. Organizace, které tohle berou jako zaškrtávací políčko, obvykle mezeru objeví až při skutečné krizi: zdražení, výpadek bez garantované doby obnovy, nebo provider ukončující službu, na které produkční systém závisí. Skutečná strategie odchodu se testuje dřív, než se něco z toho stane, ne až během toho.
Uvíznutí u jednoho providera málokdy pramení z podepsané smlouvy - pramení z architektury. Proprietární spravované služby (vlastní databázový engine providera, frontu zpráv nebo serverless běhové prostředí) je nejtěžší opustit, protože přestavba na jiné platformě znamená přepsat kód aplikace, ne jen přesunout data. Poplatky za odchozí přenos dat přidávají přímý náklad na odchod. A infrastruktura provisionovaná ručně přes vlastní konzoli providera bývá zdokumentovaná jen v té konzoli - nikdo neumí vypsat, co existuje, natož to přesunout. Nic z toho neznamená úplně se vyhýbat specifickým funkcím providera; znamená to písemně vědět, které části stacku jsou přenositelné, které ne, a co by stálo a trvalo to změnit.
Proč na tom záleží, i když nikdy neodejdete
Většina organizací, které si postaví strategii odchodu, ji nikdy nepoužije - a o to jde. Zdokumentovaná, otestovaná schopnost odejít je vyjednávací páka: dodavatel, který ví, že přechod je reálný, má míň prostoru zvedat ceny, zhoršovat podporu nebo prosazovat nevýhodné smluvní podmínky při obnově. Je to i řízení rizik proti věcem mimo vaši kontrolu - regionální výpadek, provider opouštějící trh, akvizice měnící plán rozvoje produktu, nebo změna obchodních podmínek. A čím dál víc je to regulatorní očekávání, ne bonus navíc: pravidla EU jako NIS2 vyžadují, aby organizace řídily rizika ve svém ICT dodavatelském řetězci, a sektorová pravidla jako DORA výslovně žádají po regulovaných subjektech zdokumentovat plány odchodu pro kritické dodavatele třetích stran. Nákupní i bezpečnostní prověrky si ji vyžádají před uzavřením obchodu, ne po něm.
Jak Sencai drží tuhle možnost otevřenou
Sencai se připojuje k vašim existujícím cloudovým účtům formou BYOC: nic se do Sencai nemigruje, účet, smlouva i fakturace zůstávají u vás. Přihlašovací údaje jsou šifrované at-rest a přístup Sencai u providera můžete kdykoliv odvolat. Ve chvíli, kdy se účet připojí, Sencai zinventarizuje, co už běží - instance, sítě, úložiště, DNS - zdroj po zdroji, bez vynuceného přebírání; stejné objevování funguje napříč všemi 11 providery, které Sencai podporuje. Díky tomu máte stálý, aktuální obrázek toho, na čem skutečně závisíte, místo obrázku sestaveného pod tlakem termínu. Stejná platforma funguje bez ohledu na to, jestli infrastruktura zůstane u providera, kterého jste si vybrali, nebo se přesune k jinému, který Sencai podporuje.
Podívat se, jak funguje inventura a provisioning →