5 nejčastějších chyb při migraci do cloudu

Tisíce zákazníků SoftwareOne se nacházejí někde uprostřed cesty své organizace do cloudu. Každý týden hovořím s IT manažery, kteří vyvíjejí strategie pro migraci své organizace do cloudu. Nejen při těchto rozhovorech jsem zaznamenal 5 opakujících se témat, která osobně považuji za chyby při zavádění veřejného cloudu.

1. Vnímání přechodu do cloudu jako pouhé náhrady datového centra

Někteří manažeři, s nimiž hovořím, se na cloud dívají až příliš z pohledu infrastruktury. Pak si mohou myslet, že stačí říct: „Pojďme a udělejme to rychle“. Abyste však mohli takto postupovat, musíte ignorovat problémy spojené s neoptimalizovanými přesuny do cloudu i projekty, které vašemu podniku nepřinesou žádnou nebo jen malou hodnotu.

Možná, že se vaše společnost právě zavázala k pořízení kapacit u poskytovatele hyperškálovatelných cloudových služeb a čas běží. Spousta aplikací bude jen přemístěna s odůvodněním, že „už jsme za to zaplatili“. Vzhledem k tomu, že aplikace obvykle zůstávají beze změny, po měsících investic do cloudu vás čeká přinejlepším scénář, že budou migrované aplikace fungovat a chovat se úplně stejně jako v datovém centru. To ale přinese jen málo ze slibovaných příslibů cloudu.

2. Upřednostňování aplikací k migraci spíše na základě technologie než podle přínosů pro podnik

Někteří naši zákazníci chtějí migrovat aplikace do cloudu nikoliv podle toho, co by mělo největší přínos pro firmu, ale podle toho, co je technicky nejvýhodnější. Tento přístup zjednodušuje práci a dává IT oddělení větší pružnost při přesunu, avšak výsledek může podniku přinést zklamání.

Manažeři mají ohledně přínosů cloudu vysoká očekávání, k čemuž přispívá i marketing poskytovatelů hyperškálovatelných cloudových služeb. Přesun do cloudu a poskytování stejné zkušenosti při podobných nákladech však nemusí stačit. Platí to zejména v případě, kdy proces migrace spotřebovává mnoho zdrojů IT, ovlivňuje běžný provoz nebo znamená odklad jiných strategických projektů.

3. Teoretické plánování migrace namísto přístupu založeného na nástrojích a osvědčených postupech

Mnoho organizací se spoléhá na interní předpoklady o technické životaschopnosti, konzistenci architektury, kvalitě kódu a možnostech refaktorizace. (Ostatně, kdo by chtěl všechen fungující kód vyhodit?) Předběžné předpoklady v procesu plánování mají často bumerangový efekt. Je až šokující, kolikrát se migrace do cloudu plánuje s malým přehledem o tom, jaké změny v aplikacích bude nutné provést nebo jak proveditelná bude refaktorizace konkrétních aplikací.

I v rámci refaktorizace existuje několik úrovní úsilí. Refaktorovat aplikaci tak, aby běžela na PaaS, nebo opravit problémy se zabezpečením, není totéž co kompletně ji přepracovat s využitím principu mikroslužeb. Nejlepším způsobem, jak zjistit, co máte a co je potřeba pro migraci zařídit, je použít automatizované nástroje pro zjišťování a kontrolu, spolu s metodami ověřenými v daném oboru.

4. Oddělené vývojové a provozní cloudové strategie

Při zavádění cloudu se IT manažeři zaměřují na náhradu datového centra a úsporu nákladů na infrastrukturu, zatímco vývojové týmy se soustředí na produktivitu a nové možnosti aplikací. Tyto skupiny musejí záměrně spolupracovat na často podceňovaných problémech spojených s nasazením cloudu. Jak nyní funguje zálohování? Jak rozšíříme naše bezpečnostní prostředí do cloudu? Jaký je správný model řízení v cloudu? To jsou jen některé z mnoha otázek, které si je potřeba pokládat.

5. Tradiční způsob uvažování o nákladech

Když pomáháme zákazníkům vytvářet projektové záměry migrace do cloudu a sledujeme, jak porovnávají cloudové a on-premise úlohy, často vidíme, že jim chybí odborné znalosti v oblasti FinOps, které by jim umožnily řídit sofistikovanější scénář nákladů a nákupu v multicloudovém světě. Systémoví integrátoři a cloudoví architekti jen zřídka bývají zároveň i odborníky na software nebo licence. Nezaměřují se na cenovou dynamiku světa IT.

Pokud si například chcete koupit licenci na databázi nebo jiný konkrétní softwarový produkt, máte možnost nakupovat přímo na cloudových tržištích, ale také prostřednictvím tradičních smluv na software s hybridními, on-premise a cloudovými oprávněními. Jestliže při vytváření projektového záměru vycházíte z předpokladu, že bude software pořízen v cloudu jako řešení typu SaaS (což se může architektovi zdát rozumné), je to jednoduše špatný způsob, jak sestavit odhad nákladů. Ve skutečnosti jsme se setkali s mnoha situacemi, kdy projektové záměry v cloudu nevycházejí, protože náklady na software jsou nadhodnocené či nejsou optimalizované. S tím se setkáváme i u cloudové infrastruktury, kde jednotkové náklady často zlepšují dlouhodobé smlouvy.