Auton varustelistassa lukee ”digitaalinen ilmastoinnin säätö”. Yhdellä automerkillä tämä tarkoittaa sitä, että fyysisen ilmastointisäätöhanikan keskellä on peukalon kynnen kokoinen diginäyttö, jossa näkyy lämpötila. Toisella merkillä kojelaudassa ei näy yhtä ainutta fyysistä nappulaa vaan suuri diginäyttö, josta auton ilmastointia hallitaan näyttäen samalla sekä sisä- että ulkoilman lämpötilakäyrät. Tai itseasiassa olet voinut hoitaa homman jo ennen autoon istumista puhelimellasi.
Sama tieto varustelistassa, mutta radikaali ero todellisuudessa. Niin ajatusmallissa, käytännön toteutuksessa kuin tulevaisuuden hyödyntämismahdollisuuksissa. Tämä sama ajattelun, toteutuksen ja potentiaalin kolmio on läsnä myös pilvipalveluiden hyödyntämisessä. Yli 80% suomalaisista organisaatiosta on jo pilvessä jollain tasolla (The status and future of Finnish companies’ IT-infrastructures; Arrow/M-Brain 11/2019). Kuitenkin tavat hyödyntää pilvipalveluita vaihtelevat suuresti, ja samoin vaihtelee pilvipalveluista saatavat hyödyt.
Olen kuullut useammankin suomalaisen IT-päättäjän toteavan:
Kokeiltiin pilvialustaa, mutta huomattiin pian, että kyllä palveluiden pyörittäminen on omassa konesalissa edullisempaa.
Tämä on totta, ja siinä piileekin ongelman ydin. Eli se, että verrataan porkkanoita porkkanoihin. Ja moni todellakin vertaa, ymmärtämättä että julkisen pilven palveluiden radikaali hyöty piilee jossain ihan muualla. Parhaimmillaan pilvi on kuin se juuri tarjolle nostettu mehevä porkkanapiirakkapala, jonka voit ostaa kahvin kera juniorin jalkapalloturnauksen kioskista. Jos siis porkkana-vertausta halutaan jatkaa.
Mutta miten varmistaa, että oma pilvi ei ole porkkana vaan porkkanapiirakka? Miten saada radikaalisti enemmän hyötyä pilvestä?
Kaksi raaka-ainetta on tässä porkkanapiirakassa ratkaisevassa roolissa. Reaktiovalmius ja reaktioprosessi. Yksinkertaisia sanoja, mutta niiden takana piilee totaalinen ajattelumallin muutos.
Reaktiovalmius eli kyky vastata liiketoiminnan tarpeeseen
Jaan tämän kyvyn kahteen osioon: Tuotannon dynaamisuuteen ja innovaation tukemiseen.
Tuotannon dynaamisuudella tarkoitan kykyä skaalata tuotantopalveluita kysynnän mukaan. Eli pitämään palvelut pystyssä silloin, kun asiakkaat haluavat palvelua käyttää. Harmikseni huomasin, että vielä vuonna 2019 Black Fridayn aikana monen suomalaisen kauppiaan verkkopalvelut korahtelivat aamuseitsemästä iltayhteentoista kuin kuolonkouristuksissaan. Todennäköisesti vuoden ylivoimaisesti kovin myyntipäivä, ja kassakone ei ole sinut kaupallisuuden kanssa. Ei hyvä.
Julkiset pilvipalvelut tarjoaisivat 100% varmuudella sellaisen laskentatehon, että verkkokauppa ei olisi moksiskaan suomalaisten liikehdinnästä.
Tällaisen palvelun rakentaminen vaan vaatii radikaalin muutoksen ajattelumalliin. Pilven parhaita voimia ei valjasteta käyttöön sillä, että virtualisoidaan tai kontitetaan omassa konesalissa olevat palvelimet, ja nostetaan pilveen pyörimään sellaisenaan. Ei syntyisi kovin mainiota porkkanapiirakaa sillä, että pinotaan kasa porkkanoita vuokaan ja paistetaan uunissa.
Radikaalisti hyödyllisempi pilvipalvelu lähtee liikkeelle uudella tavalla tuotetuista raaka-aineista ja nerokkaasta valmistusohjeesta. Pitää siis suunnitella pilvipalvelu- ja automaatiolähtöisesti.
Pilvipalveluissa on lähtökohtaisesti kaksi tapaa tuottaa ratkaisuja ja niiden osia: serverless ja serverful. Serverless-palveluiden toiminta ja skaalaaminen on täysin pilvipalvelun tarjoajan vastuulla, ja se on todennäköisesti hoitanut hommansa hyvin. Eli serverless-palvelut skaalautuvat lähes rajattomasti globaalissa mittakaavassa. Ja sama kääntäen, eli jos serverless-palvelua ei käytetä, se ei myöskään kuluta resursseja eikä generoi kustannuksia. Tiettyjä rajoitteita serverless-palveluilla vielä tässä kehitysvaiheessa on, eli ihan kaikkiin käyttötapauksiin ne eivät sovellu.
Serverful-palvelut ovat kuin omia palvelimiasi pilvipalvelualustalla, eli valitset niihin käyttöjärjestelmän, prosessorit, muistit, levyt jne., ja maksat niistä jatkuvasti ja ennustettavasti. Serverful-palveluiden skaalaaminen tapahtuu klusteroimalla palveluita ja/tai osoittamalla niille lisää resursseja. Olet näistä asioista itse vastuussa, mutta näidenkin konfiguraatioiden ylläpitämiseen ja palveluiden skaalaamiseksi ja kopioimiseksi ympäristöjen välillä on mahdollista valjastaa automatiikkaa. Kubernetes onkin saavuttanut tällä kentällä de-facto-standardin aseman, ja Kubernetesia ollaan tuomassa vauhdilla myös usean perinteisen IT-tuotetalon palveluidenhallintaan, esimerkkeinä tästä VMWare ja IBM.
Pilvitransformaation lopputuloksena tulisi olla merkittävästi enemmän suorituskykyä ja kustannusten kohdentaminen sinne, missä niistä on eniten hyötyä.
Tämän vuoksi tuleekin harkita tarkkaan, mitä komponentteja ratkaisusta kannattaa toteuttaa Serverless-palveluilla ja missä yhteyksissä perinteisempi Serverful-malli on järkevämpi. Ratkaisuvaihtoehtoja tulee tarkastella sekä käyttökelpoisuuden, suorituskyvyn että kustannusten näkökulmasta.
Innovaation tukemisella tarkoitan sitä, kuinka nopeasti pystyt valitsemillasi työkaluilla kehittämään liiketoiminnan tarvitsemia palveluita. Toimialasta ja kilpailutilanteesta riippuen vuosi jäljessä kilpailijaa saattaa jo merkittävästi ohjata asiakkaita naapurin pilttuuseen. Eli nopeudella on merkitystä.
Pilvipalvelut eivät ole veljiä sen suhteen, mitä kyvykkyyksiä ne tarjoavat omien palveluiden koostamiseen nopeasti. Yhtäläisyyksiä pilvillä on äkkiseltään todella paljon ja perusjutut, kuten serverful-palvelut ja serverless-puolelta omien funktioiden ajo koodina, tapahtumavirrat, tietokannat ja vastaavat perusrakennuspalikat löytyvät MS Azuresta, Google Cloudista ja AWS:stä kutakuinkin samanlaisina. Merkittävimmät eroavaisuudet ovat seuraavat (ei varmastikaan tyhjentävä listaus):
- Microsoft Azure kannattaa valita silloin, jos on tarve ajaa suurta määrää Windows-palvelimia Serverful-palveluna - Microsoftilla on luonnollisesti edullisimmat hinnat tähän tarpeeseen. Microsoft kannattanee valita myös niissä tapauksissa, kun tarve on laajentaa Office- ja O365-tuotteiden toimintaa pilvipalveluilla.
- Google Cloud tarjoaa monessa yhteydessä edullisimmat hinnat. Tämän lisäksi Google Cloudilla on ilmiömäiset kyvyt laajojen datamassojen käsittelyyn ja analysointiin, kuvan- ja videontunnistukseen, tekstin tulkitsemiseen sekä kaikkeen muuhun, mitä voit kuvitella löytyvän kyvykkyytenä Googlen omissa julkisissa palveluissa. Google Cloudilla on myös konesali Suomessa, eli voit halutessasi pitää käyttämäsi palvelut ja datan Suomen kamaralla.
- Amazonin AWS on pilvipalveluista pisimmälle kehittynyt kokonaisuutena. Siinä missä Googlen pilvessä on käytettävissä n. 50 eri valmista palvelua, löytyy AWS:stä jo n. 200 palvelua. Suuri määrä tuo toki mukanaan sen, että samaan tarkoitukseen, esim. serverless-tietokannaksi, on valittavissa useita erilaisia ratkaisuja. AWS on myöskin maailmalla selvästi eniten käytetty pilvialusta ja siihen löytyy paljon integroituvia ratkaisuja, valmiita koodi- ja konffausesimerkkejä, koulutustarjontaa jne. AWS:n palvelut ovat ”eniten koeteltuja” ja siten tuotantovalmiimpia esimerkiksi verkkokonfiguraatioiden ja -integraatioiden osalta verrattuna kilpailijoihinsa.
Jotta pystyy palvelemaan liiketoimintaa nopeasti ja pitämään kiinni kilpailukyvystä, ei välttämättä ole fiksu ratkaisu valita vain yhtä pilveä ja sulkea silmänsä muiden tarjoamilta ratkaisuilta. Fiksu valitsee yhden pilven ns. kotipesäksi, mutta rakentaa kyvykkyyden hyödyntää kunkin pilven parhaita puolia ratkaisujen rakentamisessa.
Markkinoille on jatkuvasti tulossa parempia työkaluja multi-cloud-strategiaa tukemaan, eli hallinnoimaan palveluita usean pilven yli. Samoin markkinoilta löytyy jatkuvasti enemmän ns. hybridi-ratkaisuja, joiden avulla voit helposti valita, haluatko ajaa työkuormia pilvessä vai omassa konesalissa. Esimerkiksi VM Ware julkaisi viime vuonna oman kyvykkyytensä siirtää virtualisoituja palveluja usean konesalin ja pilven välillä, ja AWS julkaisi joulukuussa 2019 re:Invent-konferenssissaan AWS Outposts -ratkaisun, jonka avulla voit ajaa AWS-pilven työkuormia omassa konesalissasi.
Reaktioprosessi eli kyky saada asioita aikaiseksi tehokkaasti
Maailmanluokan vehkeilläkään ei tee mitään, jos organisaatio ei saa aikaiseksi. Uuden äärellä on pakko olla nöyrä, ja pohtia asioita, jotka joko hidastavat tai nopeuttavat kehitystä. Asiat, jotka ennen toivat nopeutta ja suoritusvarmuutta, eivät välttämättä sitä enää tuo. Nopeuden käsite on muuttunut.
Samalla kun nopeuden käsite on muuttunut, myös hinnan käsite on muuttunut. IT-palveluiden tilausprosessi oli aikanaan perusteltua, koska uusien palvelinten tilaus saattoi olla kymmenien tai satojen tuhansien arvoinen investointi. Uudessa maailmassa palvelimet maksavat joitakin senttejä tai euroja päivältä, ja niitä voi ottaa käyttöön tai luopua käytöstä heti kun siltä tuntuu, välittömin kustannusvaikutuksin.
Pilviajattelussa mahdollisten riskien ja potentiaalisten hyötyjen välinen sytytyslanka on niin lyhyt, että on usein nopeampi ja edullisempi kokeilla, kumpaan suuntaan sytytyslanka lähtee palamaan, kuin että käyttäisi aikaansa asian teorisointiin.
Nopeuden ja hinnan käsitteen muuttuminen johtaa suoraan siihen, että myös kommunikaation käsite täytyy muuttaa. Toimintaympäristöä pitää muuttaa radikaalisti, jotta onnistut ulosmittaamaan pilvialustojen hyödyt. Pitää pystyä rakentamaan sellainen ympäristö, jossa byrokratia ei jarruta tai estä suorittamista.
Reaktioprosessin ensimmäinen näkökulma on siis organisoitumisen muutos. Näitä muutettavia asioita ovat mm.:
- Sopimukset siitä, mitä tehdään ja millä rahalla. Pyri saamaan selkeät reunat käytettävissä olevalle rahamäärälle koko vuodeksi ja selkeät liiketoiminnalliset päämäärät työlle. Olisi hyvä, jos sinulla on 4-8 liiketoiminnan KPI:ta sovittuna, joita kohti voit vapaasti valita polun.
- Sopimukset kehitysresurssien käytöstä. Keskity siihen, että sinulla on tarvittavat kehitysresurssit käytettävissäsi. Älä keskity sopimuksissa siihen, mitä tuotoksia heidän tulisi saada aikaiseksi milläkin aikataululla/kustannuksilla.
- Muodosta selkeät kytkennät muuhun organisaatioon, eli keskeisesti liiketoimintaan ja IT-infraan. Ota molemmista organisaatioista edustajat kiinteästi osaksi kehitystiimiäsi, hengittämään joka päivä samaa ilmaa kehitystiimin kanssa. Arvokasta aikaa ei kannata hassata uuvuttavaan sähköpostipingikseen, vaan liiketoiminnan pitää pystyä speksaamaan vaatimuksia päivä- ja viikkotasolla sitä mukaa kuin palvelua iteroidaan eteenpäin. Samoin kehitystiimissä oleva IT-infran jäsen henkilökohtaisesti valvoo ja varmistaa, että tarvittavat verkkokonfiguraatiotilaukset, integraatiotyöt on-premisen ja pilven välillä jne. etenevät oikealla vauhdilla ja prioriteetilla.
Tämä muutos tarkoittaa ikävä kyllä sitä, että jos homma menee pieleen, et voi syyttää ketään ulkopuolista. Olet itse vastuussa onnistumisesta. Veikkaan että tämä lisää sekä sinun että tiimisi omistautumista ja sitä kautta myös onnistumisprosenttia.
Reaktioprosessin toinen muutettava asia on tehokkaan ohjelmistotyön menetelmät. Organisoitumisen muutos tarkoittaa käytännössä muutosta tilaajaorgnisaatiosta tekijäorganisaatioksi. Tämä on radikaali muutos, josta monellakaan organisaatiolla ei ole aiempaa kokemusta.
Tekijäorganisaatio tarvitsee työkalut kehitystyöhön, versionhallintaan, dokumentaation hallintaan, vaatimusten- ja backlogin hallintaan. Jos halutaan rakentaa kyvykkyys viedä uusia ominaisuuksia tuotantoon useita kertoja kuukaudessa, kenties jopa viikoittain tai päivittäin, tarvitaan myös tähän tehoa ja automaatiota. Tarvitaan hyvät testausmenetelmät ja järjestelmällistä testausautomaatiota. Tarvitaan automatiikkaa julkaistavien softapakettien kääntämiseksi ja pakettiversioiden hallitsemiseksi. Tarvitaan automatiikkaa pakettien asentamiseen palvelimille ja tarvitaan todennäköisesti myös rajapintojen versiointia ja hallintaa.
Jos halutaan rakentaa kyvykkyys julkaista uusia ominaisuuksia tiheällä tahdilla, koko kehitystyö pitää aloittaa tämän testaus- ja julkaisuputken rakentamisesta. Vasta sitten, kun automatiikka on käynnissä, kannattaa kirjoittaa ensimmäiset rivit koodia ja varmistaa, että deployment-prosessi toimii. Toisin päin lähestyttäessä menee todennäköisesti pitkään, ennen kuin julkaisuvauhti voidaan nostaa edes 1krt/vk tasolle. Jos koskaan.
Ja nämä kaikki tarvitsevat ihmisiä, jotka ylläpitävät ja kehittävät näitä prosesseja. Ja vaaditaan kurinalaisuutta. Koko tiimin tulee ymmärtää näiden menetelmien kriittisyys onnistumiselle, ja pitää aukottomasti huoli siitä, että näitä käytäntöjä noudatetaan koko kehitysprosessin matkalla.
Yhteenveto
Pilvipalvelut tarjoavat merkittävästi enemmän niille, jotka ovat valmiita muuttumaan. Yksinkertaistettuna kyse on siitä, että unohdetaan organisaatiorakenteen mukainen järjestäytyminen ja aletaan järjestäytymään työn ympärille. Riippumatta tehtävänkuvasta, organisaatioyksiköstä tai y-tunnuksesta.
Reaktiovalmius ja reaktioprosessi. NordHero auttaa yritystäsi löytämään ne ja saamaan radikaalisti enemmän hyötyä pilvestä.