Pilvipalveluiden edut alkavat olla useimmilla jo siinä määrin tiedossa, että kysymys on vain siitä miten ja milloin palvelut siirretään pilveen. Sana siirtymä antaa prosessista yksinkertaisen kuvan, mutta jokainen järjestelmä on ainutlaatuinen, joten siirtymä vaatii aina yksilöllisiä ratkaisuja.
Siirretään nykyinen toteutus pilveen, eikö se riitä?
Pilvisiirtymän toteutustavat riippuvat siitä, mitä muutoksella halutaan saavuttaa.
Yksinkertaisimmillaan olemassa oleva järjestelmä voidaan siirtää pilvipalvelimelle sellaisenaan. Tällä ratkaisulla voidaan saavuttaa kustannussäästöjä ja parantaa järjestelmän saavutettavuutta. Järjestelmä ei kuitenkaan muutu itsestään joustavammaksi tai mukaudu käytön mukaan, joten usemmiten siirtymältä halutaan enemmän.
Räätälöity pilvisiirtymä on prosessi, jossa palvelut siirretään pilvipalveluiksi tavalla joka on teknisten vaatimusten, aikataulun ja kustannusten kannalta paras ratkaisu kullekin palvelulle.
Seuraavaksi pitäisi valita oikea pilvipalvelun tarjoaja, vai kuinka?
Merkkiuskollisimmat ovat tässä vaiheessa jo valintansa tehneet. Muiden kannattaa tehdä ensin hyvä kartoitus omasta järjestelmästä, selvittää mitä pilvisiirtymällä halutaan saavuttaa ja näiden pohjalta tutustua olemassa oleviin vaihtoehtoihin, joten palataan tähän aiheeseen hieman myöhemmin.
Mitä halutaan saavuttaa?
Ensisijaisesti järjestelmän tulee toimia halutulla tavalla tilanteessa kuin tilanteessa, myös ruuhkaisimpina aikoina. Halutaan myös, että oma järjestelmä on hieman parempi ja monipuolisempi kuin kilpailijoiden järjestelmät.
Kustannusten pitäisi olla ennakoitavissa, muutoksia pitäisi pystyä tekemään helposti ja nopeasti, ja mukana saisi olla tekoälyä ja muita hienouksia. Lisäksi asioiden pitäisi tapahtua automaattisesti.
Sitten tarvitsee vain selvittää, miten olemassa olevasta järjestelmästä saadaan sellainen.
Mitä pitää tehdä ja paljonko se maksaa?
Muutostyö maksaa ja isot muutokset maksavat aika paljon. Tässä vaiheessa menneisyyden valinnat näyttelevät isoa roolia. Onko pidetty huolta siitä, että järjestelmäarkkitehtuuri seuraa hyviä tapoja, eli on mm. modulaarinen ja helposti ylläpidettävä? Panostettinko testiautomaatioon? Nämä investoinnit maksavat itsensä takaisin pilvisiirtymässä.
Modulaarisuus antaa mahdollisuuksia rakentaa järjestelmää pala palalta. Pilvipalvelun tarjoajilla on paljon valmiita palveluita yleisiin käyttötarkoituksiin. Kannattako nykypäivänä käyttää sähköpostipalvelua joka tehtiin itse kymmenen vuotta sitten ja on sittemmin jäänyt vaille huolenpitoa, vai käytetäänkö mieluummin valmista ratkaisua jota palveluntarjoaja ylläpitää jatkuvasti?
Skaalautuvuus on avainsana, joka useimmilla on perusteena pilveen siirtymiselle. Myös tässä vaiheessa moludaarisuus pääsee näyttämään hyödyllisyytensä. Monoliittinen toteutus on helppo monistaa tarpeen mukaan, mutta samalla monistuvat myös ne palvelut, jotka olisivat olleet toimivia kovassa kuormassa jo ilman skaalaustakin. Modulaarisesta toteutuksesta pullonkaulat voi irroittaa omiksi mikropalveluikseen, joita sitten skaalataan tarpeen mukaan. Ja taas säästettiin kustannuksissa ja parannettiin tehokkuutta.
Parhaimmillaan pilvipalveiluden edut pääsevät kuitenkin esiin, kun toteutukset kirjoitetaan puhtaalta pöydältä suoraan pilviympäristöön sopivaksi, eli ns. serverless-arkkitehtuuriin Function-as-a-Service (FaaS) -mallilla. Tässä ratkaisussa palvelut ovat käytössä aina tarpeen mukaan, eli toiminnallisuudet elävät sen aikaa kun niille on käyttöä ja sammuvat käytön jälkeen. Oikein toteutettuna järjestelmä skaalautuu kaikkiin kuviteltavissa oleviin tarpeisiin ja vähän yli, ja kustannuksia kertyy vain käytön mukaan.
Yksinkertaistettuna olemassa olevien toteutusten pilveistämiseen on viisi vaihtoehtoa:
Siirretään toteutus sellaisenaan paikalliselta palvelimelta pilvipalvelimelle
Laitetaan sovellus konttiin (esim. Docker) ja konfiguroidaan se (esim. Kubernetes) skaalautumaan automaattisesti kun käyttöaste nousee tietyn rajan yli.
Pilkotaan toteutus mikropalveluiksi, jotka konfigurodaan skaalautumaan itsenäisesti joko kontittamalla tai käyttämällä serverless-pilvipalvelua.
Toteutetaan olemassa olevat toiminnallisuudet uudestaan serverless-pilvipalveluun Function-as-a-Service -mallilla.
Korvataan olemassa oleva toteutus valmiilla palvelulla.
Listan vaihtoehdot ovat tietyllä tapaa käänteisessä paremmuusjärjestyksessä, koska mitä alemmaksi listalla mennään, sitä joustavammaksi palvelu saadaan kehitettyä. Toki pilvisiirtymän kustannukset kasvavat samassa järjestyksessä, pois lukien nro. 5, jonka hintalappu riippuu valmiin palvelun mahdollisista maksuista.
Näiden viiden vaihtoehdon lisäksi on vielä jokeritapaus, jossa todetaan että olemassa olevalle toiminnolle ei ole käyttöä, jolloin se voidaan poistaa pilvisiirtymässä.
Minkä palvelun valitsen? AWS? Azure? Google Cloud? Joku muu?
Oma suosikkini on yleensä se, jonka parissa olen viimeksi touhunnut. Toisilla aikaisemmin käytetyt teknologiat voivat ohjata vahvasti johonkin suuntaan ja osa tekee valintansa puhtaasti ideologisista syistä. Kaikilla isommilla pilvipalvelun tarjoajilla on jotakuinkin samat peruspalikat hieman erilaisilla painotuksilla, joten omat tarpeet ohjaavat oikeaan suuntaan.
Palveluntarjoajat kehittävät omia palveluitaan jatkuvasti, joten myös palvelun käyttäjien kannattaa seurata kehitystä. Tekoälyt ja muut hienoudet tulevat koko ajan paremmin myös pienempien yritysten hyödynnettäviksi. Kehitys menee lujaa eteenpäin, siinä on hyvä pysyä mukana.
Sami Kovalainen, Lead Solution Architect, Amabit Oy
