IT-infran uudistajan opas: vaihtoehdot ja vertailu

Kun on tullut aika uudistaa IT-infraa, saattaa valinta eri vaihtoehtojen välillä tuntua vaikealta. Yhtä, jokaiselle yritykselle sopivaa vastausta ihanteellisesta IT-infrasta ei ole, sillä siihen vaikuttavat yrityksesi liiketoiminnan tarpeet ja toisaalta IT:n tehokkuusvaatimukset.

Tämä kirjoitus auttaa ymmärtämään mahdollisuuksia, joilla yrityksen IT-palvelut voidaan tuottaa sekä antaa näkökulmia valintojen tekemiseen. Kirjoitus jakautuu kolmeen pääkohtaan:

1. Valitse hankintamalli palvelun mukaan: SaaS, PaaS, IaaS, co-location vai on-premise?
2. Mitä tarkoittavat julkipilvi, private cloud ja hybridipilvi?
3. Yrityksen IT-infran rakentaminen: 7 pohdittavaa asiaa
 

Valitse hankintamalli palvelun mukaan

Yrityksen palvelut voidaan karkeasti jakaa kolmeen kategoriaan:

- Perus IT-infraan liittyvät palvelut kuten työasemien ja internetin hallinta, ADt, SCCMt
- Liiketoimintaa tukevat palvelut kuten HR- ja palkanlaskentajärjestelmät, CRM
- Liiketoiminnan harjoittamiseen liittyvät palvelut kuten verkkokauppa, verkkosivut ja tilausjärjestelmät.

Millaisia palveluita yritykselläsi on ja miten kukin palvelu on fiksuinta tuottaa? Onko markkinoilla sopiva SaaS-palvelu vai tarvitaanko yrityksellesi kustomoitu ratkaisu? Nämä valinnat määräävät sen, paljonko tarvitaan omia tai ostettuja resursseja IT-infran rakentamiseen ja ylläpitoon ja mitä investointeja päätyy yrityksen taseeseen.

Seuraavassa on esitelty hankintamallit alkaen siitä vaihtoehdosta, joka vaatii yritykseltä eniten omia IT-resursseja ja toisaalta mahdollistaa eniten kustomointia:
 

On-premises

Yrityksen omissa tiloissa sijaitseva konesali. Esimerkki: fyysiset palvelimet, levyjärjestelmät tai hyperconvergenssiratkaisut.

Co-location

Kumppani tarjoaa yrityksen omalle infralle (laitteille) sijoituspaikan ja sähkön. Ylläpito jää yritykselle. Esimerkki: Helsingin Pitäjänmäessä sijaitseva Helsinki Data Center.

IaaS

IT-infraa palveluna. Voi sijaita pilvipalvelussa tai kumppanin konesalissa. Esimerkki: INdatacenter.

PaaS

Alustapalvelu ohjelmistojen kehittämiseen, testaamiseen ja julkaisuun. Tällaisia tarjoaa esimerkiksi Microsoft Azure.

SaaS

Sovellus, jonka toimittaja tarjoaa käytettäväksi internet-yhteyden välityksellä. Esimerkki: Microsoft Office 365.

Lue tarkemmin IaaS, PaaS, SaaS ja on-premises -ratkaisujen eroista täältä.
 

Tunne erilaiset pilvipalvelut: julkinen, yksityinen ja hybridipilvi

Pilvipalveluista puhutaan usein yhtenä ryhmänä, vaikka termi sisältää sekä SaaS-, PaaS- että IaaS-palveluita. Siksi ensimmäinen kysymys ei ole ”ostaisinko pilvipalveluita”, vaan edellä esitelty kullekin sovellukselle optimaalinen hankintamalli.
 

Kansainvälinen julkinen pilvipalvelu

Useiden käyttäjien jakama pilvipalveluympäristö. Käyttäjät voivat ostaa verkon kautta itsepalveluna resursseja kuten virtuaalikoneita (VM), sovelluksia tai tallennustilaa. Palveluista laskutetaan yleensä käytön mukaan. Esimerkkejä: AWS, Azure.

Suomalainen julkinen pilvipalvelu

Kuten kansainvälinen julkinen pilvipalvelu sillä erotuksella, että kapasiteetti sijaitsee Suomessa.
Esimerkki: INcloud 9 (avoin lähdekoodi).

Hybridipilvi

Yhdistää kahta tai useampaa pilvipalvelua, joita hallitaan yhteisellä API-rajapinnalla kuten esimerkiksi Azurestack (Azure) ja Openstack (AWS).

Voidaan myös ajatella, että todellinen hybridipilvi on teknologia- ja alustariippumaton palvelu, joka koostuu koodilla ohjattavista kontitetuista applikaatioista eli mikropalveluista. Applikaatioita ja työkuormia voidaan perustaa minkä tahansa julkipilven tai private cloudin päälle.

Private Cloud eli yksityinen pilvi

Yrityksen omaan käyttöön rajattu ja automatisoitu palvelualusta, joka sijaitsee joko kumppanin tiloissa (co-location) tai asiakkaan omassa palvelinympäristössä (on-premise).

Parhaimmillaan yksityinen pilvi toimii kuten julkinen pilvi: palveluita voi ottaa pilvestä käyttöön nopeasti itsepalveluna, palvelun suorituskyky on käyttäjän määriteltävissä ja laskentaresursseista laskutetaan käytön mukaan.

Esimerkkejä: Vmware Vcloud, Azure Stack, Ormuco, Fluentscale. Lisäksi erilaiset avoimeen lähdekoodiin perustuvat Openstack-ratkaisut.
 

IT-infran rakentaminen: 7 pohdittavaa asiaa

Kun vaihtoehdot ovat tiedossa, siirrytään tarkastelemaan IT:lle asetettuja vaatimuksia. Listaan seitsemän yleistä kriteeriä, jotka kannattaa huomioida IT-infran valintoja tehdessä.
 

1. Latenssi

Latenssi eli tiedonsiirron viive sovelluksen ja palvelimen välillä on merkityksellinen palveluiden sujuvalle käytölle. Varsinkin, kun applikaatio tuottaa paljon pieniä tiedonsiirtopaketteja (esim. Client Server -applikaatio), voivat pakettien pitkät latenssiajat kertautuessaan hidastaa käyttöä häiritsevästi.

Kun latenssin on oltava mahdollisimman pieni, tulee palvelimien sijaita mahdollisimman lähellä ohjelmiston käyttäjiä. Parhaat vaihtoehdot ovat tällöin joko oma konesali tai joissain tapauksissa julkipilvipalvelu. Esimerkiksi AWS on monelle suomalaisyritykselle hyvä vaihtoehto Tukholmaan avautuneen datakeskuksen ansiosta.

2. Vikasietoisuus ja palautuminen

Yrityksen käyttämät sovellukset kannattaa luokitella kriittisyyden mukaan: mikä on liiketoimintavaikutus, kun sovellus on alhaalla? Erityisesti kriittisten, kuten tuotantoympäristön toimivuuteen vaikuttavien sovellusten vikasietoisuuteen ja palautumiseen tulee kiinnittää huomiota.

Vikasietoisuutta voidaan parantaa esimerkiksi palvelualustan kahdentamisella paikallisesti eli ajamalla sovellusta fyysisesti kahdella eri palvelimella saman fyysisen lokaation sisällä. Tällöin yhden palvelimen vikaantuessa sovellus jatkaa toimintaansa toisella palvelimella eikä käyttäjälle aiheudu katkosta.

Jos halutaan korkeampaa vikasietoisuutta, on vaihtoehtona rakentaa kahdentaminen useamman fyysisen lokaation avulla. Tällöin yhden fyysisen lokaation menettäminen ei vaaranna itse sovelluksen toimintaa. Tämä on kuitenkin yleensä myös kallein vaihtoehto, jos halutaan, että kaikki komponentit matkan varrella on kahdennettu ja data on aktiivisesti peilattu lokaatioiden välillä. Siksi tätä tapaa kannattaa käyttää vain kaikkein kriittisimmille sovelluksille.

Kolmas vaihtoehto on ns. disaster recovery eli datan replikointi / varmistaminen toiseen lokaatioon. Tällöin vikatilanteessa palveluiden nostaminen saattaa kestää kauemmin, mutta dataa ei menetetä.

Parhaat mahdollisuudet vikasietoisen ympäristön rakentamiseen löytyvät julkipilvestä. Vaihtoehtoisesti voit rakentaa omat konesalit, yhteydet sekä kahdennuksen ja sen valvonnan useampaan lokaatioon, mutta tämä ei aina ole se kustannustehokkain vaihtoehto.

3. Ketteryys

IT-kehityksen ketteryys voi olla merkittävä kilpailuvaltti: jatkuvan kehityksen malli tuottaa ajan myötä parempia palveluita liiketoiminnalle ja mahdolliset viat saadaan korjattua nopeammin.

Ketteryys voi toteutua, kun infraa (verkko, palomuurit, kapasiteetti, tallennus) voidaan hallita koodilla ja alusta on rakennettu käyttäen mikropalveluarkkitehtuuria ja kontittamista. Tällöin kehittäjien ei tarvitse odotella kapasiteettia ja asentaa siihen tarvittavia sovelluksia, vaan valmis kehitysympäristö on käytössä muutamassa sekunnissa.

Jos ketteryys on tärkeää, vaihtoehtosi löytyvät julkipilvestä tai private cloudista.

4. Datan sijainti

Joskus datan sijainti Suomessa tai esimerkiksi EU:n sisällä voi olla tärkeä asia. Syynä voi olla alan regulaatio tai yrityksen liiketoiminnan preferenssit.

Nykyään myös julkipilven tarjoajilla on toimintaa EU:n sisällä ja kuvatut datankäsittelyprosessit, joten ongelmaa GDPR-vaatimusten suhteen ei synny.

5. Tietoturva

Tietoturvauhat kehittyvät jatkuvasti ja niinpä myös hyökkäyksiltä suojautuminen ja niiden pysäyttäminen vaatii jatkuvaa kehitystyötä. Vastoin yleistä luuloa julkipilvi voi olla tietoturvallisempi vaihtoehto kuin oma konesali.

Selitys on yksinkertainen: julkipilven tarjoajilla ei ole varaa mokata ja niinpä heillä on oltava tarvittavat resurssit, osaaminen, varahenkilöjärjestelyt, 24/7 -toiminnot, liiketoiminnan jatkuvuussuunnitelmat, tietoturva- ja viranomaissertifioinnit sekä turvallisuus- ja tietoturvajärjestelyt kunnossa. Julkipilvessä infra on koodilla ohjattua ja automatisoitua eli myös tietoturvasta huolehditaan rutiiniomaisesti ilman ihmistyövoimaa. Huomaa kuitenkin, että pilvipalvelun tietoturva jakautuu tyypillisesti toimittajan ja ostajan kesken. Toimittaja vastaa konesalin fyysisestä tietoturvasta, konesaliympäristöstä ja laitealustojen valvonnasta sekä ylläpidosta ja päivittämisestä. Asiakkaan vastuulle jäävät puolestaan kaikki omaan ympäristöön liittyvät suunnittelu-, käyttöönotto-, ylläpito- ja päivitystehtävät. Jos omaa osaamista tai riittäviä resursseja ei ole, managed cloud -palvelut ovat huoleton vaihtoehto.

Lue lisää: Kysymyksiä tietoturvasta – pilvipalvelu vai perinteinen IT-ympäristö?

6. Skaalautuvuus

Vaihteleeko yrityksesi kapasiteetin tarve? Tarve voi kasvaa yllättäen piikkeinä tai nousujohteisesti yrityksen kasvun myötä. Jos suuremman kapasiteetin tarve on hetkittäistä tai kasvua on vaikea tarkalleen ennustaa, kannattaa valita pilvipalvelu, jolloin kapasiteettia on aina sopivasti ja laskutus käytön mukainen.

7. Tulevaisuudensuunnitelmat

Julkipilveen on helppo siirtyä, mutta hätiköimällä saattaa syntyä kalliiksi käyvä toimittajaloukku eli palvelu ei ehkä olekaan siirrettävissä tai provisioitavissa toiseen palvelualustaan.

Toimittajaloukun voi välttää, kun rakentaa palvelut mikropalveluarkkitehtuurilla ja muutenkin suunnittelee infran rakentamista pitkäjänteisesti. Hyvä esimerkki fiksusta arkkitehtuurista on Suomen Messujen toteutus.
 

Miten alkuun IT-infran uudistamisessa?

Fiksu IT-infran uudistaminen alkaa liiketoiminnan tavoitteista. Sen jälkeen on vuorossa arkkitehtuurin rakentaminen näitä tavoitteita tukevaksi. Mitä moninaisemmat ovat yrityksen tarpeet, sitä huolellisemmin suunnittelu kannattaa tehdä.

Pilvipolku-palvelumme auttaa luomaan kokonaisuuden, joka on optimaalinen yrityksesi toiminnalle ja kasvulle.
Lue lisää Pilvipolusta: