Toimittajariippuvuus pilvessä: miten rakennat joustavamman pilvistrategian?

Pilvistrategiassa ei enää ratkaista vain teknologiaa

Pilvipalveluita valittaessa huomio on perinteisesti kiinnittynyt esimerkiksi suorituskykyyn, kustannuksiin, skaalautuvuuteen, saatavilla oleviin palveluihin ja oman organisaation osaamiseen. Nämä eivät ole kadonneet mihinkään, mutta niiden rinnalle ovat nousseet entistä vahvemmin kysymykset datan sijainnista, toimittajan omistuksesta, palveluketjuista ja siitä, mitä tapahtuu, jos palvelun saatavuuteen tai toimintaympäristöön tulee merkittävä muutos.

Eurooppalaisista pilvipalveluista käytävä keskustelu liittyy juuri tähän. Ambientian asiakaskeskusteluissa kiinnostus datan sijaintia ja eurooppalaisia vaihtoehtoja kohtaan on kasvanut selvästi. Eurooppalaisuus ei kuitenkaan itsessään tee ratkaisusta hyvää: teknisen toteutuksen, suorituskyvyn, palveluiden ja muiden vaatimusten on edelleen kestettävä sama kriittinen tarkastelu kuin minkä tahansa muun pilvipalvelun.

Eurooppalainen vaihtoehto on siis yksi arvioitava tekijä muiden joukossa, ei itseisarvo. Sen merkitys korostuu erityisesti silloin, kun organisaatiolla on vaatimuksia datan käsittelyn, omistuksen tai palveluketjun suhteen.

Datasuvereniteetti on enemmän kuin datan sijainti

Datasuvereniteetti typistyy helposti kysymykseen siitä, sijaitseeko data Suomessa tai Euroopan unionin alueella. Todellisuudessa kyse on laajemmasta kokonaisuudesta, johon vaikuttavat datan fyysisen sijainnin lisäksi esimerkiksi palveluntarjoajan omistus, toimittajaketju ja palvelun jatkuvuus.

EU:ssa sijaitseva datakeskus ei vielä automaattisesti tarkoita, että koko palveluketju olisi eurooppalaisessa omistuksessa tai hallinnassa. Datan sijainti on tärkeä osa kokonaisuutta, mutta yksin se ei ratkaise suvereniteettia. Myös palvelun jatkuvuutta ja koko toimittajaketjua on tarkasteltava osana riskiä.

Kaikkea dataa ei myöskään tarvitse käsitellä samalla tavalla. Julkisen verkkosivuston sisältö, liiketoiminnan sisäinen tieto, henkilötiedot, liikesalaisuudet ja esimerkiksi terveystiedot muodostavat hyvin erilaisia riskiprofiileja. Pilvistrategiassa kannattaakin lähteä liikkeelle datan ja työkuormien luokittelusta: mitä kriittisemmästä tiedosta tai toiminnosta on kyse, sitä tarkemmin myös sijaintia, hallintaa, jatkuvuutta ja toimittajaketjua on syytä arvioida.

Toimittajariippuvuus ei synny vain sopimuksesta

Vendor lock-inista puhuttaessa ensimmäisenä voi tulla mieleen pitkä sopimus, josta on vaikea päästä irti. Pilviympäristössä huomattavasti olennaisempi riippuvuus syntyy kuitenkin usein teknologiasta. Perustason infrastruktuuri voi olla verrattain helposti siirrettävissä palveluntarjoajalta toiselle, mutta toimittajakohtaiset palvelut voivat kytkeä sovelluksia tiukemmin tiettyyn ympäristöön.

Mitä enemmän käyttöön otetaan tietyn pilvialustan omia hallittuja tai muuten toimittajakohtaisia palveluita, sitä enemmän siirtyminen voi vaatia muutoksia myös sovelluksiin, arkkitehtuuriin ja toimintalogiikkaan. Käytännössä riippuvuus voikin muodostua huomaamatta useasta pienestä teknisestä päätöksestä.

Valmiita palveluita käytetään silti hyvästä syystä. Tietokanta, kuormantasaus, Kubernetes-klusteri tai muu hallittu palvelu voi poistaa valtavan määrän ylläpitotyötä, eikä kaikkea olisi järkevää rakentaa itse vain siksi, että jokainen komponentti olisi teoriassa mahdollisimman helposti vaihdettavissa. Siksi olennaisempi kysymys ei ole, syntyykö riippuvuuksia, vaan tiedetäänkö, missä ne sijaitsevat ja mitä niiden purkaminen myöhemmin vaatisi.

Hyvä vendor lock-in on tietoinen päätös

Toimittajariippuvuuden hyväksyminen voi olla täysin perusteltu liiketoimintapäätös. Jos tietty palvelu nopeuttaa tuotteen markkinoille saamista merkittävästi, vähentää ylläpitotarvetta tai tarjoaa ominaisuuksia, joiden rakentaminen itse olisi kallista, hyöty voi olla selvästi suurempi kuin mahdollinen tulevaisuuden vaihtokustannus.

Ongelma syntyy silloin, kun tätä vaihtokustannusta ei ole koskaan arvioitu. Palvelua käyttöönotettaessa pitäisi ymmärtää ainakin se, kuinka riippuvaiseksi siitä tullaan ja mitä vaihtoehtoja on olemassa, jos palvelu joskus halutaan tai joudutaan korvaamaan. Parhaimmillaan vaihtoehto tunnistetaan jo arkkitehtuuria suunniteltaessa, vaikka rinnalle ei rakennettaisikaan valmiiksi toista toteutusta.

Toimittajakohtaisesta palvelusta saatava liiketoimintahyöty voi siis hyvin oikeuttaa riippuvuuden, mutta silloin myös riski pitäisi tunnistaa etukäteen. Näin vendor lock-inista tulee hallittu valinta eikä myöhemmin paljastuva yllätys.

Avoimet teknologiat lisäävät vaihtoehtoja – mutta eivät poista riskejä

Avoimen lähdekoodin ja laajasti käytettyjen standarditeknologioiden yksi keskeinen etu on siirrettävyys. Jos tietokanta, konttialusta tai infrastruktuurin hallinta perustuu teknologiaan, jota useat palveluntarjoajat tukevat, siirtyminen ympäristöstä toiseen on yleensä helpompaa kuin silloin, kun koko toteutus perustuu yhden toimittajan omaan teknologiaan.

Tästä ei kuitenkaan seuraa, että avoin lähdekoodi automaattisesti poistaisi toimittajariippuvuuden. Projektin lisensointi voi muuttua, kehitys voi hiipua tai käytetty palvelu voi poistua palveluntarjoajan valikoimasta. Organisaatioon voi myös vuosien aikana muodostua niin paljon tiettyyn teknologiaan liittyvää osaamista ja prosesseja, että vaihtaminen on käytännössä kallista, vaikka se olisi teknisesti mahdollista.

Siksi hyvä arkkitehtuuri ei perustu vain tämän päivän teknologioihin vaan myös kykyyn korvata yksittäisiä osia. Olennaista on tunnistaa, mitkä komponentit ovat aidosti vaihdettavissa ja missä kohdissa vaihtaminen vaatisi suuremman muutoksen.

Modulaarisuus tekee muutoksesta hallittavamman

Modulaarisuus on yksi konkreettisimmista tavoista valmistautua tulevaisuuteen. Ajatus on yksinkertainen: kokonaisuus pitäisi rakentaa niin, ettei yhden komponentin vaihtaminen edellytä koko järjestelmän rakentamista uudelleen.

Siirrettävyys ja modulaarisuus näkyvät jo myös kilpailutusten vaatimuksissa. Teknologiavalinnoilta voidaan edellyttää sitä, että yksittäinen komponentti voidaan tarvittaessa vaihtaa toiseen ilman kohtuuttoman suurta muutosta koko ympäristöön.

Tämä on realistisempi tavoite kuin täydellinen toimittajariippumattomuus. Täysin neutraali arkkitehtuuri voi johtaa siihen, ettei minkään alustan vahvuuksia pystytä hyödyntämään kunnolla, kun taas modulaarinen arkkitehtuuri sallii alustakohtaisten palveluiden käytön mutta pyrkii rajaamaan niiden vaikutukset hallittaviin osiin kokonaisuutta.

Multicloud voi hajauttaa riskiä – mutta se ei ole itseisarvo

Yksi tapa vähentää riippuvuutta yhdestä toimittajasta on käyttää useampaa pilvipalvelua. Multicloud ei kuitenkaan tarkoita sitä, että jokainen sovellus pitäisi pystyä ajamaan samanaikaisesti useassa pilvessä, sillä se olisi monessa ympäristössä tarpeettoman kallista ja monimutkaista.

Käytännössä pilviympäristöjä voidaan jakaa työkuormittain niin, että osa palveluista sijaitsee yhden palveluntarjoajan ympäristössä ja osa toisen. Siirtymiäkään ei yleensä tarvitse tehdä yhdellä kertaa, vaan ympäristöä voidaan muuttaa pala kerrallaan. Tällainen vaiheittainen lähestymistapa voi olla realistinen tapa rakentaa multicloud-strategiaa ja jakaa riskejä.

Samalla on muistettava, että useampi pilvi tuo mukanaan myös lisää hallittavaa. Kahden tai kolmen ympäristön käyttäminen ei automaattisesti tee kokonaisuudesta parempaa, jos samalla ylläpito, osaamisvaatimukset ja kustannukset kasvavat enemmän kuin saavutettava hyöty.

Kaikkea osaamista ei tarvitse pitää talon sisällä

Pilvipalveluiden yleistyminen on muuttanut myös sitä, millaista teknistä osaamista yrityksen kannattaa ylläpitää itse. Kaikkien tietokantojen, Kubernetes-klustereiden tai infrastruktuuripalveluiden ylläpitoon ei välttämättä ole järkevää rakentaa omaa tiimiä, sillä hallitut palvelut ja kumppanit ovat olemassa juuri siksi, ettei jokaisen organisaation tarvitse ratkaista samoja infrastruktuuriongelmia uudelleen.

Ulkoistaminen ei kuitenkaan tarkoita omistajuuden ulkoistamista. Yrityksen pitäisi edelleen ymmärtää, mistä sen ympäristö muodostuu, mitkä järjestelmät ovat liiketoiminnan kannalta kriittisiä, mitä riippuvuuksia niiden välillä on ja minkä kumppanin vastuulla mikäkin osa kokonaisuudesta on. Kumppaneita voi olla useita ja paljon voidaan ostaa palveluna, mutta kokonaisuuden ymmärryksen pitää säilyä organisaatiossa.

Tämä korostuu etenkin monitoimittajaympäristöissä, joissa yksittäinen kumppani näkee vain oman osansa kokonaisuudesta. Asiakkaan tehtäväksi jää pitää kokonaisuudesta riittävä omistajuus ja kyky tehdä sitä koskevia päätöksiä.

Dokumentaatio on osa exit-strategiaa

Yksi käytännöllisimmistä tavoista vähentää tulevaisuuden toimittajariippuvuutta on myös yksi vähiten eksoottisista: dokumentaatio. Viiden vuoden kuluttua ympäristöä ylläpitävät ihmiset eivät välttämättä ole samoja kuin ne, jotka tekivät alkuperäiset ratkaisut, ja arkkitehtuurin on saattanut rakentaa ulkopuolinen kumppani.

Järjestelmään voi vuosien aikana kertyä riippuvuuksia, joiden taustalla olevia päätöksiä kukaan nykyisessä tiimissä ei enää tunne. Silloin teknisesti yksinkertaiseltakin näyttävä siirtymä voi muuttua vaikeaksi, koska kukaan ei tiedä varmasti, miksi jokin komponentti on olemassa tai mihin kaikkeen se vaikuttaa.

Dokumentaatiosta pitäisi siksi käydä ilmi paitsi mitä on rakennettu, myös miksi tietyt valinnat on tehty. Se auttaa myöhemmin erottamaan aidosti välttämättömät riippuvuudet sellaisista ratkaisuista, jotka voidaan korvata. Samalla dokumentaatio pienentää hiljaisen tiedon katoamiseen liittyvää riskiä henkilöstön tai kumppaneiden vaihtuessa.

Pilven kustannuksia pitää tarkastella myös tulevaisuuden kustannuksina

Pilvipalveluiden hinnoittelussa huomio kiinnittyy helposti nykyiseen kuukausilaskuun. Todelliseen kustannukseen vaikuttavat kuitenkin myös esimerkiksi dataliikenne, tallennus, tietokantaoperaatiot ja muut käytön mukaan veloitettavat palvelut. Uusien AI-palveluiden myötä mukaan ovat tulleet myös tokenpohjainen laskutus ja tilanteet, joissa huonosti rajattu käyttö voi kasvattaa kustannuksia nopeasti.

Kustannusten toinen puoli on vaihtamisen hinta. Ratkaisu voi olla tänään erittäin kustannustehokas, mutta jos se tekee myöhemmästä siirtymisestä poikkeuksellisen kalliin, myös tämä pitäisi ainakin tunnistaa päätöstä tehtäessä. Tarkoitus ei ole optimoida kaikkea viiden vuoden päässä mahdollisesti tapahtuvaa muutosta varten, vaan ymmärtää nykyisen hyödyn ja tulevan riippuvuuden välinen suhde.

Tekoäly tuo samat pilvistrategian kysymykset uudessa muodossa

AI ei poista pilviarkkitehtuurin peruskysymyksiä vaan tuo ne uudelleen esiin. Missä dataa käsitellään, kuka pääsee siihen käsiksi, mihin palveluun ratkaisu sitoutuu, kuinka ennustettavia kustannukset ovat ja voidaanko malli tai sitä ympäröivä palvelu vaihtaa myöhemmin?

Valmiiden AI-palveluiden käyttöönotto voi olla erittäin helppoa, mikä samalla voi nopeuttaa uusien riippuvuuksien syntymistä. Palvelu otetaan osaksi sovellusta nopeasti, ja vasta myöhemmin huomataan, kuinka syvälle sen rajapinnat, hinnoittelumalli tai muut ominaisuudet ovat kytkeytyneet kokonaisuuteen.

Kyse ei ole siitä, etteikö näitä palveluita pitäisi käyttää. Samat periaatteet vain pätevät myös niihin: tiedä, mitä otat käyttöön, mitä siihen sitoutuminen tarkoittaa ja mikä on vaihtoehto, jos olosuhteet muuttuvat.

Pilvistrategia ei ole kertaluonteinen projekti

Pilvistrategiaa ei voi tehdä kerran ja jättää pöytälaatikkoon. Teknologiat muuttuvat, palveluntarjoajat muuttavat palveluvalikoimiaan ja hinnoitteluaan, avoimen lähdekoodin projektien lisenssit voivat vaihtua ja organisaation omat tarpeet sekä osaaminen kehittyvät.

Siksi toimittajariippuvuuden hallinta on jatkuvaa työtä. Tavoitteena ei tarvitse olla ympäristö, jossa jokainen komponentti voidaan huomenna vaihtaa toiseen, vaan arkkitehtuuri, jossa yritys tuntee riippuvuutensa, ymmärtää niiden liiketoimintaperusteet ja säilyttää riittävästi vaihtoehtoja tilanteisiin, joissa suunnitelmaa on muutettava.

Hyvä pilvistrategia ei poista valintoja tai sitoutumista. Se tekee niistä tietoisia ja hallittavia osana arkkitehtuurin jatkuvaa kehittämistä.

Haluatko arvioida oman pilviarkkitehtuurisi vaihtoehtoja?

Ambientia auttaa organisaatioita arvioimaan pilviarkkitehtuuria, teknologiavalintoja ja eri toteutusvaihtoehtoja liiketoiminnan tarpeista lähtien. Jos haluat tunnistaa nykyisen ympäristösi riippuvuuksia tai arvioida vaihtoehtoja tulevaisuuteen, keskustellaan tilanteestasi tarkemmin.