Täydellisen pilvistrategian metsästys

Meidän yrityksellä on pilvistrategia! Hyvä homma mutta mitä se käytännössä tarkoittaa. Täydellisen pilvistrategian luominen voi olla melkoinen haaste, koska erilaisia tapoja ottaa pilvipalveluita käyttöön on monia ja yrityksen nykyiset toimintatavat esimerkiksi tietoturvan tai ympäristön operoinnin osalta eivät välttämättä suoraan sovellu pilvimaailmaan.

Aloitetaan palvelutyypeistä. Minkä tyyppisiä pilvipalveluita ollaan ottamassa käyttöön:

IaaS (Infrastructure as a Service)

Onko tarpeita siirtää virtuaalikoneita pilveen? Tämä on yleensä nopea tapa siirtää sovelluksia pilveen, koska mitään muutoksia sovelluksiin ei tarvitse tehdä. Sovellukset siirretään käyttöjärjestelmineen pilveen. Kuinkas näitä virtuaalikoneita ja niiden tarvitsemia palveluita sitten operoidaan pilvessä. Varmuuskopiointi, tietoturvapäivitysten asentaminen, virustorjunta, käytettävyys. Optimaalisin tilanne olisi se, että nykyiset ratkaisut tukevat hybridipilveä. Esimerkiksi nykyinen virustorjunta- tai varmistuskopiointisovellus tukee sekä paikallisia että pilvessä olevia virtuaalikoneita. Vaihtoehto tälle on ostaa virtuaalikoneiden tarvitsemia tukipalveluita pilvestä, jolloin taas joudutaan erillisiin hallintasiiloihin.

Miten taas hoidetaan palomuuraus? Pilvessä ei varsinaisesti ole palomuuria vaan pääsylistojen tyyppisiä komponentteja. Vaihtoehtona on tietysti ottaa kolmannen osapuolen palomuuri käyttöön pilvessä. Paikallisissa konesaleissa on jo totuttu seuraava sukupolven palomuurien ominaisuuksiin ja jotenkin tuntuisi oudolta palata pääsylistoilla tehtävään tietoturvaan kun mennään pilveen.

Pilveen voidaan luoda helposti tällainen virtuaalinen datakeskus, mutta sen ylläpitämiseen pitää panostaa siinä missä fyysiseenkin datakeskukseen.

PaaS (Platform as a Service)

Voitaisiinko virtuaalikoneiden ja operoinnin määrää vähentää hyödyntämällä valmiita ylläpidettyjä palveluita. Esimerkiksi voitaisiin siirtyä ylläpidettyihin tietokantoihin, jolloin tietokantaa vain käytetään ja ylläpitovastuu jätetään pilvipalvelun tarjoajalle. Websovellukset voitaisiin siirtää valmiiksi ylläpidetyille palveluille, jolloin omalle vastuulle jää enää sovellus. Websovelluksen tarvitsema alusta ja käyttöjärjestelmä hoidettaisiin pilvipalveluntarjoajan toimesta.

Olemassa olevat sovellukset eivät tietysti suoraan taivu tällaisiin palveluihin, joten tämä strategia vie enemmän aikaa ja rahaa. Sovellusarkkitehtuurin uudistaminen ei välttämättä tuo haluttuja kustannussäästöjä kovin nopealla aikataululla.

Pilven konfiguraation hallintaan pitäisi myös kehittää jokin prosessi. Oli konfiguraatio sitten IaaS- tai PaaS-pohjaista. Pilvikonfiguraation automatisointi mahdollistaa erilaisten testiskenaarioiden luonnin, helpottaa uusien sovellusversioiden julkaisua sekä mahdollistaa tietoturvamallin vakiinnuttamisen. Pahimmassa tapauksessa koko pilven konfiguraatio voidaan palauttaa automaation avulla. Pilveen rakennettavan konfiguraation laajuuden ja muutostiheyden takia perinteisellä dokumentointimallilla ei pilvikonfiguraation ylläpidossa ole mitään mahdollisuuksia. Pilvipalvelut tarjoavat erilaisia työkaluja konfiguraation automatisointiin, mutta usein näitäkin on tehokkaampi komentaa komentoriviltä tai jollain kolmannen osapuolen automaatiotyökalulla.

SaaS (Software as a Service)

Ylläpidettyjen sovelluksien ostaminen tarjoaa parhaan mahdollisuuden hyödyntää pilvisovelluksia ilman minkäänlaista ylläpidollista vastuuta. Sovellukselle saadaan tietty SLA ja olettamus että palveluntarjoaja hoitaa taustalla esimerkiksi tietoturvaan ja käytettävyyteen liittyvät asiat. Pitää tietysti huolella tutustua tehtyyn sopimukseen sekä dokumentaatioon. Ja tarkastaa että SaaS-toimijan prosessit ovat linjassa oman yrityksen vaatimustason kanssa.

Hyvin usein pilvistrategia koostuu useammasta erityyppisestä pilvipalvelusta. Tietyt sovellukset vaativat IaaS-palvelua, joistain sovelluksista voidaan tehdä pilvinatiiveja PaaS-palvelulla ja jotkin voidaan ostaa valmiina SaaS-palveluna. Jokaisen palvelutyypin kanssa pitää kuitenkin aina miettiä myös ylläpidolliset prosessit kuntoon. Ja jokaisen valinnan yhteydessä pitäisi aina ottaa huomioon kuinka helposti malli on toistettavissa jossain muussa pilvipalvelussa. Jos ja kun pitää alkaa miettiä EXIT strategiaa on ehkä liian myöhäistä tutkia kuinka syvän kuopan on itselleen kaivanut tietyn pilvipalvelutarjoajan kanssa.

Mitä jos pilvistrategia luodaan heti kättelyssä hybridimalliseksi. Eli otetaan alusta asti huomioon että tulevaisuutta ei rakenneta ainoastaan yhden pilvipalvelutarjoajan varaan. Hybridimallissa pitää taas miettiä miten eri pilvipalvelut voidaan tarjota käyttäjille keskitetysti. Erilaisia ”Cloud Management Platform”-tuotteita on runsaasti saatavilla, joilla voidaan tarjota keskitetty portaali loppukäyttäjille. Näiden ominaisuudet vaihtelevat suuresti ja semmoista tuotetta ei ole vielä olemassa jonka avulla voidaan keskittää kaikki pilvipalveluiden tarjoamat palvelut. Hybridimallissa ylläpitoprosessin luominen voi olla vielä haastavampaa, koska ylläpidollisten ratkaisuiden pitäisi tukea useampaa julkista pilvipalvelua sekä myös mahdollisesti paikallista datakeskusta.

Pitääkö Muhammedin mennä vuoren luo vai voiko vuori tulla Muhammedin luokse? Eli jos tuodaankin julkipilvi omaan datakeskukseen. Erilaiset ”pilvi-stack”-ratkaisut mahdollistavat julkipilven ajamisen omassa datakeskuksessa. Tietysti tällaisessa ratkaisussa saadaan melko rajoitettu versio julkisesta pilvipalvelusta. Hyötynä on esimerkiksi se, että omaa dataa ei tarvitse viedä omasta datakeskuksesta pois. Kustannussäästöjä tässä ei varmaan kauheasti saavuteta, koska itse joutuu maksamaan esimerkiksi omassa datakeskuksessa pyörivän julkipilven sähkölaskun.

On myös sellainenkin vaihtoehto, että omassa datakeskuksessa oleva virtualisointi stack voidaan ostaa myös pilvestä ja integroida ne yhdeksi hybridcloud-toteutukseksi. Tässä toteutuksessa suurinta osaa ylläpidollisista tuotteista ja prosessista voidaan hyödyntää myös julkipilvessä koska pilvessä oleva stack on identtinen oman ympäristön kanssa. Tässä voidaan hyödyntää myös jos investoitua osaamista, koska henkilöstöä ei tarvitse kouluttaa uusiin pilvipalvelualustoihin.

Voihan se olla että yrityksemme ei tarvitse mitään ylläolevista, mutta tuntuu että tuntuu että kaikkien huulilla on tekoäly jonka avulla voidaan esimerkiksi ulkoistaa triviaalitehtäviä koneälyn hoidettavaksi. Tai voidaan hyödyntää vuosien aikana kertynyttä dataa ja sen avulla tehostaa omaa liiketoimintaa tai jopa luoda täysin uutta liiketoimintaa.

Kaikkien näiden mahdollisuuksien ja vaihtoehtojen keskellä on varmasti vaikea luoda täydellistä pilvistrategiaa. Mutta jonkinlainen runko varmasti pitäisi olla millä lähteä pilvimatkaansa luomaan ja täydentää strategiaa matkan varrella. Usein matkalle otetaan mukaan jokin kumppani jonka avulla pilveen päästää nopeasti, mutta täysin pilvineutraalia kumppania ei taida vielä löytyä.

Minulta kerran kysyttiin, että kuka olisi se ihminen yrityksen organisaatiossa joka vastaisi kaikista pilveen liittyvistä asioista. Sellaista positiota ei taida olla ennen kuin sellainen luodaan. Paras ratkaisu olisi varmaan luoda kokonainen tiimi miettimään pilvistrategiaa ja toimintatapoja. Usein asiakas palavereissa olen huomannut että päitä lyödään yhteen näissä pilviasioissa. Osapuolina ovat yleensä henkilöitä joiden vastuualueina ovat tietoturva, ylläpito ja sovelluskehitys. Yhteisien pelisääntöjen löytäminen tuntuu olevan vaikeaa jokaisessa organisaatiossa. Näiden osa-alueiden edustajista saisi aikaan varmaan hyvän tiimin ”Cloud Center of Excellence” joka olisi omiaan ohjaamaan yritystä pilvipolulla ja luomaan yhteistä strategiaa.