Kun mietit organisaatiosi IT-järjestelmien tulevaisuutta, mietit luultavasti myös pilvipalvelujen hyödyntämistä. Huomioon otettavia yksityiskohtia riittää: jos sovelluksen arkkitehtuuri ei päivity samalla kun teet siirtymää, pilvialustalta toivotut kustannushyödyt voivat jäädä saavuttamatta.
Pilvipalveluihin siirtyminen ja ohjelmiston modernisointi kulkevat usein käsi kädessä. Niiden välille ei silti kannata vetää yhtäläisyysmerkkejä. Voit uudistaa sovelluksen arkkitehtuurin, käyttöliittymän ja taustateknologiat, ja 1) siirtyä omista konesaleista julkipilveen, 2) jatkaa omien palvelinten kanssa tai 3) tarttua muihin mahdollisuuksiin.
Seuraavaksi kuljetan sinut läpi kuvitteellisen casen, johon me Cinian neuvonantopalveluissa voisimme hyvin törmätä. Lataa myös kätevä muistilista pilvisiirtymää pohtivalle. Sen nelikentän avulla voit hahmottaa juuri oman organisaatiosi tilannetta.
1. Kiikkerä sovellus kaapissa
Lähtötilanteessa sovellus sijaitsee fyysisesti omilla palvelimilla. Järjestelmä on selvästi vanhentunut, ja se tuottaa harmaita hiuksia kaikille. Työntekijät ja asiakkaat turhautuvat. Tietoturva on vaakalaudalla.
- Sovelluksen rakenteet kaipaavat kipeästi uudistamista. Ohjelmistokehitys saattaa olla harvojen osaajien käsissä. Käytännöt eivät enää ole kovin ajanmukaisia.
- Tietojen säilytyksestä pitää tehdä päätöksiä. Vain vaatekaapin kokoinen serveri on altis läikkyville kahvikupeille, palovaaroille ja murtovarkaille. Kapasiteetti on koetuksella ja rauta vanhenee. Järeämmässä, omassa konesalissa tietoturva olisi paremmalla tolalla, mutta kulut nousevat korkeiksi.
- Ulkoapäin tulee lisää painetta muutokseen. Tietosuojalainsäädäntö sanelee reunaehtoja, konsernitasolta annetaan ohjeita käytäntöjen yhtenäistämiseen. Samaan aikaan kalvaa epämääräinen tunne siitä, että kaikki tekevät nyt siirtymää AWS:n tai Azuren kaltaisiin julkipilvipalveluihin.
Lue myös: Tekninen due diligence on IT-järjestelmän riskejä paljastava kuntotarkastus
2. Sopisiko SaaS?
Seuraavaksi IT-tiimin kannattaa istua yhteiseen pöytään liiketoimintajohdon kanssa ja jutella siitä, onko nykyinen järjestelmä toiminnan ytimessä. Onko mielekästä, että käytämme asiantuntijoidemme aikaa sen kehittämiseen? Olisiko markkinoilla tarjolla valmiita vaihtoehtoja, jotka vakuuttavat jatkuvuudellaan?
Yksi hyvä vaihtoehto on koko paketin ulkoistaminen. SaaS-ohjelmistot (Software as a Service) ovat suosittuja ratkaisuja etenkin tukitoimintojen, kuten CRM:n ja taloushallinnon tarpeisiin. Ideana on maksaa kiinteää kuukausihintaa ohjelmiston käytöstä. Ylläpitoon ja kehittämiseen ei tarvitse itse osallistua. Työaikaa vapautuu ydintehtäviin.
Aina SaaS-markkinoilta ei löydy omiin tarpeisiin osuvaa palvelua, tai sitten oma ohjelmisto todella on toiminnan ytimessä. Se voi olla tuotekehityksen strateginen kulmakivi tai yrityksen sisäiseen käyttöön tehty räätäliratkaisu, joka tuo uniikkia kilpailuetua markkinoilla. Silloin paukut kannattaa laittaa jatkossakin sen kehittämiseen.
3. Aika selvittää pilvipalvelujen hyödyt ja riskit
Nyt on siis todettu, että palvelinkaapista on päästävä eroon, mutta sovelluksen ylläpitoa halutaan jatkaa omin voimin. Julkipilvipalvelut kiinnostavat, sillä niiden ideana on yhdistää toimintavarmuus kustannusten optimointiin:
- Julkipilvi saadaan skaalautumaan automaattisesti kävijäpiikkeihin. Kapasiteettia ei tarvitse ostaa pahan päivän varalle, vaan asiakas maksaa aidosti siitä, mitä käyttää.
- Virtuaalipalvelinten lisäksi käytettävissä on Platform-as-a-Service-palveluita (PaaS), esimerkiksi valmiiksi rakennettuja ja hallinnoituja tietokantoja.
- Tietojen säilytys on saatettu hajauttaa useaan konesaliin ympäri maailman. Yhden salin kaatuminen ei aiheuta käyttökatkoja.
- Pohdittavaa tulee eteen, jos pitää varmistua siitä, että tiedot pysyvät varmasti EU:n sisällä. Jos sovelluksen datan on pysyttävä Suomen rajojen sisällä, varmistaminen käy erityisen haastavaksi.
Tässä kuvitteellisessa casessa paras lopputulos syntyy eri mallien yhdistelmästä. Soveltuvat osat kokonaisuudesta viedään julkipilveen, osaa varten taas hankitaan kapasiteettia tai tilaa omalle palvelimelle. Private cloud -ratkaisu on eräänlainen kompromissi kahden ääripään välillä:
- Se tarjoaa tietyssä sijainnissa palvelinsalin, joka on omia, vanhoja servereitä tietoturvallisempi.
- Kapasiteetin nosto vaatii tilanteen jatkuvaa seuraamista ja vähintään puhelinsoiton.
- Kustannukset ovat tyypillisesti julkipilveä korkeammat, ja tietokantojen kanssa on tehtävä enemmän manuaalista työtä.
Lue myös: Suunnitteilla uusi IoT-ratkaisu? Varaudu kasvuun, vältä sudenkuopat
4. Ei vain sovellusarkkitehtuurin, vaan koko ajattelutavan muutos
Tämä kannattaa muistaa: Edulliselta näyttävän julkipilven hyödyt voivat jäädä laihoiksi, jos kopioit sinne vanhan sovellusarkkitehtuurin suoraan omilta palvelimiltasi. Siksi pilvisiirtymässä tarvitaan koko ajattelutavan muutosta.
Tässä esimerkkitapauksessa sovellusta ei esimerkiksi kannata enää kehittää suurimman hetkellisen käyttäjämäärän tarpeisiin, vaan testipalvelut ja automaattinen skaalaaminen auttavat varautumaan piikkeihin.
Valmiit PaaS-palvelut kannattaa valjastaa käyttöön, jos mahdollista. Se edellyttää omalta sovellukselta niihin yhteensopivaa rakennetta. Kannattaa kuitenkin pitää mielessä, että juuri PaaS-palveluihin liittyy toimittajalukon riski. Silloin koko liiketoiminta voi olla riippuvainen yhden julkipilvialustan palvelujen jatkuvuudesta ja hinnoittelumuutoksista.
Toimittajalukon syntymistä voit ehkäistä modernisoimalla sovelluksesi siten, että se on teknisesti siirrettävissä tietyn palveluntarjoajan julkipilviympäristöstä toiseen. Samasta syystä jo silloin, kun suunnittelet IT-järjestelmien uudistamista, neuvoja kannattaa kysyä kumppanilta, joka ei ole sidoksissa tiettyyn teknologiaan tai pilvialustaan.
Parhaita vaihtoehtoja on yhtä monta kuin organisaatioitakin
Mikään ei estä rakentamasta tuoreita käyttöliittymiä ja modernia arkkitehtuuria, vaikka sovellus sijaitsee jatkossakin omilla on-premise -palvelimilla. Tai ehkä haluat siirtyä pilveen nyt, mutta varaudut tarvittaessa palaamaan omiin palvelinympäristöihin?
Joskus on järkevää jatkaa käyttökelpoisen palvelininfrastruktuurin käyttöä vielä muutaman vuoden ajan, mutta aloittaa rakenteiden modernisointi saman tien. Silloin pilvisiirtymä käy vaivatta, kun on sen aika.
IT-järjestelmäkokonaisuudet ovat vuosi vuodelta monimutkaisempia, eikä yksi sapluuna sovi joka tilanteeseen. Siksi kannattaa aina aloittaa oman tilanteen ja markkinoiden kartoittamisella.
