Pet ključnih napak migracije v oblak

V podjetju SoftwareOne imamo na tisoče strank, ki so sredi procesa uvajanja storitev v oblaku. Vsak teden se pogovarjam z vodji IT oddelkov, ki razvijajo strategije za oblak. Opažam pet ponavljajočih se stvari, za katere menim, da so napake pri sprejemanju javnega oblaka.

1. Pristop k selitvi v oblak, kot da gre zgolj za zamenjavo podatkovnega centra

Nekateri vodje, s katerimi se pogovarjam, na oblak gledajo s strogo infrastrukturnega vidika V takšnih primerih mislijo: »Gremo v to in hitro opravimo.« A s takim pristopom boste morali prezreti težave, ki so posledica neoptimiziranih premikov v oblak in projektov, ki prinašajo malo ali nič poslovne vrednosti.

Morda se je vaše podjetje pravkar zavezalo enemu izmed hiperskalerjev in ura teče. Pri številnih aplikacijah prihaja do spremembe gostovanja z utemeljitvijo »smo že plačali za to«. Ker aplikacije običajno ostanejo nedotaknjene, je po mesecih vlaganja v oblak najboljši scenarij, da preseljene aplikacije delujejo in se obnašajo popolnoma enako kot lokalne različice. Nekaj napihnjenih obljub glede oblaka – aplikacije bodo izgledale in delovale enako.

2. Prednostno razvrščanje aplikacij za migracijo temelji na tehnoloških vidikih in ne na poslovnih rezultatih

Nekatere naše stranke želijo preseliti aplikacije glede na to, kar je tehnično najbolj primerno, vendar tega ne uravnotežijo s tem, kar bo privedlo do največjega poslovnega učinka. Ta pristop poenostavlja delo in daje IT oddelkom večjo agilnost pri selitvi, vendar je rezultat lahko za podjetje razočaranje.

Vodstveni delavci imajo visoka pričakovanja glede tega, kaj lahko nudi oblak (pri čemer jim pomagajo obljube hiperskalerjev). Prehod v oblak ter zagotavljanje enake izkušnje in podobnih stroškov morda ne bo dovolj. To še zlasti velja, če proces migracije porabi veliko informacijskih virov, je prizadeta običajna storitev ali pride do odložitve drugih strateških projektov.

3. Pristop, ki temelji na teoretičnem načrtovanju, namesto pristopa, ki temelji na orodjih in najboljših praksah

Številne organizacije se zanašajo na notranje predpostavke o tehnični izvedljivosti, doslednosti arhitekture, kakovosti kode in zmožnostih preoblikovanja. (Kdo bi rad zavrgel celotno kodo, ki deluje?) Predpostavke v procesu načrtovanja imajo pogosto učinek bumeranga. Šokantno je videti, kolikokrat so migracije v oblak načrtovane z zelo malo vpogleda v to, katere spremembe aplikacij so morda potrebne ali v kolikšni meri bo refaktoriranje določenih aplikacij sploh izvedljivo.

Tudi znotraj kategorije refaktoriranja obstajajo različne ravni prizadevanj. Ni isto, če se aplikacija refaktorira zgolj tako, da deluje na PaaS, ali da se odpravijo varnostne težave, saj jo je v takšnem primeru treba popolnoma prenoviti z uporabo mikrostoritvenih pristopov. Najboljši način, da ugotovite, kaj imate in s čim se boste pri migraciji morali soočiti, je uporaba avtomatiziranih orodij za odkrivanje in preverjanje skupaj z drugimi metodami, uveljavljenimi v panogi.

4. Ločitev razvojnih in operacijskih strategij za oblak

Pri uvajanju oblaka so vodje IT oddelkov pozitivno naklonjeni menjavi podatkovnega centra in prihrankom pri stroških infrastrukture, medtem ko se razvojne ekipe osredotočajo predvsem na produktivnost in nove zmogljivosti aplikacij. Te skupine morajo načrtno sodelovati pri pogosto podcenjenih izzivih sprejemanja oblaka, kot so npr. naslednja vprašanja: Kako zdaj deluje varnostno kopiranje? Kako razširimo našo varnost tudi na oblak? Kakšen je pravi model upravljanja v oblaku?

5. Preveč tradicionalno razmišljanje o stroških

Ko strankam pomagamo ustvariti poslovne primere okolja v oblaku ter gledamo, kako primerjajo delovne obremenitve v oblaku in lokalno, pogosto vidimo, da jim primanjkuje strokovnega znanja s področja finančnega upravljanja oblaka, ki je potrebno za upravljanje bolj sofisticiranega scenarija stroškov in naročil v večoblačnih okoljih. Sistemski integratorji in arhitekti oblaka so le redko strokovnjaki za programsko opremo ali licenciranje. Niso osredotočeni na cenovno dinamiko IT sveta.

Na primer, če želite kupiti licenco za bazo podatkov ali drug konkreten programski izdelek, imate možnost nakupa neposredno na tržnicah v oblaku, pa tudi prek tradicionalnih pogodb o programski opremi s hibridnimi, lokalnimi in oblačnimi pravicami. Če gradite svoj poslovni primer na predpostavki, da bo programska oprema nabavljena v oblaku kot rešitev SaaS (kar se morda zdi smiselno za arhitekta), je to preprosto napačen način za izdelavo ocene stroškov. Pravzaprav smo videli veliko situacij, kjer poslovni primer v oblaku ne deluje, ker so stroški programske opreme precenjeni ali niso optimizirani. To opažamo tudi pri infrastrukturi v oblaku, kjer dolgoročne pogodbe pogosto izboljšajo stroške na enoto.