Palveliton (serverless) arkkitehtuuri mahdollistaa todellisen muutoksen työpanoksen kohdentamiseen digitaalisten palveluiden rakentamisessa. Palvelittomassa mallissa keskitytään liiketoiminnan lisäarvoa tuottavien osien rakentamiseen, ei alla olevan infrastruktuurin rakentamiseen tai ylläpitoon.
Palvelittoman arkkitehtuurin perusidea
Perusajatuksena palvelittomien palveluiden käyttämisessä on vastuun siirto ympäristöstä ja siihen liittyvistä asioista palveluntarjoajalle. Palveluita käyttävän organisaation vastuulle jää ainoastaan varsinainen liiketoimintalogiikan rakentaminen näiden palveluiden päälle.
“Palveliton” arkkitehtuuri ei siis tarkoita, etteikö oikeasti “jossakin” palvelinsalissa olisi palvelimia, vaan että nämä palvelimet eivät ole sinun organisaatiosi vastuulla. Näiden palvelinten raudasta, tietoturvasta, ympäristöistä ja verkotuksesta on vastuussa palveluiden tarjoaja, esimerkiksi Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure tai vaikkapa Alibaba Cloud.
Tässä artikkelissa keskitymme pääasiassa näihin edellä mainittuihin julkisiin pilvipalveluihin. Palvelittomalla periaatteella on myös mahdollista ajaa kuormia myös muun tyyppisissä ympäristöissä. Esimerkiksi omassa hallinnassa olevassa Kubernetes-klusterissa voi ajaa kuormia palvelittomalla periaatteella Kubeless-kehystä käyttämällä.
Lyhyessä ajassa suureen suosioon
Palvelittomien toimintamallien historia on kohtalaisen lyhyt ja termistä alettiin puhua toden teolla vuoden 2016 aikana. Tosin AWS julkaisi palvelittoman koodin ajamiseen tarkoitetun Lambda-kehyksen yleiseen käyttöön jo vuonna 2015. Suomessa palvelittomien arkkitehtuurien käyttö on kasvanut kohtalaisen verkkaisesti, mutta selkeästi kiihtymään päin. DataDogin tekemästä selvityksestä on nähtävillä, että maailmalla n. puolet AWS:ää käyttävistä organisaatioista hyödyntää Lambdoja, eli kyse on koetellusta teknologiasta.
Terminä palvelittoman tietojenkäsittelyn yhteydessä käytetään termiä FaaS, functions as a service erottamaan esimerkiksi IaaS, Infrastructure as a service -mallista, jossa palveluiden käyttäjän vastuulla on myös palvelinten ylläpito oman sovelluslogiikan lisäksi. Palveliton arkkitehtuuri ei tosin suoraan ole aina tekemisissä omien ajettavien funktioiden tai koodipalasten kanssa, vaan myös tallennustilaa, analytiikkaa, viestinvälitystä, koneoppimista, jne. on saatavissa palvelitonta mallia hyödyntäen.
Palvelittomien ratkaisujen arkkitehtuuri
Palvelittomiin ympäristöihin tehdyt ratkaisut ajetaan pilvipalvelutarjoajan määrittämällä ja haluamalla tavalla. Tämä luonnollisesti antaa sekä mahdollisuuksia että asettaa joitain rajoituksia siihen, miten ratkaisut on rakennettava. Palvelujen alla olevaan infrastruktuuriin ei pääosin ole pääsyä palveluiden käyttäjillä, vaan se kaikki on abstraktoitu pois näkyvistä. Toisaalta taas juuri tästä abstraktoinnista johtuen kaikille yhteinen kapasiteetti on mahdollista jakaa käyttäjien ja organisaatioiden kesken todella tehokkaasti.
Useimmiten palvelittomat ratkaisut ovat tapahtumapohjaisia, eli liiketoiminnan vaatimat toiminnot päätyvät suoritukseen jonkin ulkoisen herätteen seurauksena. Suorituksen ulkopuolisen ajan kyseiset oman organisaation palvelittomat komponentit nukkuvat horrosta ja pilvipalveluntarjoajan resurssit tekevät töitä jonkun toisen asiakkaan kuormien suorittamisessa. Tapahtumapohjainen suoritus myös yleensä mahdollistaa hyvin tehokkaan suorituksen, kun esimerkiksi sovelluskoodia ajetaan vain yhden tapahtuman käsittelyn ajan. Tällainen suoritusaika on usein alle sekunnin luokkaa ja esimerkiksi DataDogin samaisessa selvityksessä puolet ajettavista koodifunktioista ajettiin tässä ajassa. Viidesosa jopa alle 100 millisekunnissa. Useimmiten tästä kaikesta on seurauksena selkeä kustannushyöty kaikille palvelua käyttäville organisaatioille, kun resursseja ei tarvitse varata ainoastaan oman organisaation käyttöön.
Tapahtumapohjaisuuden ohella palvelittomien arkkitehtuurien palvelut ovat usein tilattomia, eli funktion käynnistyessä eli ole tallennettua tilaa mihin viimeksi jäätiin. Oman liiketoimintalogiikan lisäksi käytetään usein myös muita palvelittomia ratkaisuja esimerkiksi tiedon tallentamiseen, käyttäjien autentikaatioon, pyyntöreititykseen ja monitorointiin liittyen. Tarvittaessa palvelittomat komponentit pelaavat hyvin yhteen myös perinteisempien palvelumallien kanssa. Esimerkiksi osa palvelusta voi pyöriä konteissa perinteisen palvelinkapasiteetin päällä.
Miljoonia kutsuja muutamalla eurolla
Palvelittoman ratkaisun suurin hyöty on, että palveluiden käyttäjien ei tarvitse maksaa käyttämättömästä ajasta, vaan kapasiteetti on käytettävissä aina kun sille on tarvetta. Useimmiten pilvipalveluntarjoavat veloittavat vain kutsujen määrän ja yhden kutsun aikana käytettyjen resurssien mukaisesti.
Esimerkiksi miljoona kutsua funktioille maksaa palveluntarjoajasta riippuen alle euron, ja tämän lisäksi pitää maksaa funktioiden ajoajan ja muistivaatimusten mukainen hinta. Käytännön tasolla jos AWS Lambdalle esimerkiksi varataan 256Mt muistia ja sitä ajetaan n. sekunti per kutsukerta ja funktiota kutsutaan 100 miljoonaa kertaa kuukauden aikana, tulee kustannuksiksi hieman alle kolmesataa euroa.
Toisin sanoen jokainen suomalainen voisi kutsua funktiota noin parikymmentä kertaa kuukaudessa ja kustannuksia tulisi kuitenkin aika maltillisesti. Toki tässä ei huomioida mahdollisia tiedonsiirto-, tallennus-, turvallisuuskustannuksia tai vastaavia. Siltikin laskelma näyttää aika selvästi minkälaisia etuja palvelittomalla ratkaisulla voi olla verrattuna vaikka siihen, että kapasiteetti varattaisiin perinteisimmin suoraan omaan käyttöön varatuilta palvelimilta. Samaten tässä esimerkissä ei ole merkitystä sillä tulevatko kutsut yhtenä päivänä vai tasaisesti kuukauden aikana.
Toinen todella suuri vaikutus on sillä, että palvelittomissa ajoympäristössä ei tarvitse varata työaikaa itse palvelinten ja infrastruktuurin ylläpitoon. Pilvipalveluiden tarjoaja on vastuussa siitä, että palvelimia on riittävä määrä palvelemaan kaikkia asiakkaita ja että ne on konfiguroitu oikein huomioiden tietoturvapäivitykset, käyttöjärjestelmän liittyvät päivitykset, verkkokomponentit, tms. Parhaimmillaan organisaatiossa ei tarvitse olla lainkaan palvelinraudan ja siihen liittyvien näkökohtien erityisasiantuntija, vaan osaaminen ja ammattitaito voi keskittyä enemmän itse liiketoimintalogiikkaan ja sen oikeellisuuden varmentamiseen. Samaten vikasietoisuuden varmistaminen, vikatilanteiden hallinta ja skaalautuvuus ovat kaikki palveluntarjoajan vastuulla infrastruktuurin osalta. Miljoona kutsua yhtenä päivänä ja nolla toisena ei ole mikään ongelma palvelittomassa ratkaisussa.
Monesti palvelittoman ratkaisun toteuttaminen pakottaa miettimään toteutusta tapahtumapohjaisuuden ja pienempien osakokonaisuuksien kannalta. Tällöin rakennetaan kokonaisuutta, joka pilkkoutuu pienempiin yksittäisiin osiin ison monoliittisen kokonaisuuden sijaan. Osien välissä toimii puolestaan yleensä jokin tapahtumapohjaisuutta tukeva viestinvälityskanava tai jono, joka huolehtii tiedon siirtämisestä eri rakennuspalikoiden välillä.
Ei vielä kaikkiin käyttötarkoituksiin
Luonnollisesti palvelittomilla ratkaisuilla on myös omat haasteensa operoinnin ja toteutuksen suhteen. Useimmissa ratkaisuissa olet jollain tavalla naimisissa valitun pilvialustan kanssa, eikä sovelluskoodin tai kokonaisratkaisun siirtäminen pilvestä toiseen ole erityisen helppoa. Pilvialustojen tarjoamat palvelut ja mallit ovat myös alati liikkeessä ja kehittyvät todella nopeasti, joten ajan hermolla on pysyttävä sovelluskehitysratkaisujen osalta.
Palveliton arkkitehtuuri vaatii myös miettimään uudelleen totuttuja ratkaisuja ja teknologioita myös ajoympäristöjen vaatimusten takia. Palvelittomien funktioiden ajaminen on lähtökohtaisesti tilatonta, joten tilan ylläpito vaatii hieman uudenlaista ajattelua, mikäli tausta on perinteisessä client-server -maailmassa.
Maksimaaliset yksittäisiin kutsuihin liittyvät ajoajat ovat usein rajoitettuja palvelittomissa ratkaisuissa. Näin ollen palveliton malli pääasiallisesti suosii rakenteita, joissa pieniä asioita ajetaan paljon yhtä aikaa sen sijaan, että ajettaisiin jotain massiivista yhtä prosessointilogiikkaa. Käytännön tasolla esimerkiksi voi olla parempi prosessoida laaja datasetti monella yhtäaikaisella funktiolla, kuin yrittää prosessoida kaikki data yhdellä funktiolla.
Erityinen hankaluus palvelittomassa maailmassa on ns. cold start -ongelma, jossa kyseinen funktio tai koodi ei ole ollut ajossa vähään aikaan tai se on täytynyt siirtää palvelimelta toiselle palveluntarjoajan toimesta. Tällöin ensimmäiseen pitkän ajan jälkeen tapahtuvaan kutsuun voi liittyä merkittävä viite, joka ei ole kaikissa palveluissa hyväksyttävää. Tähänkin ongelmaan on onneksi tullut ratkaisuja eri pilvipalveluntarjoajilta, joissa esimerkiksi pientä lisäkustannusta vastaan palveluntarjoaja huolehtii siitä, että tietty kapasiteetti pysyy aina käyttövalmiiksi lämmitettynä.
Lisäksi on hyvä tunnistaa, että palvelittomissa funktioissa on usein merkitystä sillä, kuinka nopeasti koodi saadaan ajoon, eikä välttämättä niinkään sillä, kuinka tehokkaasti koodi ajetaan toistuvasti. Tästä syystä esimerkiksi Java Virtual Machine (JVM) -ympäristöt ja kielet kuten Java tai Scala ovat aiemmin hieman kärsineet haasteista nopean käynnistyksen suhteen. Tosin tähänkin ongelmaan on tullut huomattavia parannuksia ja ratkaisuja hiljattain.
Hallitsemattomasta palvelittomien funktioiden ja palveluiden käytöstä voi myös muodostua sekava verkko, jonka toiminnan selvittäminen jälkikäteen voi olla todella hankalaa. Tässä kuitenkin auttaa hyvät arkkitehtuuriperiaatteet, infrastruktruurin luominen koodin avulla sekä palvelittomia arkkitehtuureja tukevat sovelluskehykset.