Onko pilveen vain menolippuja?
Pilveen mennään usein rytinällä pelkkä menolippu taskussa. Koska kaikki sinne pyrkivät, miksi ihmeessä miettiä jo etukäteen exit-strategiaa? Mutta tarpeen se on silti ja minäpä kerron miksi.
Oikeastaan paluukaistan unohtaminen jopa hämmästyttää. Kuvittelisi ainakin riskinhallintajamppojen haluavan undo-toiminnallisuuden jokaiseen projektiin. Myönnettäköön, että itse näen julkipilven tehokkaimpana tapana tuottaa IT-palveluita. En usko näkeväni montaakaan tapausta, joissa aidosti tekniset tai liiketaloudelliset syyt pakottaisivat pilvipoistumaan. Voi kuitenkin tulla esimerkiksi tarve päästä pois entisestä pilvestä voidakseen rynniä uuteen ja uljaaseen. Olenpa itsekin ollut muutamassa exit-projektissa mukana, joskin näissä ajureina olikin juuri vaihto toisen merkkiseen pilveen. Tästäkin syystä voisi poistumistien viitoittamisen sisällyttämistä jo pilveen siirtymisvaiheessa pitää järkevänä ideana.
Miten pilvestä sitten pääsee pois?
Lähtökohtaisesti kyse on pilvimigraatioprojektin toteuttamisesta käänteisenä. Landing Zone on siis poistumistie pilvestä eli joko hosting-yrityksen tai omissa tiloissa sijaitseva virtuaali-infra tai toinen julkipilvi. Ikävä kyllä julkipilvitoimijoiden kivat ja edulliset migraatiotyökalut ja ohjeistot eivät tue pilvestä poistumista. Julkipilvestä toiseen tietenkin tarjotaan työkalut kohdepilven taholta. Omaan konesaliin siirtyjän taas täytyy haalia työkalut kaupallisten toimijoiden kilkkeistä.
Eroa siinä, onko migraatio konesalilta pilveen, pilvestä toiseen tai pilvestä konesaliin, ei juuritaan tekemisessä ole. Vähän vaivaa, mutta ei mitään rakettitiedettä. Kontitettujen työkuormien suhteen – siis tuo välivaihe virtuaalikonepohjaisten työkuormien ja aidosti serverittömän prosessoinnin välillä – siirtely on vieläkin helpompaa.
Mutta sitten kun tuomme kuvaan mukaan ”modernisoidut työkuormat”, haasteellisuusaste kasvaakin melkoisesti. Toki aivan sama kompleksisuus meillä oli silloinkin, kun työkuormia julkipilveen siirtelimme. Modernisoinnilla tarkoitetaan yleisesti sitä, että hyödynnetään julkipilven palveluita laajemmin kuin pelkkien virtuaalikoneiden ajoympäristönä. Käytettäessä PaaS-tyyppisiä palveluita on jouduttu rakentamaan palvelut julkipilveen kertaalleen uusiksi. Käänteisessä migraatiossa koodaat ja rakennat samat palvelut jälleen kerran uudelleen. Tuskallisinta tämä on silloin, kun tietyt palvelut on rakennettu ”suoraan pilveen”, eli käytännössä softakumppanisi on rakentanut teille myydyn ratkaisun julkipilvitoimittajan teknologian varaan. Näiden osalta pilvi-exit edellyttää koko rakennelman toteutusta uudelleen, toisen teknologiapinon varaan.
Pilvitoimijoiden PaaS-palvelut ovat aina nk. vendor lock. Eli rakennettu hässäkkä toimii ja pyörii vain ja ainoastaan sen julkipilven teknologioiden varassa, johon se alun perin on rakennettu.
Tärkeä kysymys onkin, miksi ihmeessä menisit edes siirtämään PaaS-palveluiden tai vastaavien toimittajalukittujen teknologioiden varaan rakennettuja palveluita. Organisaatiossanne on todennäköisesti käytössä jo vaikka mitä verkko- ja pilvipalveluita. Olette jo hyväksyneet sen, että SaaS-palvelut (esim. M365, Salesforce, Monday jne.) ovat missä ovat ja maksatte vain palvelusta vaihtoehtona ohjelmistolisenssien ostolle.
PaaS- ja SaaS-palvelut ovat siis oma kokonaisuutensa. Niiden migraatiossa pelkän toimittajavaihdoksen tai vastaavan takia ei ole järkeä. Vaikka siirtäisitkin kaikki IaaS-työkuormasi (virtuaalikoneet + kontit) esimerkiksi Azuresta Googleen, voit aivan hyvin jättää PaaS-palveluiden varaan rakennetut elementit Azureen. Toisaalta joku käyttämäsi SaaS-palvelu on taatusti tuotettu AWS:n laskentavoiman varassa. Molempien yhdistäminen GCP:n IaaS-työkuormiin on yhtä helppoa tai vaikeaa kuin samaisten palveluiden yhdistäminen Azuren IaaS-palveluihin. Yleisesti ottaen erilaiset PaaS-palvelut edustavat varsin marginaalista osaa kokonaiskuluista, joita julkipilvi organisaatiolle tuottaa. Sekin puolustaa näkemystä, että PaaS- ja SaaS-palvelut kannattaa käsitellä erikseen.
Entäpä huoltovarmuus?
Haastavin tilanne on huoltovarmuus-tyyppisissä käyttötapauksissa, joissa täytyisi varmistaa palveluiden saatavuus myös mahdollisessa äärimmäisessä yhteiskunnallisessa poikkeustilanteessa. Yhteydet julkipilviin ovat varsin haavoittuvia. IaaS-palveluista on helppoa ja jopa verrattain kustannustehokastakin rakentaa DR-saitti konesaliin. Nämä PaaS-palvelut ovat siksi todella hankala ja arvokas pähkinä purtavaksi. Pilvitoimittajien omat nk. edge-teknologiat ovat ainoa vähääkään suoraviivainen tai kustannustehokas tapa. Pilvistä maan päällä olen pitänyt webinaarin , josta saat lisätietoa pilvenreunateknologioista. Vaikka webinaarin varsinainen kärki ei olekaan huoltovarmuusajattelussa, aihealue ja teknologiat ovat tähänkin sopivat. Tästä ”lähipilvi”-kehityssuunnasta kannattaa lukaista myös blogi.
SaaS-palvelut joudut ikävä kyllä unohtamaan huoltovarmuuden kannalta. Niitä et pysty peilaamaan maan päälle mitenkään, ellei nyt kyseinen SaaS-palvelu sitten tarjoa jotain hybridiratkaisua. Tämä kannattaa ottaa huomioon huoltovarmuuslain koskettamilla toimialoilla tietojärjestelmävalintoja tehtäessä. Riittäisikö ehkä se, että SaaS-palvelun sisältämä data olisi käytettävissä vaikkei palveluun päästäisi?
Vaikka uutisia isojen SaaS-palveluiden kadottamista tiedoista ei olekaan näkynyt (mikä kertoo jo jotain näiden palveluiden tekniikan laadusta), tutkimusten mukaan 40 % organisaatioista on menettänyt tietoa SaaS-palveluissa. Toki 2/3 menetyksistä on aiheutunut käyttäjien turauksista. Mutta menetettyä tietoa ne silti ovat. Jos varmistat CRM:n omassa konesalissasi, kannattaisiko ehkä harkita pilvessä olevan CRM:nkin tietojen suojaamista?
Menikö ohi ajatuksen ja kaarsi kaukaa jakauksesta? Eipä hätää. Klikkaa itsesi pilvi–suomi-sanakirjaan, josta löydät blogissa käytetyn termonilogian kattavasti selitettynä.
