Verslo infrastruktūros perkėlimas į debesį gali labai supaprastinti vidines operacijas. Tai taip pat suteikia jums ekspertų pagalbos ir padeda išlaikyti nuspėjamą, reguliarų tvarkaraštį.
Tačiau nebūtinai reikia pasirinkti vieną paslaugų teikėją ir laikytis jo amžinai. Įmonės vystosi, o jūsų poreikius šiandien atitinkantis debesies partneris gali būti netinkamas po kelerių metų. Be to, aptarnavimas ir palaikymas gali neatitikti jūsų lūkesčių. Net jei šiuo metu nenorite imtis veiksmų, verta apsvarstyti savo pasitraukimo strategiją – visada būkite pasiruošę galimybei, kad galbūt norėsite pereiti prie kito teikėjo.
Frankas Jenningsas, komercinių sutarčių teisininkas, besispecializuojantis debesijos paslaugų srityje, dalyvavo daugelyje perkėlimo projektų. „Kai kalbu su debesijos paslaugų teikėjais, – sako jis, – paprastai jie labai džiaugiasi perkeldami klientą, kuris nenori būti su jais. Taip sektorius vystosi. Mažai tikėtina, kad jie iš anksto tiksliai nurodys, kiek kainuos perkėlimas, bet ten yra būdas sumažinti netikrumą – pavyzdžiui, jie gali susitarti dėl pagalbos klientams dienos tarifo migruoti“.
Tačiau norint užtikrinti, kad viskas vyktų sklandžiai, svarbu tiksliai suprasti, kokios yra jūsų teisės ir pareigos. Tai prasideda nuo to, kad atsižvelgsite į minimalų sutarties terminą. Ne visose sutartyse yra tokia sąlyga: daugybė paslaugų teikėjų lanksčiai, mokamai išnuomoja saugyklą ir serverio energiją, įskaitant didelius berniukus, tokius kaip „Amazon Web Services“ (AWS). Tačiau didesnis perkėlimas dažnai susijęs su laiko įsipareigojimu leisti teikėjui kompensuoti jų įrengimo išlaidas. „Jei visą infrastruktūrą perkeliate į debesį, teikėjas iš anksto pareikalaus didelių investicijų“, – pažymi Jennings.
Tai reiškia, kad nebūtinai galite judėti pirmyn – net jei paslauga neveikia taip, kaip tikėtasi. „Yra daugybė pardavimo pažadų, kurie nepatenka į galutinę sutartį“, – perspėja Jennings. „IT paslaugų teikėjai paprastai naudoja SLA [paslaugų lygio sutartis], todėl „100 % pasiekiamumas“, kurį pažadėjo pardavėjas gali būti išverstas į „99,999%, išskyrus suplanuotą prastovą“, kartu su įvairiomis kitomis išimtys. Kitas dalykas, į kurį reikia atkreipti dėmesį, yra paslaugų kreditas kaip vienintelė priemonė – dar nesutikau kliento, kuris būtų patenkintas gavęs kreditą iš kitos sąskaitos faktūros debesijos paslaugų teikėjui, kuris nevykdo veiklos.
Net jei atrodo, kad jūsų debesies paslaugų teikėjas mielai padeda pereiti, verta pagalvoti, kas nutiks, jei išsiskirsite blogomis sąlygomis. „Verslas gali pereiti iš vieno debesies į kitą, nes jis iškrito“, – sako Jennings, „todėl mažiau tikėtina, kad išeinantis paslaugų teikėjas sulauks geros valios, kad suteiktų pagalbą. Lygiai taip pat bet kokiuose verslo santykiuose, kai jie pradeda žlugti. Jei turite sutartį, kuri apima įsipareigojimus, tai palengvina: kiek įmanoma, iš pradžių turite susitarti dėl perėjimo plano arba bent jau visiško įsipareigojimo.
Vertėtų pagalvoti, kas nutiks, jei išsiskirsite blogomis sąlygomis
Taip pat atsižvelkite į savo duomenų apsaugos įsipareigojimus. Nekyla jokių teisinių problemų leisti trečiajai šaliai tvarkyti jūsų klientų įrašus, o kai ateina laikas perkelti, jie privalo perduoti visą jūsų turtą. Tačiau turėtumėte gauti patvirtinimą, kaip ir kada jautrūs duomenys bus ištrinti iš pradinio serverio. Laimei, tai paprastai nėra problema: „Išeinantis paslaugų teikėjas tikriausiai bus daugiau nei pasirengęs ištrinti tuos duomenis“, - pažymi Jennings. „Jie nenorės laikyti papildomų išteklių, kuriuos kitu atveju galėtų parduoti kam nors kitam“.
Praktiniai svarstymai
Debesijos paslaugų teikėjai ne visada nori pamatyti, kaip klientai išvyksta, tačiau jie, kaip galima nuspėti, nori padėti naujiems klientams pereiti prie jų platformų. Kai kurie operatoriai, pvz., AWS, siūlo sumanias perdavimo sistemas, kad būtų kuo lengviau pasiekti jų sistemas. „Suteikiame klientams įrankius, kad perėjimas būtų kuo lengvesnis“, – aiškina „Amazon“ atstovas Ianas Massinghamas. „Kažkas, ką klientai naudoja, yra Amazon VPC [Virtual Private Cloud] ir AWS Direct Connect derinys.
Tai reiškia, kad klientai gali išplėsti esamus tinklus iš savo patalpų arba esamų debesijos paslaugų teikėjų į AWS, o tai veikia kaip esamos aplinkos išplėtimas. Duomenys gali būti sinchronizuojami arba perkeliami su minimaliomis pertraukomis, o kai jie yra pasirengę pakeisti gali tiesiog pakeisti DNS [domeno vardų sistemos] įrašus ir pradėti aptarnauti klientus iš naujojo AWS infrastruktūra“.
Tai vis dar palieka daug praktinių klausimų, kuriuos reikia apsvarstyti. Pirmasis, pasak Simono Mohro iš Stonegate IT, yra paprastas laiko klausimas. „Kiek prastovų yra priimtina verslui ir kada tai gali būti? jis klausia. „Verslo įmonės turi skirti pakankamai laiko, kad migracija įvyktų be prievartos neprotingi terminai“. Be verslo tikslų, tai gali apimti griežtus terminus, pavyzdžiui, perėjimą prie naujo patalpose.
Visų pirma, Mohras perspėja, kad nereikėtų per daug šaudyti, kad nebūtų prastovos. „Yra įrankių, kuriuos galima naudoti duomenims sinchronizuoti realiuoju laiku“, – pažymi jis, „tačiau tiesioginių duomenų sinchronizavimas kelia naujų pavojų. Sutikimas su nedideliu prastovų kiekiu mažai naudojamo naudojimo metu yra mažesnės rizikos duomenų perkėlimas.
