Mistä puhut, kun puhut multi-cloudista? [3 x määritelmä]

Vaikka et vielä operoisi useassa pilvessä yhtä aikaa, on murros väistämättä edessäsi. Mitä termi “multi-cloud” tarkoittaa? Oikeita vastauksia on vähintään kolme.

Hyppää kyytiin tai putoa kehityksen kelkasta, sillä niin se on, että monipilviympäristöt ovat tulleet osaksi työtapojen muutosta. Ihan kuten monoliitit vaihtuivat mikropalveluihin ja funktioihin, tai vesiputousprojektit ketterien menetelmien kautta DevOps-kulttuureihin, näemme nyt, miten yhden pilven strategiat eivät enää välttämättä riitä.

Multi-cloud, multicloud tai monipilvi: miten sinä määrittelet termin? Jokapäiväisissä keskusteluissa huomaan nopeasti, miten eri asioita sana eri ihmisille tarkoittaa.

Käyn seuraavaksi läpi kolme erilaista multi-cloud -strategiaa. Nämä esimerkit kuvaavat tilannetta julkipilviskenaariossa, eli mukaan ei tällä kertaa sotketa yksityisiä “pilviä”. Jos perusteellisempi katsaus hyviin monipilvikäytäntöihin kiinnostaa, lataa whitepaper multi-cloud -haasteiden taklaamisesta.

Kolme multi-cloud -strategiaa

On olemassa ainakin kolme erilaista määritelmää sille, mitä termi “multi-cloud” tarkoittaa. Valitse tilanteeseen sopivin ja varmista, että olet samalla kartalla keskustelukumppanisi kanssa.

1) Työkuormat eri pilvialustoilla

Multi-cloud tarkoittaa, että ajelemme työkuormia eri pilvialustoilla niin, että ne siirtyvät pilvestä toiseen saumattomasti, vaikkapa hinnan tai saatavilla olevien resurssien mukaan. Toisin sanottuna järjestelmät hyödyntävät kahta tai useampaa pilveä ajoalustanaan. Tällainen ympäristö voidaan toteuttaa vaikkapa konttialustoja hyödyntäen.

Ajatus siitä, että kapasiteettia siirreltäisiin jatkuvasti alustalta toiseen, syntyi pilven alkuhämärissä. Siksi idea onkin tänä päivänä sellaisenaan yhtä validi kuin jos katsoisit avaruusaluksen rakennusohjeet vanhasta scifielokuvasta.

Ei tullut kiivaasti päivittyviä pilvipörssejä, ei tullut pelkkiä virtuaaliversioita on-premises -palvelimista. Sen sijaan tuli muullakin kuin hinnalla kilpailevia pilvipalveluntarjoajia: tuli komponenttikirjastoja, transaktiopohjaisia ratkaisuja ja kokonaan uudenlaisia ominaisuuksia, joiden varaan voi rakentaa serverless-sovelluksia.

Skenaario liikuteltavista resursseista elää silti yllättävän monen mielessä sitkeästi. Todellisuudessa kustannushaasteita ei ratkota siirtelemällä sovellusta nopeasti edestakaisin eri alustojen välillä. Hintaerot ovat niin pieniä, eroavaisuudet arkkitehtuureissa niin merkittäviä.

Konttiteknologian hyödyntäminen sen sijaan on tätä päivää. Konttiarkkitehtuureissa sovellukselle rakennetaan alusta, jolla olevia palveluita voi siirtää pilvestä toiseen. Et ehkä halua sitoa kokonaisuutta tietyn pilven natiiveihin mahdollisuuksiin, tai organisaatioosi kohdistuvat vaatimukset sanelevat, ettei järjestelmää saa pultata yhteen alustaan, vaan sen tulee olla siirrettävä.

Tarkoitus ei silloinkaan ole tehdä siirtelyä jatkuvasti, vain varmistaa valmius siihen.

Kriittisesti voisi sanoa, että ykkösvaihtoehto ei ole “aitoa” multi-cloud -tekemistä, vain riskeihin varautumista. Tässä mallissa menetät myös pilven natiivien ominaisuuksien tuomia etuja.

Lue myös: Spotterin Costs -näkymä helpottaa pilven kustannusten hallintaa

2) Järjestelmän osat eri pilvissä

Multi-cloud tarkoittaa, että järjestelmän eri osia ajetaan eri pilvissä. Esimerkiksi tekoälyrajapinta voi olla yhdessä pilvessä, kun taas kantapalvelut pyörivät toisessa pilvessä. Tällöin järjestelmässä voi olla erilaisia, löyhästi kytkettyjä (loosely coupled) komponentteja eri pilvialustoilla.

Järjestelmä on rakennettu ensin tiettyyn julkipilveen. Ajan kuluessa huomataan, että kilpailevassa pilvessä onkin hyvää osaamista ja valmiita komponentteja juuri tietynlaisen datan käsittelyyn. Voisiko ominaisuuksia hyödyntää ilman, että koko järjestelmän pohja tehdään uusiksi?

Se on mahdollista: yksi järjestelmä voi hyödyntää useita eri pilviä, joko valmiiden palvelujen tai rajapintojen kautta.

Tämä lähestymistapa hyödyntää “loosely coupled” -periaatetta, jossa eri osat voivat toimia itsenäisesti, mutta myös yhdessä, tuottaen joustavuutta ja laajennettavuutta.

Skenaario on virhealtis. Riskikerroin nousee, kun järjestelmän toimivuus edellyttää, että kahden tai kolmen pilvipalveluntarjoajan palvelut toimivat jatkuvasti ja saumattomasti yhteen. Tässä yhteydessä löyhästi kytkettyjen komponenttien käyttö voi vähentää riippuvuuksia ja siten vähentää riskejä.

Eri asia on, jos järjestelmä kokoaa tietonsa useista eri järjestelmistä. Eri datakokonaisuudet saattavat sijaita kolmessa tai neljässä eri pilvessä. Puhutaanko silloin enää varsinaisesta multi-cloud-järjestelmästä – siitä voi olla montaa mieltä. Kyse on integraatioista. Ja jos yksi integraatio onkin väliaikaisesti alhaalla, ja tietynlaisen tiedon virta katkeaa hetkeksi, itse sovellus toimii siitä huolimatta.

Lue myös: Digita tarvitsi yhtenäisyyttä pilviympäristöjen välille

3) Eri järjestelmät eri pilvissä

Multi-cloud tarkoittaa, että hyödynnämme monia eri pilviä eri järjestelmiemme ajoalustana riippuen siitä millaisia tarpeita näillä on. Yrityksellä voi olla esimerkiksi asiakaspalvelujärjestelmä, joka toimii AWS-pilvessä, ja BI-järjestelmä, joka toimii Azuressa. Yksittäiset järjestelmät ovat aina yhdessä pilvessä, mutta yrityksen eri järjestelmät ovat eri pilvissä.

On yritykselle hyvin tyypillinen tilanne, että eri sovellukset ja järjestelmät toimivat eri pilvissä. Tilannetta voikin kuvata kaikkein yleisimmäksi multi-cloud-strategiaksi.

Hyvä puoli on, että näin organisaatio pystyy hyödyntämään eri pilvien parhaat puolet. Tiettyyn käyttötarkoitukseen voidaan valita (tai kehittää) se vaihtoehto, joka on aidosti ominaisuuksiensa puolesta paras, eli valintaa ei tarvitse tehdä pilvialusta edellä.

Osa järjestelmistä saattaa toimia täysin erillään. Nykyisin on kuitenkin tavallista, että järjestelmien välille rakennetaan integraatiota, esimerkiksi silloin jos on tarve liikutella AWS:ssä pyörivästä asiakaspalvelujärjestelmästä tietoa Business Intelligence -sovellukseen, joka puolestaan toimii Azuressa.

Tähänkin multi-cloud -strategiaan liittyy haaste, olivat järjestelmät sitten erillisiä tai yhteydessä toisiinsa. Ongelma on hallinnallinen. Kustannuksia pitää mitata, landing zonet pitää rakentaa, tietoturva pitää varmistaa – kaikkiin pilviin yhtä aikaa.

Ok, kohti multi-cloudia, mutta mitä tällä tiedolla pitäisi tehdä?

Sovellukset ja niiden kokonaisuudet monimutkaistuvat. Digiosastosi saattaa vannoa AWS-pohjaisten ja tuotannon puoli Azure-sovellusten nimeen. Monipilviympäristöt hiipivät kuvaan huomaamatta, vaikka niitä ei erikseen tavoittelisi.

Liian monesti huomaa, että ongelma on “ratkaistu” yrityksessä yksinkertaisesti silmät sulkemalla. Tieto liikkuu ehkä niin huonosti, ettei sisäinen IT-osasto edes tiedä, mitä ratkaisuja eri liiketoimintayksiköissä on tehty. Cloud governance -käytännöt ovat irrallisia toisistaan, ja jos ne eivät ole aivan retuperällä, niiden eteen on tehty paljon päällekkäistä työtä.

Keskitetty pilvenhallintamalli ja kokonaiskuvan luominen on ehdottomasti yksi tärkeimmistä ratkaisuista multi-cloud governancen haasteisiin. Hyvä multi-cloud -hallintamalli huomioi riskit ja vaatimukset, mutta ei ole liian raskas tai rajoittava. Sen avulla saat monipilviympäristöistä enemmän irti.

Miten lähdet rakentamaan mallia? Lataa seuraavaksi whitepaper, joka antaa konkreettisia työkaluja multi-cloud governancen hyvien käytäntöjen noudattamiseen.