Pilvipalvelut ja digitaalinen suvereniteetti 2026
Datakeskukset, tietoliikenneyhteydet ja pilvipalvelualustat ovat herättäneet suorastaan ilahduttavan paljon huomiota viime aikoina. Itämerellä tuntuu menevän kaapelia poikki tämän tästä (mm. marraskuussa 2024, jouluna 2024 ja vuodenvaihteessa 2025), serverien päällä lämmittelevät kissat voivat vaikuttaa kryptovaluutan louhintaan ja sähkösängyt jumiutua, koska AWS:n automaatio teki kahta asiaa päällekkäin. Palveluita voi lähteä saavuttamattomiin muistakin syistä: esimerkiksi välillä pääsy Microsoft-tilille voi katketa jos edustaa tiettyä laitosta. Eikä organisaation kannata edistää monimuotoisuutta, yhdenvertaisuutta ja osallisuutta missään omassa toiminnassaan, jos haluaa saada rapakon takaa tukia. Tämä surkuhupaisten ja absurdien anekdoottien lista kasvanee kuluvana vuonna.
Serveri ei siis ole enää vain serveri eikä datakeskus ei ole vain Suomeen lämpöä tuottava investointi. Pureudun tässä blogipostauksessa siihen, mitä konkreettisia toimia on mahdollista tehdä, jotta yllä mainittujen kaltaisilta palvelukatkoilta vältyttäisiin tai ainakin niistä toivuttaisiin hieman nopeammin.
Mitä vaihtoehtoja on ja miksi sen pitäisi kiinnostaa?
IT-palvelujen ylläpitoa voi siis ajatella monesta näkökulmasta. Turvallisuus, varautuminen ja omavaraisuus ovat olleet johtavia teemoja jo muutaman vuoden ajan muuallakin kuin paikkatietoalan seminaareissa. Suomen ja EU:n digitaalinen suvereniteetti kiinnostaa nyt useampia tahoja.
Monet organisaatiot ovat viemässä tai ovat jo vieneet palveluitaan pilvialustoille, ja usein valinta osuu kahdesta yhdysvaltalaistoimijasta toiseen, Amazonin AWS:ään ja Microsoftin Azureen. Päätös on varsin perusteltu: molemmat palvelut ovat de facto standardeja ja niillä on laaja tarjonta erilaisia lisätoimintoja itse palvelujen hostaamisen lisäksi. Tekijöitä ja ohjeita löytyy kumpaankin liuta ja “kaikki muutkin käyttää sitä”.
Jos organisaatio käyttää muitakin Microsoftin palveluita, Azure voi tuntua helpolta valinnalta. Vaikka Azurea tarjoava Microsoft ja AWS:ää tarjoava Azure ovatkin yhdysvaltalaisia firmoja, niin saatavilla on esimerkiksi Tukholman tai Keski-Euroopan konesali (“region”), jolloin palvelimet sijaitsevat kuitenkin maantieteellisesti melko lähellä. Riittääkö se? Riippuu miten asiaa tarkastelee: palvelun yhteys muodostuu kyllä EU-alueelle, mutta rahavirta suuntaa Atlantin taakse ja palveluiden todellinen omistajuus, ja sitä myöten myös niihin liittyvä päätäntävalta, pysyy siellä.
Mikäli Suomen ja EU:n suvereniteetti kiinnostaa, niin ratkaisu on suosia toimittajia, jotka ovat joko kotimaisia tai EU:n sisältä. Jos GDPR-asiat koskettavat, voi kysyä, miksi aineisto ja tieto lähtee yhdysvaltalaiselle palvelun toimittajalle tai ylipäänsä Suomen rajojen ulkopuolelle. Microsoft on myöntänyt, että se ei voi taata että data pysyy EU:ssa, vaan voi mennä myös Yhdysvaltain hallinnolle. Kyynisimmät ajattelevat tietenkin, että järjestelmästä riippumatta kaikki data päätyy lopulta Kiinaan (ks. mm. 2025 lausunto).
Palvelun tilaajan näkökulmasta yksi vaihtoehto on hajauttaa palveluiden ylläpito usealle toimijalle. Jos ei muuten, niin edes pitää varainstanssia eri toimittajalla. Jos tuotantoinstanssiin ei saa syystä tai toisesta yhteyttä, niin läheltä löytyy valmiiksi toinen instanssi, johon liikenne voidaan ohjata. Organisaation oman hyödyn ja omien auditointien vaatimusten täyttäminen on yksi tapa lähestyä palveluntarjoajien valintaa.
Välillä voi myös tuijottaa muutakin kuin omaa napaa ja todeta, etteivät vaihtoehtoiset järjestelmät ja palvelut koskaan lähde kunnolla lentoon, jos niitä ei aktiivisesti tueta ja niihin panosteta. Isot toimijat pysyvät isoina ja pienet pieninä, jos rahavirrat suuntaavat jatkossakin tiettyyn suuntaan. Viime kädessä asiakas voi tässäkin päättää, mihin rahansa vie ja mitä se käytännössä tarkoittaa niin poliittisesti kuin eettisestikin. Palveluita täytyy ylläpitää jossakin, ja tehtyjä ja tekemättömiä valintoja voi tässäkin yhteydessä perustella monin tavoin.
Mitä eroja ja ominaisuuksia pilvipalveluilla on?
Kysymys saatavilla olevista ominaisuuksista kääntyy pian siihen, mikä on palvelun tai palvelun ylläpitäjien kannalta olennaista. Esimerkiksi pilvipalvelujen tarjoajat myyvät erilaisia asioita: osa tyhjiä servereitä, osa laajaa valikoimaa erilaisia koneita, osa lisäpalveluita tekoälytyökaluista lambda-funktioihin.
Jos organisaatiolla on jo palvelu ylläpidossa, osa päätöksistä on jo tehty: palvelun monitorointi on saatettu hoitaa erikseen asennetulla ohjelmistolla tai pilvialustan omalla monitorointityökalulla, palvelu on ehkä pystytetty kontitettuna tai sen pystyttämiseen on käytetty skriptiä. Voi myös olla niin, että palvelu on suunniteltu käytettäväksi tietyllä alustalla ja hyödyntämään alustan työkaluja, jolloin ylläpito muualla käy todella haastavaksi. Päätökset valitusta alustasta voivat olla hyvinkin perusteltuja ja niiden vaikutukset tiedossa.
Varmasti yksi tärkeimmistä kysymyksistä alustaa tai palveluntarjoajaa valitessa on “mitä se maksaa?” ja “mitä minä siitä hyödyn?” Jälkimmäiseen on jo toivottavasti vastattu aiemmin tässä kirjoituksessa. Mitä hinnanmuodostukseen tulee, vastaus on perinteinen “it’s complicated”. Pilvialustojen käytön lopulliset kustannukset näkee vasta ensimmäisten laskujen tullessa, ja siihen voivat vaikuttaa alustalta valitut koneet, palvelun käyttömäärät ja palvelun tyyppi.
Palveluiden ylläpidossa on myös mahdollisuus toimittajaloukkuun (eng. vendor lock-in). Näin on varsinkin silloin kun palvelu on käsin pystytetty pilvialustalle ja se hyödyntää alustan spesifejä toiminnallisuuksia tai on jopa niistä riippuvainen. Oman palvelun alustariippuvuuden voi saada selville pohtimalla esimerkiksi sitä, saako vastaavan palvelun pystyyn toiselle alustalle ja kuinka nopeasti se tapahtuisi.
Yksi ratkaisu toimittajaloukun välttämiseen ja palvelun nopeaan uudelleenpystytykseen on käyttää ohjelmointikieliä, jotka käskyttävät alustaa pystyttämään määritysten mukaisen ympäristön. Tähän voidaan käyttää esimerkiksi Ansiblea, Terraformia tai Open Tofua. Näitä meilläkin on käytetty ylläpitoasiakkaiden palveluiden pystyttämiseen, koska saatavat hyödyt ovat niin hyvät.
Automatisoidun pystytyksen säätäminen vaatii työtä ja opiskelua, mutta niiden ansiosta tiukan paikan tullen palvelu voi olla taas pystyssä puolessakin tunnissa. Skriptien edut voivat näkyä myös arkityössä: yhdellä komennolla voidaan esimerkiksi ajaa aineistopäivitykset, muokata palvelinympäristöä tai pystyttää nopeasti testausinstanssi. Hyvin kirjoitettu ja dokumentoitu skripti automatisoi käsin näpyttelyä ja mahdollistaa asetusten toistettavuuden nopeasti.
Lopuksi
Ennen kaikkea viime vuosien tapahtumat ovat konkretisoineet sen, että internet sijaitsee fyysisesti jossain ja siihen liittyviä komponentteja voi mennä rikki. Maailmanpoliittinen tilanne puolestaan osoittaa, että lähes mikä tahansa hyödyke voi olla viime kädessä poliittisten toimijoiden vaikutuspiirissä.
Lopulta asiakas saa päättää, mitä tilaa ja miten työ toimitetaan. Jos organisaatio on linjannut Azuren pilvipalvelualustaksi, kunnioitamme tietenkin sitä. Jos kukaan ei kuitenkaan äänestä jaloillaan, kaikki jatkuu kuten tähänkin asti ja tietyt firmat pitävät monopolia, ilman että uudet toimijat pääsevät niitä kunnolla haastamaan.
Suomesta ja Euroopasta löytyy pilvipalvelualustoja tarjoavia tahoja, joihin siirtymistä mieluusti tuemme ja joiden suhteen autamme kartoittamaan vaihtoehtoja. Innokkaimmat voivat perehtyä niihin jo itse tästä. Kun alusta on päätetty, voidaan pohtia aiemmin mainittua palvelun automaattista pystytystä käsin klikkailun sijaan.
Kenenkään ei tarvitse olla heti paras tai nähdä kerralla koko prosessia. Ensimmäisen askeleen ottaminen on tärkein.
