Mikä ihmeen serverless?

Serverless on vuoden 2018 hypesana. Muutaman vuoden takaisen Docker-huuman tapaan monet yritykset tulevat tekemään uusia ja siirtämään nykyisiä palveluitaan serverlessiksi markkinoiduille alustoille. Onkin syytä katsoa mistä asiassa on kyse.

Isompi trendi serverlessin takana on erilaisten liiketoimintojen muuttuminen dataintensiivisiksi. Paradigma IT-puolella tunnetaan nimellä Streaming Platform, joka pohjautuu erilaisten datavirtojen hallintaan. Dataa tulee jatkuvasti lisää, saapuvalla datalla sekä jo aiemmin talletetulla tehdään laskentaa ja sitä säilötään myöhemmin käytettäväksi. Data tallennetaan erilliseen tietovarastoon, ja koska sitä ei jatkuvasti muokata tai käsitellä, on käsittely muuttunut erilliseksi toimeksi.

Yksinkertaisimmillaan data otetaan tietovarastosta, sillä tehdään laskentaa ja tulokset lähetetään käyttäjälle tai talletetaan takaisin tietovarastoon. Samoin saapuva uusi data tai yksittäinen API-pyyntö voidaan haluta käsitellä kertaalleen ilman, että sitä varten on jatkuvasti odottamassa yksi tai useampi palvelin.

Streaming Platform -visualisaatio
Streaming Platform -näkemys Confluent-yrityksen blogista.

Serverlessissä onkin kyse ennen kaikkea ohjelmiston tilattomuudesta. Tilattomuus tarkoittaa, että ohjelmisto saattaa olla PHP-koodin tapaan ajossa vain suorituksensa ajan ja tieto sen tekosista on oltava tallessa jossain sen ulkopuolella, kuten vaikkapa tietokannassa. Hajautettujen järjestelmien yleistyessä on yhä tavallisempaa, että ohjelmistosta on ajossa useampia, jopa satoja, kopioita kerrallaan.

“Serverittömät” palvelut ovat viime vuosina ottaneet sellaisia hyppäyksiä, että termin merkityskin on mennyt matkalla uusiksi. Aikojen alussa eli vielä muutama vuosi takaperin serverless tarkoitti puhtaasti Backend as a Service -tyyppisiä ratkaisuja, joissa pilvitarjoajalta ostettiin tietokantoja tai vaikkapa koneoppimisinfrastruktuuria palveluna. Sittemmin serverless on siirtynyt tarkoittamaan enemmän Function as a Service -tyyppisiä palveluita, joissa yksittäinen pieni tai isompi osa koodia siirretään ajettavaksi palveluntarjoajan suoritusympäristössä. Koska koodi on ajossa vain suorituksen ajan, ei sillä ole erillistä tilaa ja kaikki tilaan liittyvä on haettava erikseen tietokannasta tai esim. AWS:n S3-bucketista. Samanlaiset tilattomat palvelut ovat viime vuosina yleistyneet Docker-konttien ja mikropalveluiden myötä, joten aiemmin luodut tilattomat softat toimivat näppärästi myös serverless-ympäristöissä. Näiltä osin yritys voi luopua myös palvelinylläpidosta, sillä tämä hoituu lähes poikkeuksetta serverless-palveluntarjoajan puolelta.

Kriittisiäkin äänenpainoja on kuultu. Yleisin, hiukan kyyninen näkemys on että kyseessä ei ole mitään uutta. Jo mainittu PHP-ohjelmakoodi on suorituksessa vain ajonaikaisesti ja jo ensimmäisistä webhotelleista löytyi Perlin suorittamiseen tarkoitettu cgi-bin-hakemisto. Serverlessin vahvuus tulee kuitenkin ennen kaikkea ympäristöstä, jossa kaikkea ei tarvitse tehdä enää funktiotasolla. Esimerkiksi AWS:ään pystyy helposti rakentamaan ympäristön, jossa mm. autentikaatio ja osin myös autorisointi on hoidettu ennen pyynnön saapumista serverless-ympäristössä olevalle funktiolle.

Yllä olevaan twiittiin viitaten serverless voi olla hyvä ratkaisu myös keittiön kanssa. Vaikka palveluntarjoajilla on halu esittää asian olevan hyödyllinen ainoastaan heidän ympäristössään, voi serverlessistä olla isojakin hyötyjä myös osana omaa palvelinympäristöä.

Tässä oli serverless-blogisarjan ensimmäinen osa. Seuraavassa osassa palaan erilaisiin tarjolla oleviin serverless-ratkaisuihin itse ylläpidetyn ympäristön vaihtoehtoja unohtamatta. Toinen osa ilmestyy parin viikon sisään, joten pysythän kanavalla!

DevOps tuo yrityksellesi strategista kilpailuetua – lue miten! 

DevOps on siitä upea termi, että harvoin löytää sanaa, jolla on eri merkitys käytännössä kaikille. Yhdelle se tarkoittaa tiettyä valikoimaa työkaluista, joilla toimintaa tehdään. Toiselle taas sitä, että koodille ajetaan välittömästi muutosten jälkeen testit, joiden onnistuttua uusi versio softasta otetaan automaattisesti käyttöön yhdessä tai useammassa ympäristössä. Nämä näkemykset eivät ole vääriä, mutta mielestämme DevOps voi kuvata laajemminkin organisaatioiden toimintaa ja tuoda strategista kilpailuetua, jonka avulla yritys voi toimia vikkelämmin ja huomioida asiakkaidensa tarpeita nopeammalla syklillä.

CALMS – DevOps viidellä kirjaimella

The DevOps Handbookin kirjoittajanakin toiminut Jez Humble loi CALMS-käsitteen kirjan muiden kirjoittajien aiemmin luoman CALMS-akronyymin pohjalta. CALMS muodostuu sanoista Culture, Automation, Lean, Measurement ja Sharing. Mallissa ei mainita ensimmäistäkään palvelua, ohjelmistoa tai työkalua, vaan nämä ovat toteutuskysymyksiä. Vaikka esimerkiksi ohjelmistokehityksen ja tuotantoonviennin automatisointi tapahtuu usein muutamalla yleisesti käytetyllä työkalulla ja järjestelmällä (Ansible, Jenkins, Docker, Kubernetes jne.) on tärkeää, ettei toimintaa suunniteltaessa takerruta liiaksi tiettyyn ratkaisuun.

“Kuka haluaa antaa devaajille rootit?”

Kulttuuri, CALMSin C eli culture, tarkoittaa DevOpsissa jaetun vastuun kulttuuria, jonka myötä perinteiset raja-aidat ohjelmistokehityksen ja järjestelmien pyörityksen väliltä kaadetaan. Itselleni tämä osa DevOps-käsitettä tuntui aikanaan erityisen vastenmieliseltä. Sysadminina olin usein tilanteessa, jossa devaajat rikkoivat muutoksilla tuotantojärjestelmiä ja omana työnäni oli ongelmien korjauksen lisäksi vastaavien tapausten ennaltaehkäisy, käytännössä käyttöoikeuksien rajaaminen. Stabiiliutta korostettiin siis merkittävästi yli muutosten.

Vastuurajojen kaatuminen on kuitenkin muuttanut pelikenttää merkittävästi. Kun aiemmin kiisteltiin, pitäisikö kehittäjillä olla pääsy tuotantoon, puhutaan nyt siitä miksi ylläpitäjänkään pitäisi kirjautua sinne. Automatisointi on kääntänyt asian päälaelleen, jolloin tuotannon testauksesta ja pystyssä pysymisestä on tullut prosessiasia, ei yksittäisten ihmisten vastuualue.

“Mä teen tän aina uuden version tullessa.”

Automatisoinnista, joka on CALMSin A eli automation, puhutaan DevOpsissa usein turhaan vain tuotantoautomaationa (Continuous Integration & Deployment), vaikka se kuuluu olennaisena kaikkeen tekemiseen. Organisaatioista löytyy usein käsin tehtäviä rutiinihommia, jotka ovat jääneet jonkun vastuulle. Yleinen perustelu on, että hommassa ei mene kuin pari minuuttia, mutta päivittäin tehtävänä tähän alkaa kulua melkoisesti aikaa. Kiireessä voi myös sattua virheitä, joista seuraa huomattavasti lisää työtä.

Hyvä alku manuaalisen työn poistamiselle on kirjoittaa asia skriptiksi, jolloin samat asiat tapahtuvat riippumatta kuka sen ajaa. Paremmaksi tilanne menee, kun skriptin ajaminen kytketään suoraan siihen toimintoon, joka sitä edellyttää. Näin asia tapahtuu aina oikea-aikaisesti ja sovitun määrän kertoja.

“En mä osaa sanoa, milloin tää on valmis.”

Lean eli CALMSin L tuo tiimin tekemää työtä näkyväksi niin tiimille kuin sen ulkopuolellekin. Työn palastelu järkeviksi kokonaisuuksiksi ja siitä vielä yksittäisiksi kehitystehtäviksi tekee suuremmankin ominaisuuden kehityksen paremmin nähtäväksi – ja tilanne aukeaa nopealla vilkaisulla myös tiimin ulkopuolisille.

Leaniin voi liittyä myös asioiden tekeminen näkyväksi esimerkiksi palvelun omalla kojelaudalla, josta löytyy yhdellä vilkaisulla sekä metriikat että ongelmatilanteet. ChatOps-käsitteellä tarkoitetaan palvelussa tapahtuvien asioiden näyttämistä ja hallintaa erilaisten integraatioiden avulla. Mikäli firma toimii muutenkin Slackissä tai Flowdockissa on luonnollista, että myös järjestelmät raportoivat tekemisistään sinne.

“Valvomme, että palvelu vastaa.”

Monitorointi, CALMSin M eli measurement, on usein palvelun saavutettavuuden tarkkailua. Kun sivuston latauksessa kestää useampi sekunti tai se ei lataudu ollenkaan, lähetetään asiasta sähköposti tai tekstiviesti. Infrapuolella valvontaan kuuluu usein myös palvelinten saavutettavuus ja kuormitus, mutta useimmiten valvonta tapahtuu noin minuutin välein ja muutaman minuutin alhaallaolon jälkeen aiheutuu hälytys. Valvonta on tällöin pakostakin reaktiivista, ja ennakointi jää usein tekemättä.

DevOps tuo monitoroinnin seuraksi mittaamisen (instrumentation), joista voi yhdistettynä puhua havaittavuutena (observability). Havaittavuus korostaa nimenomaan järjestelmien toiminnan ymmärtämistä ja sen hallintaa erilaisilla mittaristoilla. Esim. API-rajapinnan virhemäärien tarkkailu on tärkeää, mutta virheen taustalta on hyvä nähdä myös syy, mistä virheet aiheutuvat. Palvelu voi olla täysin kunnossa, vaikka APIn pyynnöistä 50 % tyssäisi virheeseen, mikäli kyse on häirintäyrityksestä. Häirintä on syytä havaita, mutta siihen on osattava reagoida eri tavoin kuin palvelun rikkinäisyyteen.

“Eihän me voida kaikille kertoa, miten nää tehdään!”

CALMSin viimeinen kirjain S eli sharing sisältää tiedon jakamisen kehityksen ja ylläpidon välillä. Vaikka työtehtävät ja vastuut sekoittuvatkin, voi tietyn tiimin pääasiallinen työ edelleen liittyä ylläpitoon. Tässä kontekstissa on äärimmäisen tärkeää, että eri asioita tekevien tiimien välillä on avoin ja toimiva keskusteluyhteys, tapahtui tämä sitten toimistolla tai jotain viestintä käyttäen. Yllättävän moni asia lakkaa hajoamasta, kun kehittäjä pääsee näkemään oman koodinsa toimintaa tuotannossa.

Jakamisen käsitettä voidaan haluttaessa laajentaa myös oman firman ulkopuolelle. Esimerkiksi Suomen OpenStack -operaattorit juttelevat kuukausittain OpenStack Finland -ryhmän myötä erilaisista ongelmista ympäristöissään. Salaisuuksien varjelun ja verisen kilpailun sijaan ratkaisuja jakamalla voidaan saavuttaa etua kaikille.

Haluaisitko kuulla lisää DevOpsista, CALMSista ja käytännön opeista? Puhuimme asiasta webinaarissa keskiviikkona 7.2., ja tämä blogikirjoitus summaa webinaarissa käymäämme keskustelua.

CALMS on mainio lähtökohta yritykselle, joka hakee DevOpsista parannusta ja ketteryyttä toimintaansa. Vaikka DevOpsista puhuttaessa kannattaakin sivuuttaa teknologia hetkeksi, ei tätä toki voida käytännön sovellutuksissa unohtaa. Jakamisen opit pätevät myös teknologiavalintoihin eli työkaluista ja järjestelmistä kannattaa keskustella ja kysellä. Mikäli et oikein tiedä mistä aloittaisit, kannattaa kysyä asiasta vaikka meiltä!
antti.myyra@codento.com tai petri.aukia@codento.com