Než podepíšete smlouvu s partnerem pro migraci do cloudu, zeptejte se, jak zinventarizuje to, co provozujete, jak zvolí strategii migrace pro každou aplikaci, jak navrhne a zabezpečí cílové prostředí, jak u každého přepnutí zajistí návrat zpět, jak vám ukáže náklady a jak připraví váš tým na provoz výsledku. Konkrétní písemné odpovědi vám o nadcházející migraci řeknou víc než denní sazba.
Zeptejte se, jak zjistí, co skutečně provozujete
Plán migrace je jen tak dobrý jako inventura, na které stojí. Zeptejte se partnera, jak ji sestaví: z rozhovorů s vlastníky aplikací, z dat o infrastruktuře, jako jsou metriky serverů a síťová spojení, ze samotného kódu, nebo ze všech tří zdrojů. Stávající dokumentace je výchozí bod, ne důkaz, protože se od toho, co skutečně běží, postupně vzdaluje.
Zeptejte se, co bude inventura zaznamenávat a komu bude potom patřit. Dobrá odpověď jmenuje jednotlivá pole a potvrdí, že inventura zůstane u vás, ať se dál rozhodnete jakkoli.
- Každá aplikace, její obchodní vlastník a míra její kritičnosti
- Běhová prostředí, frameworky a operační systémy, s označením všeho, co je po konci podpory
- Databáze, sdílená úložiště souborů, plánované úlohy a fronty, na kterých každá aplikace závisí
- Integrace v obou směrech, včetně těch, které nikdo nezdokumentoval
- Licence vázané na hardware nebo počet procesorů, které se do cloudu nemusejí přenést
- Přijatelná odstávka a obchodní kalendář: konec měsíce, sezónní špička, regulatorní termíny
Očekávejte strategii pro každou aplikaci, ne jednu pro celé portfolio
Aplikace se do cloudu přesouvají různými způsoby. Obvyklé možnosti jsou přesunout aplikaci tak, jak je (rehost, lift and shift), převést ji na jinou platformu s malými změnami, například se spravovanou databází (replatform), přepracovat ji na cloudové služby (refactor), nahradit ji produktem typu software jako služba (SaaS), ponechat ji zatím tam, kde je, nebo ji vyřadit. Partner, který navrhuje jeden přístup na všechno, se nedíval dost pozorně.
Zeptejte se na kritéria, podle kterých vybírá, a před podpisem chtějte vidět, jak je uplatní na tři nebo čtyři vaše vlastní aplikace. Jeho úvahy o vašich skutečných systémech vám řeknou víc než slajd s metodikou. Zeptejte se zejména, jak zachází s aplikacemi na běhových prostředích po konci podpory, protože jejich přesun beze změny přenese stará rizika na novou platformu.
Zjistěte, kdo navrhuje a zabezpečuje landing zone
Landing zone je připravené cílové prostředí: struktura účtů, identity a přístupy, síť, logování, šifrování a mantinely, které zdědí každá aplikace. Chyba v ní se zopakuje v každé aplikaci, která na ni přistane. Zeptejte se, kdo ji navrhuje, zda je definovaná jako kód, například v Terraformu, a zda ji před přesunem první aplikace zkontroluje váš bezpečnostní tým.
Bezpečnost v cloudu je sdílená. Poskytovatel zabezpečuje podkladovou infrastrukturu a vy zůstáváte odpovědní za to, jak ji konfigurujete a používáte. Zeptejte se partnera, které kontroly nastaví on, které zůstanou na vašem týmu a jak se přístup jeho vlastních inženýrů uděluje, zaznamenává a na konci odebírá.
- Samostatné účty nebo projekty pro každé prostředí, s oddělenou produkcí
- Jednotné přihlášení (SSO) se jmenovitými uživateli a rolemi s nejmenšími nutnými oprávněními, bez sdílených administrátorských přístupů
- Centrální logování a auditní stopy, které inženýři projektu nemohou vypnout
- Šifrování dat v klidu i při přenosu jako výchozí stav, s tajnými klíči mimo kód
- Regiony zvolené tak, aby splňovaly vaše povinnosti ohledně umístění dat a GDPR
Nechte si ukázat jedno přepnutí a jeden návrat zpět krok za krokem
Přepnutí je okamžik, kdy provoz a data přecházejí do nového prostředí, a je to chvíle, kdy je migrace pro firmu nejvíc vidět. Požádejte partnera, aby s vámi prošel přepnutí jedné z vašich aplikací krok za krokem: jak se synchronizují data, jak se přepíná provoz, jaké kontroly proběhnou potom a kdo rozhodne, že se to povedlo.
Pak se zeptejte, jak by se vrátil zpět. Věrohodný plán jmenuje podmínky, které návrat zpět spouštějí, osobu, která o něm rozhoduje, a jak dlouho zůstane staré prostředí k dispozici. Pokud uživatelé od přepnutí zapsali data do nového prostředí, zeptejte se, jak se tato data dostanou zpět do starého. Slabé plány tuto otázku přeskakují.
Náš článek o migraci stovek starších aplikací do AWS ukazuje, jak se z těchto kroků stávají runbooky pro rozsáhlé portfolio.
Trvejte na tom, abyste náklady viděli dřív, než přijde první faktura
Náklady v cloudu se chovají jinak než v datovém centru. Platíte za to, co běží, včetně testovacích prostředí, která nikdo nevypnul, úložiště, které stále roste, a dat přenesených mimo síť poskytovatele. Vyžádejte si odhad nákladů pro každou aplikaci se sepsanými předpoklady a zeptejte se, jak ho partner v prvních měsících porovná se skutečným využitím.
Přehled o nákladech je rozhodnutí při návrhu, ne měsíční report. Vyžádejte si pravidla pro štítkování (tagging), která každý prostředek propojí s aplikací a vlastníkem, rozpočty a upozornění od prvního dne a revizi velikostí instancí, jakmile aplikace poběží pod skutečnou zátěží. Dimenzovat cloudové servery podle starého hardwaru je spolehlivý způsob, jak platit za kapacitu, kterou nikdo nevyužívá.
Varovné signály, že návrh migrace není připravený
Kterýkoli z nich může mít vysvětlení. Několik v jednom návrhu obvykle znamená, že riziko zůstalo na vás, abyste ho objevili.
- Pevný harmonogram dřív, než kdokoli viděl vaši inventuru
- Jedna strategie migrace uplatněná na všechny aplikace
- Žádný písemný plán návratu zpět, nebo návrat, který závisí na obnově ze záloh pod tlakem
- Cloudové účty, kód infrastruktury nebo pipeliny ve vlastnictví partnera, a ne vašem
- Odhady nákladů bez předpokladů a žádný plán pro štítkování nebo rozpočty
- Předání znalostí naplánované na poslední týden
Předávání znalostí plánujte od prvního týdne, ne od posledního
Migrace skončí, provoz platformy ne. Zeptejte se, jak se váš tým naučí provozovat to, co vznikne: společnou prací na skutečných úlohách během migrace, runbooky pro opakované operace a průchodem monitoringem a upozorněními s lidmi, kteří budou držet pohotovost.
Požadujte, aby vše bylo od začátku ve vašich účtech a repozitářích: kód infrastruktury, pipeliny, runbooky a diagramy. Pak se dohodněte, jak se předání přebírá, například tak, že váš tým nasadí aplikaci a vrátí ji zpět bez pomoci partnera.
Pracovali jsme v týmu, který přesunul 600+ interních aplikací Crédit Agricole ze starých VM do AWS, a 50+ z těchto migrací jsme dodali sami. Pokud chcete druhý názor na návrh migrace nebo tým, který dodá část práce, naši inženýři pro cloudovou infrastrukturu s vámi tyto otázky projdou.
Hlavní body
- Zeptejte se, jak bude inventura sestavena a ověřena, protože na ní závisí každý odhad i plán vln migrace.
- Očekávejte strategii migrace zvolenou pro každou aplikaci zvlášť, podle kritérií, která uvidíte uplatněná na vlastní systémy.
- Landing zone mějte definovanou jako kód, zkontrolovanou vaším bezpečnostním týmem a ve vašich účtech.
- Nepřijímejte plán přepnutí bez jmenovitě určeného spouštěče návratu zpět a bez způsobu, jak obnovit data zapsaná po přepnutí.
- Štítkování, rozpočty a způsob převzetí předání si dohodněte dřív, než se přesune první aplikace.
Časté dotazy
Má naše portfolio migrovat stejný partner, který ho posuzoval?
Může a často to ušetří čas, protože tým, který inventuru sestavil, zná hraniční případy. Posouzení si ale kupte jako samostatný výstup, který vám patří, abyste s ním mohli jít k jinému partnerovi, pokud vás návrh migrace nepřesvědčí.
Jak porovnat nabídky různých partnerů pro migraci?
Dejte každému partnerovi stejný výtah z inventury a stejné otázky a požádejte každého, aby svá kritéria uplatnil na stejných několik aplikací. Porovnávejte úvahy, plány návratu zpět a předpoklady, na kterých stojí odhady, ne jen celkovou cenu.
Může náš tým během migrace dál vydávat nové funkce?
Ano, pokud plán říká jak. Dohodněte pro každou aplikaci okno zmrazení změn, způsob, jak držet obě prostředí synchronizovaná, dokud se aplikace přesouvá, a kdo schvaluje vydání, dokud je aplikace uprostřed přesunu.