Palvelut pilvessä, so what? Osa 2/2

Viime blogikirjoituksessani avasin hieman mysteerihattaraa pilvipalveluiden ympärillä. Lupasin pureutua tarkemmin pilven yhteydessä käytettäviin lyhenteisiin ja termeihin sekä pilven erilaisiin käyttömahdollisuuksiin. Jatketaan siitä mihin jäätiin.

Pilven useat käyttömahdollisuudet

Tarkkasilmäisimmät ovat varmaan jo huomanneet, etten viime postauksessani antanut yhtäkään konkreettista käyttötapausesimerkkiä pilven suhteen. En aio antaakaan, etten vahingossa heijasta sellaista kuvaa, että pilvi olisi jotain tiettyä käyttötarkoitusta varten. Kyseessä on pohjimmiltaan virtualisoitu palvelin internetissä – internetpalvelin, jonka päälle voi vahva innovaattori rakentaa ihan mitä vain. Yritän selittää vielä muutamia tapoja hyödyntää pilveä, joille on vakioitunut omat terminsä:

Saas – Software as a service

Perinteisesti ohjelmisto myydään käyttäjälle CD-rompulla tai annetaan maksun yhteydessä linkki, josta käyttäjä voi ladata ostamansa ohjelman ja asentaa sen koneellensa. Tässä on ainakin pari perustavanlaatuista ongelmaa:

  • Päivitykset. Aina kun ohjelmaan tulee versiopäivitys, vaaditaan käyttäjältä toimenpide sen suorittamiseksi. Myös itse ilmoittaminen uudesta versiopäivityksestä vaatii resursseja. Päivitys ei myöskään tapahdu koskaan heti. Tämä on tietenkin suuri ongelma, jos päivityksen tarkoitus on paikata vakava tietoturvaongelma.
  • Levitys. Mikä estää käyttäjää tietoisesti tai tiedostamatta jakelemasta asennuspakettiaan? Toki näissä on usein jonkinlainen identiteetin varmentaminen ja käyttöä edeltävä kirjautuminen.

Entä jos kuvitellaan sovellus, joka pyörii yksinomaan pilvessä. Kuka tahansa voi periaatteessa yhtyä siihen, koska internetillä nyt sattuu olemaan avoin luonne. Koska kyseessä on ihan normaali palvelin, voidaan siinä samassa pilvessä myös pyörittää käyttäjähallintaa.

Tässä kohtaa menemme palveluajatteluun, Saassiin. Sovellusta myydään vaikkapa aikaperustaisesti tai ihan elinikäisenä lisenssinä, jolloin käyttäjä yhdistää sovellukseen, kirjautuu ja käyttää ohjelmaa ilman, että mitään sovelluksen pyörittämiseen tarvittavaa koodia imuroitui käyttäjän omalle tietokoneelle. Ainoa asia mitä käyttäjä itse pitää tallessa, on lisenssitiedot. Lisenssitiedot voivat olla yksi vaivainen sähköposti tai käyttäjänimi ja salasana kombinaatio.

  • Päivitykset. Ohjelmistoa myyvä yritys päivittää ohjelman pilvessä. Bäng, kaikki käyttäjät käyttävät nyt uusinta versiota.
  • Levitys. Linkki. That’s it. Jonkinlainen työpöytäpikakuvake voidaan myös tarjota käyttäjän elämän helpottamiseksi.

Ohjelman käyttö tapahtuu siis kirjaimellisesti internetin yli.

Paas – Platform as service

Paas on lähinnä kehittäjiä varten. Usein, kun lähdetään tekemään esimerkiksi tietokoneohjelmaa tyhjästä, tarvitaan kaiken maailman apukirjastoja, testiohjelmistoja ja tekstieditoreja ennen kuin omaa koodia saadaan edes ajettua. Puhumattakaan järjestelmäriippuvuuksista ja .net -versiosta, joita pitää ylläpitää ja vaihdella sovelluksen tarpeiden mukaisesti.

Paas tarjoaa valmiin ympäristön tai pikemminkin ympäristöjä, joihin on asennettuna kaikki tietyntyyppisen kehitystyön vaatimat palikat, ei mitään muuta. Päästään suoraan esimerkiksi kirjoittamaan koodia ilman, että tarvitsee miettiä onko ympäristö ja apuohjelmat asennettuina ja valmiina.

Iaas – Infrastructure as a service

Iaas tarjoaa asiakkaalle kysyntäperusteista it-infrastruktuuria eli tarvittavia ydinresursseja tarvittavaan aikaan. Yleensä pilvipalvelun pystyttämiseksi on kolme vaihtoehtoa:

  1. Ostetaan iso varastohalli, jossa on reilusti oman nykyisen ja tulevan kapasiteettisi tarpeiden yli palvelimia, joiden tehtävänä on ylläpitää näitä virtualisoituja pilvipalvelimia.
  2. Käytetään apuna jonkinlaista datakeskusta, jonka palomuurit on säädetty sallimaan vain omasta intranetistäsi tulevia yhteyksiä.
  3. Vuokrataan tasan tarpeiden mukaan pilvipalvelimesi Iaas-tarjoajilta. Suurimpina mainittakoon Microsoft Azure, Google Cloud Platform ja Amazon Cloud.

Samalla on varmasti hyvä selittää, että ensimmäinen skenaario kulkee nimellä private cloud, toinen trusted cloud ja kolmas public cloud. Näiden pääero on siis se, kenen vastuulla pilveäsi pyörittävät palvelimet ja niiden ylläpito ovat. Mikään näistä ei tietenkään suoraan ole toistaan huonompi vaihtoehto, vaan näiden välillä on valittava käyttötarkoituksen ja saatavilla olevien resurssien ehdoilla. Alla oleva kuva selkeyttää kokonaisuutta hieman enemmän:

 

Pilvipalveluiden-vastuut-kuva-2

Kuva: Pilvipalvelun tarjoajan ja käyttäjän vastuut

Näiden lisäksi on olemassa arkkitehtuuri, joka tottelee nimeä hybrid cloud. Tämä paljastunee jo nimessä, tällöin yritys hyödyntää näitä menetelmiä ristiin. Esimerkiksi saatetaan omistaa pienehkö datacentteri, jossa pyöritetään pientä palvelua nimenomaan yrityksen sisäisten toimintojen tueksi, mutta ostetaan public cloudia siivu, jossa palvellaan esimerkiksi asiakkaita ja joka on jonkinlaisessa yhteydessä tähän omaan sisäiseen pilveen.

Tässä oli näkemykseni pilven perusteista, eli mitä mielestäni kaikkien IT-yritysmaailmassa mukana olleiden tulisi ainakin tietää. Toivottavasti lukija sai jotain uutta irti tai varmennusta vanhoihin olettamuksiinsa.

Loppupeleissä perusideahan ei ole kovin hankala, mutta aihio itsessään perustuu dynaamisuuteen ja termistö tuppaa laajenemaan sitä mukaan, kun uusista käyttötarkoituksista tulee standardeja.

Ensimmäisen osan aiheesta pääset lukemaan tästä.


Kirjoittaja: Ernesto Koskinen

Sovelluskehittäjä. EmCeläinen 2014 elokuusta lähtien. Ohjelmistotekniikan lisäksi harrastelukuaineina fysiikka ja avaruus. Voi myös tiukan paikan tullen tarttua kitaraan ja bassoon.