Lue lisää: |
Matti Grönroos
Tietysti on niin, että termin "pilvi" määritelmä on vähintään väljä ja hypen huipulla oltaessa pilvipalveluita olivat osapuilleen kaikki, jotka vähänkin tuoksuivat tietoliikenteelle.
Pilvikauppiaat ovat onnistuneet siinä, jota moni on yrittänyt: Pyörittävät tukkukauppaa vähittäiskaupan hinnoin.
Aivan.
Eritoten tilanteissa, joissa joudutaan miettimään investointia uuteen konesaliin tai vanhan kulahtaneen salin täydellistä uusimista, koko kapasiteetin työntäminen palvelutoimittajan vastuulle pilveen on peruslähtökohdaltaan oiva ajatus. Se sitten, onko kyseessä hyvä business case vai ei, ja kenen kannalta, ei kuitenkaan ole aivan yksinkertainen laskelma. Hemmetin pieni yksikköhinta kertaa hemmetin suuri määrä käytettyjä yksiköitä voi tuottaa hemmetin monen euron laskun.
Yksinkertaisimmillaan itse matematiikkahan on helppo:
Hinnoittelumielessä IaaS on konseptina lähellä sitä, mitä sukupolvi–pari sitten tapahtui IBM-keskuskonemaailmassa: Palvelukeskus myi keskusyksikkösekunteja, I/O-pyyntöjä, levypintaa urittain (19069 tavua per ura 3350-levyllä, jokin muu määrä jollain toisella levyllä), magneettinauha-asemaminuutteja, rivikirjoittimen rivejä, luettuja ja kirjoitettuja reikäkortteja jne. Valtion tietokonekeskuksen keskuskonepalveluiden hinnastossa oli neljä sivua vuonna 1982. Ei taida neljä sivua riittää Azuren hinnastoksi vuonna 2021. Yhteistä höyrykonemaailmalle ja sekuntihinnoitellulle pilvelle on se, että kummassakin asiakkaan pitää osata optimoida käyttötapansa hinnoitteluperiaatteiden mukaisiksi, jotta seuraavassa laskussa ei piile pikku yllätyksiä.
Jossain vaiheessa ennen laajaa palvelinten virtualisointia esitettiin arvioita, että 80–90 prosenttia tyypillisen konesalin asennetusta kapasiteetista on ilman kuormaa (mutta ei ilman sähkönkulutusta). Virtualisoinnin muuttuminen valtavirraksi on muuttanut tilannetta, mutta sovelluskanta saattaa olla hyvinkin ongelmallinen pilvihinnoittelun kannalta. Mallissa, jossa sovelluksen WWW-palvelin on päällä ympärivuorokautisesti odottamassa muutamaa transaktiota vuorokaudessa, tekee hinnaksi per transaktio jotain, josta talousjohtaja ei ehkä varauksetta pidä.
Käytännössä ns. pilvisiirtymä ei ehkä olekaan aivan pikku juttu, vaan iso projekti, jossa uusitaan merkittävä osa sovelluskantaa ja jossa joudutaan ajattelemaan back-end melko uusiksi. Lisäksi vastaan saattavat tulla tietosuojaan liittyvät rajoitukset, jotka tekevät siirtymän vaikeaksi. Todennäköistä onkin, että pientä omaa konesalia joudutaan ylläpitämään, jos ei muuta niin tietoliikennesolmun tarvitseman infrastrukruurin takia.
PaaS-mallissa – Platform as a Service – on kiehtovia etuja, koska se muun muassa vapauttaa suuresta osasta hankalaksi koettua lisenssihallintoa. Lisäksi suhteellisen pienellä rahalla pääsee kiinni ohjelmistoihin, joiden lisenssit itse hankittuina olisivat monelle organisaatiolle mahdottomuus. PaaS-mallin hinnoittelu on vielä monimutkaisempi kuin IaaS:n, eli siihen on hyvä kyetä panostamaan. PaaSista pitää vielä huomata se, että siinä sitoudutaan pilvitoimittajan varsin tiukkaan ohjelmaversiointiin. Rakasta kärsi ja unhoita ‑malli, jossa versionvaihdot kerran tehtynä voidaan unohtaa vuosiksi, ei toimi. Tämä saattaa tulla vastaan pulmana organisaatiolle, joka valmistaa ohjelmistoja muille myytäväksi. Omasta tuotteesta pitää tuottaa jatkuvasti uutta versioita, vaikka ohjelmiston elinkaari olisi jo jäähdyttelyvaiheessa.