Viisi askelta pilvipalveluihin

Olen pyöritellyt parikymmentä vuotta erilaisia Microsoft- ja Unix-pohjaisia palvelimia ja ympäristöjä on-premisenä ja hosting-ympäristöissä. Milloin asiakkaille, milloin omaan käyttööni ja milloin tutuille. Viimeiset vuodet ovat menneet aika tiiviisti siirtymisissä – kokonaan, osittain tai ei alkuunkaan pilvipalveluihin.

Aluksi kyse oli kotimaisen hosting-kumppanin tarjonnan vertailu ja sopimuksen kilpailutus suurta amerikkalaista pilvipalveluntarjoajaa vastaan. Lopputulos oli usein sama: Virtuaalikoneet ovat jossain, ne saavat sähköä, internetiä, jäähdytystä ja huolenpitoa.

Nykyisin teknologia ja varsinkin asenteet puhtaita pilvipalveluita kohtaan ovat ilahduttavasti muuttuneet.

Pilvipalvelu voi tarjota aidon vaihtoehdon traditionaaliselle “kaikki meillä ja oma räkki on maailman paras paikka”-asenteelle. Arkkitehtuuria ja palveluiden sijoittelua kannattaa kuitenkin mielestäni aina tarkastella kriittisesti ja faktoihin pohjautuen. Usein pilvipalveluissakin on rajoitteita, kustannusrakenteita ja teknisiä yksityiskohtia, jotka voivat vaikuttaa ratkaisevasti lopullisiin valintoihin.

Kokosin tähän viisi tärkeintä askelta, joilla pilvipalveluita kannattaa mielestäni lähestyä.

1. Päätä pilvipalveluiden hyödyt

Olin kesällä kuusivuotiaan esikoiseni kanssa meren rannalla kävelemässä ja heittelemässä leipäkiviä (tuli muuten ennätys, 16 leipää). Katselin pilvistä taivasta ja kysyin pojalta, miltä suurin pilvistä näyttää. “No totaa”, hän aloitti pohdiskelevasti kuten niin usein aikaisemminkin, “ehkä avaruusalukselta”. Niin, miksipä ei. Itse näin samassa pilvimuodostelmassa jotain aivan muuta, ehkä ison kahvikupin.

Tätä juttua kirjoittaessani tajusin, että pilvipalvelutkin näyttävät katsojasta riippuen hieman erilaisilta katselukulmasta ja omasta tilanteesta riippuen vaikka palvelut ovatkin pääosin samat kaikille.

Päätä, mihin organisaatiosi tarvitsee pilvipalveluita ja mistä suurimmat kustannus- ja skaalautumishyödyt saadaan.

Ei ole täysin mutkatonta selvittää olemassaolevia kustannusrakenteita, nyky-ympäristöstä koituvaa välillistä työtä ja käytettyjä lisenssimalleja ja verrata näitä pilvipalveluiden tarjoomaan.

On täysin ok todeta analyysin jälkeen, että pilvipalvelut eivät meille sovellu – ehkäpä teille kyllä. Toisaalta on yhtälailla ok todeta, että pilven tarjoamat kustannussäästöt ja liiketoimintaa tukevat palvelut ovat erityisen sopivia juuri meille. On mahdoton tehdä yleistävä ‘blanket statement’, koska harva yritys on identtinen jonkin toisen yrityksen kanssa.

Erityisen hyvin pilvipalveluiden hyödyt tulevat esiin perinteisissä infrapalveluissa: sähköpostissa ja intraneteissä. Huomattavasti hankalampaa on sanoa, että pilvipalveluista tarjottava virtualisointikapasiteetti on automaattisesti parempaa, halvempaa ja tehokkaampaa kuin ehkä oma käytössä oleva alusta. It depends – ja organisaation tehtävänä on selvittää, mitkä ovat ratkaisevat tekijät.

2. Hoida oma piha kuntoon

Nautin suuresti lukiessani Helsingin Sanomien artikkelia amerikkalaisista nurmikoista. Siis, okei – yritän ymmärtää. Se on nurmikko. On ihan jees, että nurmikko on siistiksi leikattu. Mutta nurmikon värjäys? Siihen vedän rajan.

On tärkeää, että oma piha, koti, asiat ja elämä on ojennuksessa ja tasapainossa. Kolmannes töitä, kolmannes unta ja kolmannes vapaa-aikaa. Ei liian tiukasti säädellen mutta sopivalla eksymällä ja raja-arvoilla.

Vastaavasti yritysten ja organisaatioiden tulee hoitaa oma piha – on-premises – kuntoon ennen haikailua pilvipalveluihin. Muuten käy niin, että edessä on myrskyisää ja ukkospilveä, eikä poutapilveä.

Suosittelen hoitamaan seuraavat kokonaisuudet riittävällä tasolla kuntoon:

Active Directory- tai muu vastaava käyttäjätunnistuksesta ja identiteeteistä vastaava ratkaisu: Käyttäjien perustiedot (etu- ja sukunimi, käyttäjätunnuksen formaatti, esimiestieto, puhelinnumero, sähköpostiosoite, toimisto tai toimipaikka jne.) kuntoon. Data näihin saattaa tulla ulkoisesta HR-järjestelmästä, SAPista, IT:n naputtelemana tai mistä tahansa. Varmista, että käyttäjien tiedot on populoitu järkevällä tasolla. Näin pilvipalveluiden tekniset asiat kuten mahdollinen kertakirjautuminen ja käyttäjistä välitettävät lisätiedot muihin järjestelmiin ovat kerralla kunnossa.

Tarvittavat infratason investoinnit: Usein pilvipalvelut edellyttävät uusia palvelimia on-premiseen (tai pilvipalveluun) tunnistautumista ja muita lisäpalveluita varten. Huolehdi, että riittävä kapasiteetti näihin on olemassa ennen suurta rykäisyä kohti auvoisia pilvipalveluita.

Varsin usein, kun ollaan jo kädet kyynärpäitä myöten kurassa tekemässä transitiota, ei saatavilla olekaan enää vapaata keskusmuistia siinä kuuluisassa VMware-alustassa mutta ihan kohta (1-4 viikon päästä) Bangaloressa joku ruuvaa lisää muistia kiinni pannuihin.

Jep – hoida tämä kuntoon ajoissa ;-).

Nykyisen ympäristön dokumentaatio ja tahtotila: Kaikillahan dokumentaatiot ovat ajan tasalla, ja verkkokaavioiden “Date modified”-metatieto on hädin tuskin tunnin ikäinen.

Meillä ei kyllä ole, joten tässäkin voi tehdä ovelasti ja dokumentoida riittävästi mutta ei liikaa. Fläppitaulu, PowerPoint, Visio-kaavio tai kynä ja paperi. Kunhan kaikilla osapuolilla on selkeä näkemys mitä ja mistä, mihin ja miten. Eikä kaikkea tarvitse kerralla siirtää – myöhemminkin ehtii. Tästä saa muuten kätevästi johdettua myös kokonaisarkkitehtuurin pohjan.

3. Käyttäjät ensin

Joskus kuulin hirtehisen mutta osuvan “leikkaus onnistui mutta potilas kuoli”-lausahduksen. Samoin it-projekti voi onnistua mutta käyttäjät eivät pääse enää maanantaiaamuna sähköposteihin käsiksi – great success!

Huolehdi ensin käyttäjistä, järjestelmät taipuvat kyllä. Ja jos eivät taivu, vaihda järjestelmä. Mitä järkeä on pitää järjestelmää, joka on hankala käyttää? Maailma on täynnä huonoja järjestelmiä (katson sinuun, Lotus Notes) – ei niitä kannata valita, ellei yrityksen toimiala ole jostain syystä työntekijöiden kiusaaminen.

Pohdi järjestelmät joista käyttäjille on hyötyä. Toteuta ne, ja suunnittele toteutus vertaamalla on-premisenä toimivaa ratkaisua vastaavaan pilvipalveluun.

Esimerkkinä loistava Harvest-työkalu tuntikirjauksiin, matkalaskuihin (ja kuitteihin) ja projektien kevyeen kirjaamiseen.

Vuonna 2009, kun ensimmäisiä laskuja piti piirtää asiakkaille, rakentelimme mielestäni todella kätevän Exceliin pohjautuvan kirjausjärjestelmän, jota parsin lähes nerokkuutta lähentelevällä komentoriviohjelmalla (.NETillä tehty .exe, tietysti). Kahdella ihmisellä se oli liikuttavan tuskaista mutta samalla tehokasta.

Aikanaan, kun Onsightiin palkattiin ensimmäisiä työntekijöitä, tuli vastaan ihan asiallisia kysymyksiä “meidän hirveästä tuntikirjausjärjestelmästä”. Tällä oli ihan taloudellisiakin implikaatioita, kun unohdin laskuttaa ulkomailta yhden keikan ja rahoja piti odotella monta kuukautta sen jälkeen.

Harvest on halpa (as in, $49/5 käyttäjää/kk), toimiva (mobiiliappsit, selainkäyttö, responsiivinen sivusto) ja luotettava (ei vielä kertaakaan käyttöä häiritsevää käyttökatkoa yli viiden vuoden aikana). Tähän päivään asti kukaan ei ole minulle kyennyt esittelemään toimivampaa, halvempaa ja kokonaiskustannuksiltaan järkevämpää on-premises-ratkaisua, jolla tuntikirjaukset hoituvat yhtä jouhevasti.

Harvestin käyttökokemus on mukava jo ensi metreillä – firman logolla tehty “brändäys” hoituu suoraan palvelun valikoista.

Projektin lisääminen omalle tuntikortille tuntikirjausta varten on hävyttömän helppoa – samalla näkyy projektiin liittyvät tehtävät.

Ja sitten vain naputellaan tunteja kuvauksineen niin kuin ne olisivat menossa pois muodista:

Siirryttyämme Harvestiin en ole kuullut avautumista siitä, miksi tuntien kirjaus on hirveää. Ehkäpä tuntikirjaus on vähemmän sydänkohtauksia aiheuttavaa puhdetoimintaa näin.

4. Exit-suunnitelma kuntoon

Startup-yrityksillä on aina toisinaan jonkinlainen exit-strategia, jolla määritellään jonkin tilanteen tai ennaltamääritellyn hetken osalta tapahtuva strategia: sammutetaanko valot ja paetaan vuorille, vai jatketaanko nykymallilla?

Mieti mahdollinen pakenemis- tai vetäytymissuunnitelma pilvipalveluista.

Tämä on kai vähän avioehdon kaltainen sopimus: Tehdään paperit, kun asiat ovat kunnossa mutta siltä varalta, että ne eivät joskus tulevaisuudessa ole.

Pilvipalvelun käyttäjä ja palvelun tilaava organisaatio omistaa oman datansa. Varmista, että käytössä on riittävä tekninen tieto, sopivat työkalut ja selkeä toimintamalli siihen hetkeen, kun valittu pilvipalvelu ei täytä enää asetettuja kriteerejä.

En tietenkään tarkoita, että olisi järkevää siirtyä käyttämään pilvipalvelua A, ja viikon päästä migroida sisältöä pilvipalveluun B ja kuun lopulla vaihtaa taas kaikki takaisin on-premiseen. Sen sijaan suosittelen vakavasti miettimään – edes yleisellä tasolla – mitkä keinot esimerkiksi sähköpostitilien ja dokumenttienhallintaan tarkoitettujen tietojen siirtämiseen ovat saatavilla ja taloudellisesti järkeviä.

Kuulostaa triviaalilta: “kopsataan ne levyjaolle” ei ehkä tässä nyt lennä kovin vakavasti otettavana optiona, joten pieni pilotti tietojen siirtämisestä takaisin itselle ei mielestäni ole alkuunkaan hölmö ajatus.

Pilvipalvelut ovat kustannustehokkaita, kun ne omaan tarpeeseen sopivat, mutta ajat ja tilanteet muuttuvat. Siinä missä virtualisointikapasiteettia ostettiin aiemmin tolkuttomasti, voi tarve pienentyä esimerkiksi taloudellisen tilanteen takia ja silloin voi olla järkevää skaalata pilvipalveluinvestointeja pienemmäksi.

5. Hallittu siirtyminen

Ja lopuksi: Älä hötkyile. Ei ole mikään kiire. Ja jos on, teet jotain väärin. Palaa alkuun ja yritä uudelleen.

Toisinaan pilvipalveluihin on niin kiire, että transitio rytistellään it-henkisellä perjantai-illan pizzalla ja kolalla yli viikonlopun, ja maanantaiaamuna kaiken on aivan pakko toimia.

Tee siirtymä mieluummin harkiten, ajatuksella ja pikakelausta välttäen. Kauas ei pilvet karkaa, vaikka siirto kestäisikin kauemmin kuin 56 tuntia, jonka viikonloppu suo. Kustannussäästöt on syöty moneksi kuukaudeksi, kun sähköpostiliikenne ei reititykään oikein työviikon alkaessa, ja ongelmia selvitellään usean toimittajan voimin aurinkoa seuraten.

Transition pilveen – täysin tai osittain – voi tehdä hallitusti esimerkiksi usean viikon tai kalenterikuukauden aikana. Priorisoi palveluiden siirto ja varmista, että tekninen alusta toimii ennen yhdenkään tuotantopalvelimen siirtoa.

Ja lopuksi: Asiat ovat vaikeita siihen asti, kunnes ne oppii. Sama pätee pilvipalveluihinkin.