Pilvi vai konesali – kumman valitsisit, osa 2 – kustannukset

pilvi kustannukset

Oletko miettinyt, kannattaisiko palveluita siirtää perinteisestä konesalista pilveen?  

Tässä artikkelissa kerron, kumpi on parempi, pilvi vai konesali, kun verrataan konesalin ja pilvipalvelun kustannuksia.

Keskustelua pilvipalvelun ja perinteisen konesalin välillä voisi verrata keskusteluun, jossa verrataan omistusasumista ja vuokralla asumista.

Harva omistusasuja osaa oikeasti luetella kaikki todelliset (suorat ja epäsuorat) kustannukset, joita esimerkiksi omakotitalossa asumiseen liittyy.


Harva perinteisen konesalin kannattaja osaa luetella kaikkia (suoria ja epäsuoria) kustannuksia, joita konesalin pyörittämiseen liittyy.


Jos olet kuullut väitteitä, että julkinen pilvi on kallis ja oma konesali halpa, kannattaa lukea eteenpäin.

  • Kerron tässä artikkelissa, mihin väite siitä, että julkinen pilvi on kallis, perustuu.
  • Lisäksi kerron, mitä ihmiset unohtavat, kun he vertaavat perinteisen konesalin ja pilven kustannuksia.
  • Käsittelen artikkelissa perinteisen konesalin kustannusrakennetta ja vertaan sitä pilvipalvelujen kustannusrakenteeseen.

Jos teillä on oma konesali, osaatko sanoa, mikä on yhden fyysisen tai virtuaalisen palvelimen tuotantokustannus? Vastauksen antaminen ei ole helppoa.

Pilvipalvelun kustannukset ovat keskeinen valintakriteeri, kun mietitään valintaa pilvipalvelun ja perinteisen konesalin välillä.


Tämä artikkeli on toinen osa kirjoitussarjaa, jossa vertailen julkista pilveä ja perinteistä konesalia.

Ensimmäisessä artikkelissa käsittelin uusien palveluiden kehittämisen nopeutta julkisessa pilvessä ja perinteisessä konesalissa.

On aika selvää, että perinteisellä konesalilla ei ole mitään jakoa kisassa julkisen pilven kanssa, kun puhutaan palvelun pystyttämisen nopeudesta. Jos haluat lukea tämän ensimmäisen artikkelin, löydät sen täältä.

Kehittämisen nopeus on kuitenkin vain yksi näkökulma mietittäessä valintaa pilvipalvelun ja perinteisen konesalin välillä.


Sisällysluettelo


Luku 1: Perusasiat haltuun

Luku 2: Perinteisen konesalin laitteisto- ja ohjelmistokustannukset

Luku 3: Konesalin infrakustannukset

Luku 4: Konesalin henkilöstökustannukset

Luku 5: Yhteenveto konesalin kustannuksista

Luku 6: Pilvipalvelu, kustannukset

Luku 7: Pilvipalvelu, muut kustannukset

Luku 8: Pilvipalvelut, mahdollisuuksia säästää kustannuksissa

Luku 9: Kumpi tulee edullisemmaksi – pilvi vai perinteinen konesali?



ETKÖ EHDI LUKEA KIRJOITUSTA NYT?

Ei hätää, voit tilata artikkelin PDF-mutoisena sähköpostiisi.


Luku 1: Perusasiat haltuun

Ennen kun syvennymme varsinaiseen asiaan, on tärkeää ymmärtää pilvipalveluista joitakin perusasioita. Tässä muutama asia pilven palvelumalleista.


Jos pilvipalvelut eivät ole kovin tuttuja, lue tämä luku. Jos taas tunnet pilvipalveluiden toimintaa hyvin, voit hypätä seuraavaan lukuun.


Pilvipalvelun keskeiset ominaisuudet

Seuraavassa on listattu pilvipalvelun keskeiset ominaisuudet. Lista on yhdistelmä usein referoidun USA:n National Institute of Standards and Technology -organisaation (NIST) pilvipalvelun määritelmästä ja Thomas Erlin Cloud Computing (Concepts, Technology & Architecture) -kirjan määritelmästä.

Määritelmät ovat toisiaan täydentäviä ja ne yhdistämällä sadaan mielestäni parempi kuva pilvipalveluiden ominaisuuksista.


  • Itsepalvelu (self-service).  Pilvipalvelussa on käyttöliittymä, jonka avulla asiakas pystyy tilaamaan palveluita itsepalveluna.


  • Palvelun saa käyttöön tarvittaessa (On-demand). Itsepalvelukäyttöliittymän jatkona on automaatiokerros, jonka avulla tilatut palvelut provisioidaan käyttöön automaattisesti, ilman palveluhenkilökunnan tekemää käsityötä. Automaatio lyhentää olennaisesti aikaa, joka kuluu palvelun tilaamisesta siihen kun palvelu on käytössä.


  • Kattavat verkkoliitännät (Ubiquitous network access). Perinteinen IT-ympäristö on sisäverkossa, josta se erikseen julkaistaan Internetiin. Aito pilvipalvelu on kytketty lähtökohtaisesti internetiin. Tämän ansiosta palvelut saadaan helpommin erilaisten käyttäjien saataville.


  • Resurssipoolit (Resource pooling). Aito pilvipalvelu perustuu fyysisten palvelin-, tallennus- ja verkkoresurssien yhdistämiseen virtualisointitekniikoiden avulla. Tämän vuoksi resursseja voidaan lisätä ja vähentää joustavasti tarpeen mukaan.


  • Joustavuus (Rapid Elasticity). Joustavuus perustuu virtualisointiin ja automaatioon. Sen ansiosta yksittäisen palvelun kuluttamia resursseja voidaan skaalata reaaliaikaisesti tarpeen mukaan joko kasvattamalla palvelussa mukana olevien noodien määrää (scale out) tai kokoa (scale up).


  • Häiriötiloja sietävä (Resiliency). Häiriötilojen sieto pitää sisällään useiden tekniikoiden hyödyntämisen. Kaikkia pilvipalveluita ei ole konfiguroitu sietämään häiriöitä. Teknologiamielessä tämän pitäisi kuitenkin olla mahdollista.


Palvelumallit


  • Software as a Service (SaaS). SaaS-palvelussa palveluntarjoaja vastaa koko palveluntuottamiseen tarvittavasta infrasta, virtuaalipalvelimista ja ohjelmistoista. Asiakas vastaa vain käyttäjähallinnasta ja datasta, jota päättää syöttää järjestelmään. SaaS-palvelu on asiakkaalle helpoin ottaa käyttöön, mutta tarjoaa vähiten joustavuutta palvelun suhteen.  SaaS-palvelut ovat nykyään erittäin suosittuja niiden helppouden vuoksi. SaaS-palveluja on helppo ottaa käyttöön ja niiden kustannukset on helppo tietää etukäteen.


  • Platform as a Service (PaaS). PaaS-palvelussa palveluntarjoaja vastaa edelleen infrasta ja virtuaalipalvelimista sekä niiden päällä pyörivästä “alustasta”, joka voi olla esimerkiksi SQL-kanta tai sovelluskehitysympäristö. Asiakkaan vastuulle jää tämän alustan hyödyntäminen. Palvelumalli vaatii asiakkaalta enemmän, mutta antaa enemmän vapautta kuin SaaS. PaaS-palvelujen suosio on tähän saakka ollut vähäisempää kuin SaaS-palvelujen, mutta ne yleistyvät kovaa vauhtia, koska organisaatiot ovat alkaneet ymmärtää niiden hyödyt.


  • Infrastructure as a Service (IaaS). IaaS-palvelussa palveluntarjoaja vastaa konesaleista, fyysisistä palvelimista ja virtualisointikerroksesta ja asiakas vastaa virtuaalipalvelimista sekä käyttöjärjestelmistä lähtien kaikesta palveluun liittyen. Palvelumalli on joustavin näistä kolmesta, mutta vaatii samalla eniten vaivannäköä. Tämä on lähinnä perinteistä konesalia.


Kaipaatko lisää taustatietoa siitä, mistä pilvipalveluissa on kyse? Olen käsitellyt pilvipalveluiden ominaisuuksia artikkelissani


Mistä tunnistaa pilvipalvelun

Nyt voimme alkaa käsitellä kustannuksia, joita perinteisessä konesalissa pitää ottaa huomioon.


Luku 2: Perinteisen konesalin laitteisto- ja ohjelmistokustannukset


Tässä luvussa käsittelen vain laitteita ja ohjelmistoja, joita perinteisen konesalin pyörittämiseen tarvitaan.

Lue eteenpäin, niin saat tietää, mistä perinteisen konesali-infran kustannus koostuu.

Yritetään listata komponentteja, joiden kustannusvaikutus pitää ottaa huomioon.

Seuraavassa kuvassa on avattu kokonaisuutta.

Konesali palvelin verkko storage

Konesali-infran teknisiä komponentteja


Aloitetaan kokonaisuuden tarkasteleminen palvelimista.


Fyysinen palvelin


Palvelimen kustannukseen vaikuttaa tietysti palvelimen rungon lisäksi esimerkiksi muistin määrä, prosessorit ja esim. verkkokortit. Homma on melko yksinkertainen, kun on kyse räkkipalvelimesta.

Jos kyseessä onkin blade-palvelin (kehikkoon asennettava korttipalvelin), hinnanmuodostus on heti monimutkaisempaa.

Yhden korttipalvelimen lisäksi mukaan tulee kehikon hinta. Kokonaisuuden hinta riippuu siitä, monelleko kortille kehikko on tarkoitettu, ja montako korttia kokonaisuuteen hankitaan.

Lasketaanko hinta täyden kehikon mukaan vai kuinka monelle kortille kehikon hinta jyvitetään?


Virtuaalipalvelin


Kustannusten jyvittäminen muodostuu hankalaksi, kun otetaan mukaan virtuaalipalvelimet. Käytännössä lisäkustannus, joka pitää ottaa huomioon, on virtualisointiohjelmiston kustannus. Esimerkiksi VMware lisensoi ainakin osan palvelinvirtualisointiohjelmistonsa komponenteista fyysisten prosessorien mukaan. 

Kun aletaan jakaa kustannuksia virtuaalipalvelimille, ongelmaksi muodostuu sen tietäminen, montako virtuaalipalvelinta yhteen fyysiseen palvelimeen mahtuu.

Lasketaanko kustannukset maksimimäärän mukaan? Vai olisiko parempi mennä jonkinlaisen keskiarvon mukaan?

Entä kun virtuaalipalvelinten koot ovat erilaisia, miten erilaiset resurssitarpeet otetaan huomioon? Entä jos virtuaalipalvelimelle osoitetaan kesken kaiken enemmän muistia ja prosessoritehoa kuin aiemmin? Miten tämä vaikuttaa kustannuksiin?

Jo tästä lyhyestä pohdinnasta huomataan, että kustannusten jyvittäminen virtuaalipalvelintasolla on käytännössä haastavaa, kuten nykyään on tapana sanoa vaikeista asioista.

Käyttöjärjestelmät

Palvelimet tarvitsevat toimiakseen palvelinkäyttöjärjestelmän. Jokainen virtuaalipalvelin ja jokainen fyysinen palvelin tarvitsee oman käyttöjärjestelmän. ​

Käyttöjärjestelmien hinta muodostuu esimerkiksi Microsoftin tapauksessa valitun lisensointisopimuksen perusteella. Ydin on kuitenkin siinä, että palvelinlisensointi pitää ottaa kustannusmielessä huomioon ja miettiä tapauskohtaisesti.


Tallennus

Yksinkertaisimmillaan jokaisessa fyysisessä palvelimessa on omat kovalevyt, joille kaikki tieto tallennetaan.

Käytännössä yritystason järjestelmissä on yleensä käytössä erilliset levyjärjestelmät. Tällöin palvelimissa ei itsessään ole isoja levyjä, vaan ne käyttävät tallennustilana keskitettyä tallennusjärjestelmää.

Tallennusjärjestelmä voi koostua tallennusverkosta, controllerista (ohjausyksikkö), itse levyistä, joita voi olla hyvin eritasoisia ja siten eri hintaisia.


Tallennusverkko voi olla perinteinen ns. SAN-verkko (Storage Area Network), jolloin palvelimet keskustelevat tallennusjärjestelmän kanssa erillisen fyysisen verkon avulla.

Tallennusverkko tarvitsee toimiakseen ainakin liittimet, kaapelit ja tallennuskytkimet.


Tallennusjärjestelmä tarvitsee toimiakseen controller-yksiköt. Ne ohjaavat koko levyjärjestelmän toimintaa. Varsinainen tallennuspinta on kuitenkin erikseen.

Hidas perinteinen kovalevy on edullisin tallennuspinta. Kun levyn pyörimisnopeus nousee, nousee myös hinta.


Käytännössä uudet tallennusjärjestelmät perustuvat yleensä SSD-levyihin, joissa ei ole pyöriviä osia. Tallennuspintana toimii puolijohdepiiri, joka mahdollistaa nopeat luku- ja kirjoitusnopeudet.

Kun käytännön tallennusjärjestelmä koostuu monesta eri komponentista, pitää kaikkien näiden kustannukset jakaa fyysisille ja virtuaalipalvelimille. Miten kustannusten jyvittäminen hoidetaan käytännössä?

Millaiseen kasvunvaraan laskelmissa varaudutaan? Jos laskelmat tehdään sen mukaan, että ympäristö on täyteen kalustettu ja täynnä virtuaalipalvelimia, todelliset kustannukset eroavat suuresti tästä laskennallisesta skenaariosta.


Palvelimesta ei ole paljoa hyötyä, jos sitä ei ole kytketty tietoliikenneverkkoon. Tarkastellaan siis seuraavaksi tietoliikenneverkkoa kustannusten näkökulmasta.


Tietoliikenneverkko

Konesalin tietoliikenneverkko koostuu kytkimistä, mahdollisesta reitityksestä ja palomuurista sekä internet-yhteyksistä. Kytkinten lisäksi tarvitaan iso määrä kaapeleita, joiden avulla laitteet kytketään toisiinsa.

Kun aletaan jyvittämään kytkinten kustannuksia yksittäisille fyysisille tai virtuaalipalvelimille, joudutaan pohtimaan sitä, paljonko yksittäinen tietoliikenneportti maksaa.

Koska kaikki palvelimet tarvitsevat kaksi liitäntää kytkimiin (kahteen eri kytkimeen tai modulaarisesn kytkimen tapauksessa kahteen eri moduliin), nostaa tämä kustannuksia.

Minkä verran internet-yhteyteen, palomuuriin ja reititystasoon liittyvistä kustannuksista pitäisi jyvittää yksittäiselle palvelimelle? Entä kun internet-yhteyden nopeutta nostetaan, miten kustannukset siinä tapauksessa jaetaan?



Perinteisessä konesalissa IT-infra pitää mitoittaa maksimikapasiteetin mukaan


Yksi haaste perinteisessä IT-infrassa on siinä, että kapasiteettia ei yhtäkkiä saada mistään. Jos kapasiteetti loppuu kesken joulumyynnin, se loppuu, eikä sitä saa välttämättä kovin helposti lisää.


Kapasiteetin hankalan saatavuuden vuoksi ympäristöt pitää yleensä mitoittaa huippukuorman mukaan. Tämä on ikävää, jos kapasiteettitarve vaihtelee suuresti.


Jos kapasiteettia tarvitaan jouluna 100 yksikköä ja muuna vuonna 10 yksikköä, ympäristö pitäisi mitoittaa 100 yksikön mukaan. Kun normaalisti tarvitaan vain vähän kapasiteettia ja sesonkina paljon, on kustannusten kohdistaminen yhdelle palvelimelle vaikeaa tai ainakin ikävää, koska varautumiskustannus on merkittävä.



Luku 3: Konesalin infrakustannukset


Palvelimet tarvitsevat aina niille varatun tilan. Tässä luvussa käsittelen konesali-infran kustannuksia. Monet näistä liittyvät itse tilaan ja sen varustamiseen konesalin pyörittämistä varten.

Seuraavaan kuvaan on koottu konesali-infraan liittyviä kustannuksia.

laitetila kustannukset

Konesalin-infran komponentteja.


Räkit

Palvelimet asennetaan käytännössä räkkeihin. Yhteen räkkiin mahtuu tietty määrä palvelimia, ja osa räkistä yleensä varataan räkin tietoliikennelaitteille.

Vaikka räkki ei maksakaan paljoa, sen kustannukset pitää ottaa huomioon, kun lasketaan yksittäisen palvelimen kustannusta.


Tilavuokra

Jokainen tila maksaa jotain. Asiallisessa konesalitilassa on usein erikoisrakenteita, jotka maksavat. Niiden kustannusten arvioiminen ja jakaminen palvelimille voi olla ongelmallista.

Perusongelma on aina sopivan kokoisen tilan hankkiminen. Jos tila on liian suuri ja kasvunvaraa on paljon, kustannus per palvelin muodostuu kohtuuttomaksi. Jos taas tila on liian pieni, ajaudutaan nopeasti tilanteeseen, jossa tila täyttyy ja joudutaan hankkimaan lisätilaa jostain muualta. Tämä taas johtaa hankaluuksiin konesalien yhdistämisessä. Vaikka salit saadaan yhteen, sen jälkeen joudutaan miettimään sitä, missä salissa ajetaan mitäkin järjestelmää.


Kulunvalvonta ja murtosuojaus

Murtosuojauksen vuoksi palvelintilan oven pitää olla vähintään metallia, ovi vaatii erillisen lukitusjärjestelmän, tila vaatii kulunvalvonnan, videovalvonnan jne. Jos tilassa on ikkunoita, niihin vedetään murtautumista hankaloittavia kalvoja ja seiniä saatetaan joutua vahvistamaan.

Olen käynyt lukemattomissa ns. konesaleissa, jotka ovat ennemmin huoneita, joissa satutaan säilyttämään palvelimia. Konesalien kanssa niillä ei ole hirveästi tekemistä.


Sähkön syöttö

Jokainen konesalien suunnittelun kanssa tekemisissä ollut tietää, miten haastavaa on arvioida sähkönsyötön riittävyyttä. Millaisia sähkönsyöttöjä rakennukseen on saatavana?

Miten sähkönsyöttö varmistetaan poikkeustilanteita varten? Onko rakennukseen saatavana useasta eri suunnasta tulevaa sähkönsyöttöä?

Tuleeko räkeille sähkönsyöttö kahdesta eri vaiheesta, jotta sähköä olisi aina saatavilla?

Onko sähkönsyöttö varmistettu UPS:lla (akusto)? Onko akustoja yksi vai kaksi? Kauanko akuston varassa voidaan toimia?

Onko konesalilla omaa aggregaattia, jolla sähköä voidaan tuottaa, vaikka sähköverkko olisikin alhaalla? Tarvitaanko kenties kaksi aggregaattia?

Ilmastointi ja jäähdytys

Kun palvelinten tehot ovat kasvaneet, on konesalien jäähdytyksestä tullut jatkuvasti isompi haaste.

Miten varmistetaan riittävä jäähdytys? Miten paljon lämpökuorma saa kasvaa? Onko jäähdytys kahdennettu niin, että kesähelteillä hajoava jäähdytyskone ei aja palvelimia vikatilanteeseen?

Miten kohdistetaan jäähdytyksen vaatimat investoinnit yksittäiselle palvelimelle?


Palosuojaus

Lähellekään kaikissa ns. konesaleissa ei ole palosuojausta. Vettä ei voi käyttää ja kaasujärjestelmät ovat kalliita. Oikeaan konesaliin sammutusjärjestelmät kuitenkin kuuluvat.

Sammutusjärjestelmä vaatii kohtuullisen kokoisen investoinnin, ja sekin on luonteeltaan hieman hankalasti jyvitettävissä.

Periaatteessa investoinnin suuruus on tiedossa, mutta kuten totesin aiemmin, oikean palvelinmäärän määrittäminen on hankalaa. Käytetäänkö teoreettista palvelinten maksimia vai jotain muuta lukua? Mikään luku ei ole täydellinen.

Tekninen infrastruktuuri muodostaa kuitenkin vain osan kokonaiskustannuksista. Suuri osa kustannuksista muodostuu ylläpitohenkilöstöstä.


Luku 4: Konesalin henkilöstökustannukset


Kun luet tämän luvun, saat selville, millaisia henkilöstökustannuksia perinteiseen konesaliin liittyy.


Yksikään konesali ei pyöri ilman henkilöstöä. Ei varsinkaan perinteinen konesali, jossa suurin osa ylläpitotyöstä on manuaalista.


Käyttöönotto

Jokainen edellisissä luvuissa käsittelemäni laitteisto vaatii käyttöönottoa. Suurimman osan laitteista ja ohjelmistoista voi tietysti ostaa asennettuna. Jos asennukset hoidetaan ulkopuolisen toimittajan toimesta, kustannusten hallinta on tältä osin melko helppoa.

Usein kuitenkin osa asennuksista tehdään itse. Erityisesti esimerkiksi uusien virtuaalipalvelinten asentaminen tai käyttöönotto hoidetaan itse. Kysehän ei yleensä ole monimutkaisesta työstä.

Jos verkkoon ei tarvitse koskea, asia hoituu palvelinylläpidon toimesta. Jos ympäristön konfigurointi vaatii enemmän työtä, tilanne muuttuu kiinnostavammaksi. Verkot, palomuurit, palvelimet ja sovellukset voivat kaikki vaatia asentamista ja konfiguroimista.

Tällöin voi olla vaikeaa määritellä, mikä osa henkilöstökustannuksista tulisi kohdistaa asennuksiin tai käyttöönottoihin. Tarkka jyvittäminen ei onneksi ole yleensä oleellista.

 

Ylläpito

Kaikki laitteistot ja ohjelmistot vaativat ylläpitoa. Käyttöjärjestelmät vaativat konfigurointia ja päivittämistä ja yksittäiset sovelluksetkin tarvitsevat päivittämistä.

Tallennusjärjestelmätkin vaativat ylläpitoa.

Myös tietoliikenneverkko vaatii ylläpitoa, palomuuri vaatii ylläpitoa ja seuraamista.

Vaikka moni komponentti ei vaadi päivittäistä hoivaamista, ihmisten pitää kuitenkin tehdä asioita aina silloin tällöin. Tämä vaatii henkilöstöä. Yleensä tarvitaan useampia ihmisiä pelkästään osaamisen vuoksi. Yksi ihminen ei yleensä osaa tehdä kaikkia asioita itse, ainakaan kunnolla.

Myös sijaisjärjestelyt vaativat useamman kuin yhden henkilön pitämistä ylläpitotöissä.

Usein järjestelmien ja kokonaisuuksien dokumentointi jää rempalleen. Tämä voi kostautua, kun ihmiset lähtevät muihin töihin, ja tieto lähtee organisaatiosta näiden ihmisten mukana. Tämän vuoksi myös IT-infra pitäisi pyrkiä dokumentoimaan järkevällä tasolla. Dokumentoiminenkin vie aikaa ja vaatii henkilöstön ajankäyttöä siihen.


Hankintaan liittyvät kustannukset

Yksikään järjestelmä ei ole ilmaantunut konesaliin itsestään. Laitteilla on elinkaaret, tyypillisesti kolmesta viiteen vuotta, jonka loppuvaiheessa pitää alkaa miettimään seuraavaa laitesukupolvea.

Hankinnan valmisteleminen vaatii tiedon hankkimista uusista ratkaisuista. Hankinnasta vastaavan pitää kerätä tietoa siitä, mikä on mahdollista, selvittää ratkaisujen teknisiä ominaisuuksia ja kustannuksia.

Vaikka itse suunnitteluun palkattaisiinkin ulkopuolinen asiantuntija, tekemistä riittää. Hankinnat halutaan kilpailuttaa, toimittajia ja ratkaisusisältöjä verrata.

Konesalin rakentamiseksi on erilaisia arkkitehtuureja, joiden hyviin ja huonoihin puoliin pitää tutustua. Vaikka toimittajia voikin käyttää tiedon keräämiseen, yleensä jonkun omasta väestä olisi hyvä ymmärtää edes kohtuullisen syvällisesti, mitä mikäkin ratkaisu tarkoittaa. Usein tässäkin joudutaan turvautumaan ulkopuoliseen apuun.

Ihmiset tarvitsevat koulutusta, joten koulutuksenkaan tuomia lisäkustannuksia ei voi unohtaa.

Konesalin ylläpitäjät muodostavat tyypillisesti tiimin, jolla on myös esimies. Usein samaan tiimiin kuuluu myös loppukäyttäjäympäristön ylläpitäjiä. Jos esimies käyttää osan ajasta myös muiden kuin konesalin asioiden johtamiseen, mikä osuus hänen työajasta pitäisi allokoida konesalille?

Jos katsotaan kaikkia henkilöstökuluja, mikä osuus niistä pitäisi jyvittää konesalille? Kuten huomasimme, kysymykseen voi olla vaikea vastata. Kun pyrimme allokoimaan kustannuksia palvelintasolle, laskelma muodostuu oikeasti hankalaksi


Luku 5: Yhteenveto konesalin kustannuksista

Tässä luvussa on yhteenveto konesalin kustannuksista.

Kustannukset koostuvat siis seuraavista elementeistä:

  1. Laitteistoihin ja ohjelmistoihin liittyvät kustannukset
  2. Infraan liittyvät kustannukset
  3. Henkilöstöön liittyvät kustannukset


Oma konesali sisältää selvästi paljon kiinteitä kustannuksia, jotka juoksevat siitä huolimatta, paljonko konesalissa on palvelimia. 

Kulut juoksevat siitä huolimatta, käytetäänkö palvelimia mihinkään. Koska kuluja ei pysty normaalisti leikkaamaan olemalla käyttämättä jotain palvelinta, säästöjä voi olla vaikea löytää.

Seuraavassa kuvassa on hieman esimerkkiä siitä, miten kustannukset jakautuvat eri vuosille. 

Konesali capex

Olen olettanut, että ensimmäisenä vuonna rakennetaan konesalia. Sen vuoksi infrakustannukset ovat suuria. 

Toisena vuonna saliin ostetaan paljon laitteita ja ohjelmistoja ja kolmantena alkaa normaali ylläpito.


Perinteisen konesalin ongelma on selvästi isot kiinteät kustannukset.


Muutaman vuoden päästä aletaan taas uusimaan laitteita ja konesali-infrakin alkaa kaipaamaan päivittämistä viimeistään viiden vuoden iässä. Vähintään akustoja pitää alkaa uusimaan.

Tein esimerkistä tarkoitushakuisen ihan tahallaan. Halusin tuoda esiin konesaleihin liittyvän perusongelman, joka on suuret kiinteät kulut.

Vaikka tietotekniikkatarpeet muuttuisivatkin, kuluihin on vaikea vaikuttaa.

Isojen kiinteiden kustannusten kohdistaminen luotettavasti yksittäiselle palvelimelle on hankalaa, ja laskelmat ovat herkästi epäluotettavia. vu

IT-infraa tietysti tarvitaan, mutta ei se mitään kilpailuetua muodosta, ainakaan kovin helpolla. Ainakaan johdon voi olla vaikea nähdä yhteyttä liiketoimintatavoitteiden ja IT-infraan tehtävien investointien välillä.

Perinteisen konesalin ongelma on selvästi isot kiinteät kustannukset. Kustannukset ovat pitkälti luonteeltaan pääomaa sitovia eli Capex-kustannuksia. Konesaliin liittyy siis paljon kustannuksia, jotka juoksevat siitä huolimatta, käytetäänkö konesalia vai ei.

Kokonaan toinen kysymys on oman IT-henkilöstön muodostamat kustannukset. Ihmisiä tarvitaan yllättävän paljon pyörittämään tuotantoa, erityisesti jos ympäristöä pitää ajaa tuotannossa 24x7. 


Lähdetään seuraavaksi tarkastelemaan pilvipalveluiden kustannusrakennetta.


Luku 6: Pilvipalvelun kustannukset


Tässä luvussa käsittelen sitä, miten pilvipalvelun kustannukset muodostuvat. Olen käyttänyt esimerkkinä Azuren hinnoittelua. Se on kuitenkin vain esimerkki, enkä ota tässä artikkelissa kantaa siihen, onko Azure parempi tai huonompi kuin Amazonin AWS tai Google Cloud.

Jos lähtisin vertailemaan eri palveluiden hintoja tässä artikkelissa, jonka tarkoitus on verrata oman konesalin ja pilvipalvelun kustannusrakenteita keskenään, artikkelista tulisi aivan liian laaja. Sen vuoksi en tee vertailua pilvipalvelujen välillä, enkä myöskään ota kantaa siihen, mikä olisi hyvä pilvipalvelu


Käyttöön perustuva veloitus


Ensimmäinen perusperiaate liittyy veloitukseen. Pilvipalveluiden veloitus perustuu käyttöön. Tyypillisesti pilvipalveluita myydään tuntiveloituksella. Palvelun käyttöönotto ei itsessään maksa mitään, mutta jokainen käytetty tunti maksaa erikseen.

Pilvipalvelut tarjoavat eri kokoisia ja erilaisilla suorituskyvyllä varustettuja palvelimia. Ne on hinnoiteltu suorituskyvyn mukaan. Mitä enemmän palvelimessa on muistia, virtuaaliprosessoreita ja tallennustilaa, sitä enemmän palvelin maksaa.

Asiakkaan pitää tietysti osata päättää minkä kokoisen palvelimen hän haluaa. Koska palvelimen speksien määrittäminen ei ole ihan yksinkertaista, Microsoft on ryhmitellyt palvelimia siten, millaiseen käyttöön ne on optimoitu. Palvelinten kokoa voi kuitenkin muuttaa jälkeenpäin – usein lennosta. 

Pilvipalvelu kustannukset

Lähde: azure.microsoft.com

 


Pitkäaikaiset sitoumukset ovat halvempia


Lähtökohtaisesti pilvipalvelut siis hinnoitellaan sen mukaan, montako minuuttia tai tuntia ne ovat käytössä. Tähän perusperiaatteeseen löytyy nykyään poikkeuksia.

Esimerkiksi Microsoft Azure tarjoaa nykyään tuntihintoja huomattavasti edullisempia hintoja, jos asiakas sitoutuu käyttämään palvelimia pidempään, esimerkiksi yhdestä kolmeen vuotta. Kyse on ns. Reserved instansseista.

Jos sopimuksesta haluaa päästä irti ennen sen päättymistä, pitää maksaa yhden kuukauden ylimääräinen maksu.

Alla olevasta kuvasta näkee, että varaamalla palvelimen vuodeksi hinnat putoavat esimerkkipalvelimilla n. 40% verrattuna käyttöön perustuvaan laskutukseen. Jos palvelimen varaa kolmeksi vuodeksi, alennus on esimerkkipalvelimilla n. 60%.


Pilvipalvelut hinta sopimusjakso

Azure hintavertailu: Pay as you go vs. varatut instanssit


Kustannuksilla on väliä


Seuraavassa kuvassa on yleiskäyttöön sopivia palvelimia tuotettuna Azuren Pohjois-Euroopan konesalista. Näissä on mukana Windows-käyttöjärjestelmä. Kustannukset on näytetty kuukausihintana, jolloin niitä on helpompi verrata perinteisen konesalin kustannuksiin.

  

Azure, esimerkkihintoja

Lähde: azure.microsoft.com

Esimerkki sopimuskauden vaikutuksesta Windows-palvelimen hintaan.

Kuvasta huomaa, että edulliselta vaikuttavat tuntihinnat ovatkin kuukausihintana helposti yllättävän suuria. Mikäli pilvessä halutaan ajaa perinteistä infraa, siis virtuaalipalvelimia, ovat varatut instanssit huomattavasti edullisempia ja järkevämpiä.

Miksi näiden hintojen alennus on pienempi kuin aiemmassa esimerkissäni? Vastaus liittyy lisensointiin.

Lue eteenpäin, niin kerron, miten lisensointi vaikuttaa kustannuksiin.


HALUAISITKO SAADA ARTIKKELIN OMAKSI?

tilaa artikkeli PDF-mutoisena sähköpostiisi.

Lisenssien vaikutus kustannuksiin


Alun esimerkeissä palvelimet eivät olleet Windows-palvelimia, vaan todennäköisesti Linux-palvelimia, joiden lisensointikustannus on olematon.

Kun pilvessä halutaan ajaa virtualisoitua Windows-palvelinta, siihen tarvitaan tietysti lisenssi, joka maksaa. Tämä selittää sitä, miksi Windows-palvelimien hintoja esittävän kuvan alennus on pienempi, vaikka palvelin varattaisiin pitkäksi aikaa. 

Palvelimen varaaminen liittyy palvelinkapasiteetin varaamiseen. Kapasiteetin varaaminen tulee edullisemmaksi, jos sitä varaa pitkäksi aikaa. Lisenssi maksaa kuitenkin koko ajan saman verran. Sen vuoksi alennusprosentti jää pienemmäksi kuin alun esimerkissä.


Omat lisenssit käyttöön


Ehkä huomasit edellisestä kuvasta viimeisen sarakkeen, jossa hinnat olivat huomattavasti halvempia.

Lähtökohtaisesti palvelinten hinta sisältää käyttöjärjestelmän. Asiakas ei siis tarvitse erikseen lisenssejä, vaan Microsoft huolehtii lisensoinnista. Tämä on kätevää, jos lisenssejä ei ennestään ole.

Tilanne mutkistuu, jos asiakkaalla on omia lisenssejä ja olisi tarkoitus esimerkiksi siirtää olemassa olevia virtuaalikoneita pilveen. Tällöin voi tuntua tuhlaukselta maksaa lisensseistä uudelleen.

Tällainen tilanne voisi muodostua, jos virtualisointiympäristöä on konsolidoitu, ja organisaatiolle on jäänyt ylimääräisiä Windows -käyttöjärjestelmälisenssejä tai SQL-lisenssejä.

Jos lisenssit ovat ylläpidossa, niitä voi käyttää pilvessä. Microsoft puhuu tästä Azure Hybrid Benefit -ohjelmana. Ohjelma mahdollistaa siis itse omistettujen, ylläpidossa olevien palvelinlisenssien käytön pilvessä.

Jos siis varastossa on ”ylimääräisiä” palvelinlisenssejä, jotka ovat ylläpidossa, niitä voi siirtää pilveen ja käyttää siellä. Samanaikainen käyttö omassa konesalissa ei ole mahdollista. Jos siis lisenssiä haluaa käyttää pilvessä, pitää instanssi sammuttaa omasta konesalista ja päinvastoin.

Jotta asia ei olisi liian yksinkertainen, data center -lisenssejä voi käyttää molemmissa paikoissa yhtä aikaa.

Luku 7: Pilvipalvelu, muut kustannukset

Tässä luvussa käsittelen lyhyesti pilvipalveluun liittyviä muita kustannuksia.

Pilvipalveluiden hinnoittelussa on joitakin hankalasti arvioitavia kustannuksia. Näitä ovat mm. tietoliikennekustannukset sekä tallennustilaan liittyvät kustannukset.


Tietoliikennekustannukset


Tietoliikenteen osalta hintoihin sisältyy sisään tuleva liikenne, mutta ei ulospäin menevää liikennettä. Tällä ei ole suurta merkitystä, jos tietoliikennetarve ei ole suurta. Kuitenkin jos liikennemäärät ovat suuria, voi tietoliikenteestä aiheutua merkittäväkin kustannuserä.

Tietoliikennekustannusten suuruutta on yleensä vaikea arvioida etukäteen.

Siinä vaiheessa, kun palvelu on käytössä, alkaa tietoliikennekustannus olla selvillä. Lähtökohtaisesti yhteys pilveen rakennetaan julkisen internetin yli.

Mikäli pilveen halutaan ”suora” yhteys, voidaan hankkia yhteys, joka ei kulje internetin kautta. Tällöin yhteydestä esim. Azureen maksetaan kiinteää hintaa, jonka kustannus ei siis riipu liikennöintimääristä.

Yhteenvetona voi todeta, että tietoliikenteen kustannukset pitää ottaa huomioon laskelmissa. Ne lisäävät peruskokoonpanon kustannuksia. Se, kuinka paljon kustannukset nousevat, riippuu täysin pilviympäristön koosta ja käyttötarkoituksesta.


Tallennuskustannukset


Palvelin sisältää vain rajallisen määrän tallennustilaa. Isommat tallennustilat pitää hankkia erikseen. Tähän tarkoitukseen on paljon erilaisia vaihtoehtoja.

En käsittele tässä tallennuskustannuksia sen tarkemmin, mutta on hyvä huomata, että tallennustilan luomat kustannukset on tärkeää huomioida.


Laitteistoihin liittyvät kustannukset

Pilvipalvelun hinnat sisältävät kaikki laitteistokustannukset. Palvelun asiakkaan ei siis tarvitse miettiä fyysisten palvelinten kokoonpanoja, elinkaaria, uudistamista, tietoliikenneverkkoa eikä tallennusjärjestelmän kustannuksia.


Fyysinen konesali-infra

Koska pilvipalvelu pyörii palveluntarjoajan konesalissa, ei fyysisen konesali-infran suunnitteluun, hankintoihin, asennuksiin ja ylläpitoon tarvitse varata omia resursseja. Ne on hinnoiteltu pilvipalvelun kustannuksiin.

Palveluntarjoaja on tehnyt laskelmat, joiden mukaan kustannukset on jyvitetty eri palveluille. Asiakkaan ei tarvitse miettiä esimerkiksi konesalien kokoa, mahdollista kapasiteettia, investointeja sähkönsyöttöön tai jäähdytykseen.


Henkilöstökustannukset

Jos koko konesali on pilvessä, ympäristön pyörittämiseen tarvittava henkilöstömäärä on huomattavasti pienempi kuin perinteisessä konesalissa.

Kun varsinaisia virtuaalikoneita otetaan käyttöön, tapahtuu käyttöönotto välittömästi, koska palvelinten provisiointi on automaattista.

Etu perinteiseen konesaliin on siinä, että isokaan ympäristö ei vaadi fyysiseen konesali-infraan liittyvää pohdintaa, asennuksia tai ylläpitoa. Myöskään laitteistojen uudistamiseen ei tarvitse uhrata oman henkilökunnan aikaa.

Siinä vaiheessa, kun asennukset saadaan automatisoitua, myös pilviympäristön operointi muuttuu edullisemmaksi verrattuna perinteistä mallia, jossa moni asia tapahtuu edelleen manuaalisesti.


Luku 8: Pilvipalvelut, mahdollisuuksia säästää kustannuksissa


Tässä luvussa käsittelen tapoja, joiden avulla pilvipalvelujen avulla voidaan säästää kustannuksissa.

Käsittelen tässä luvussa kolmea tapaa:

  • Auto scaling
  • Koneiden sammuttaminen
  • PaaS- ja SaaS -palvelujen käyttö


Auto Scaling

Auto scaling tarkoittaa ympäristön rakentamista sellaiseksi, että kuorman ylittäessä tietyt kynnysarvot, järjestelmä käynnistää automaattisesti uusia noodeja (tässä tapauksessa palvelimia), jotka liittyvät klusteriin, jossa sovellusta ajetaan.

Kun kuorma taas laskee ennalta määritetyn kynnysarvon alapuolelle, järjestelmä alkaa sammuttamaan palvelimia. Toiminnallisuuden ansiosta palvelua ei tarvitse mitoittaa huippukuorman perusteella, vaan se voidaan mitoittaa normaalin käytön mukaan.

Auto scaling mahdollistaa pienet instanssit, joita nostetaan pystyyn tarpeen mukaan. Ongelmaksi voi tosin muodostua se, että sovelluksen pitää tukea tätä. Läheskään kaikki sovellukset eivät osaa toimia klusterissa tai varsinkaan klusterissa, jossa noodien määrä vaihtelee.


Koneiden sammuttaminen

Koska käytettäessä pay as you go -mallinen pilvipalvelussa jokainen käytetty minuutti tai tunti maksaa, voi olla houkuttelevaa ajaa vähän käytettyjä palveluita alas aikoina, jolloin niitä ei tarvita.

Tällaiseen järjestelmien sammutteluun ja käynnistelyyn ei yleensä ole mitään tarvetta omassa konesalissa, jossa siitä ei synny säästöjä. Pilvessä järjestely voi olla varsin kannattavaa.

Sammuttelun ja käynnistelyn voi automatisoida, jonka vuoksi tämä säästökikka ei sido kenenkään työaikaa.


Paas- ja SaaS -palvelujen käyttö

Tähän mennessä olemme verranneet virtuaalikoneen kustannuksia perinteisessä konesalissa ja pilvessä. Virtuaalikone kuitenkin tuo mukanaan käyttöjärjestelmän ylläpitotyön ja ilon asentaa palvelimelle tarvittavat palvelinohjelmistot. Ja kun palvelinohjelmat, esim. SQL-palvelu on asennettu, se vaatii ylläpitoa.

Kustannusmielessä voi olla järkevämpää ottaa pilvestä käyttöön pidemmälle jalostettuja palveluita, jolloin oman työn osuus pienenee. Jos esimerkiksi tarvitaan SQL-klusteria, ei sen toteutukseen pilvessä tarvita kahta palvelinta, jotka konfiguroidaan toimimaan SQL-klusterina.

Pilvessä voidaan ottaa käyttöön SQL-palvelu, joka sisältää käyttöjärjestelmät, ja niiden ylläpidon, klusteroinnin, SQL-lisenssit ja SQL-palvelun asennuksen ja ylläpidon.

Hinta voi olla ensi silmäyksellä kalliimpi kuin omasta konesalista tuotettuna, mutta kun otetaan huomioon palvelun pystytyksen ja ylläpidon viemä aika, hintaero voi olla mitätön. Vaikka emme käsittelekään tässä artikkelissa pilven ja konesalien muita eroja, on hyvä muistaa, että aika on rahaa.

Säästynyt aika voidaan käyttää johonkin sellaiseen, joka tuo aidompaa lisäarvoa organisaatiolle.



Luku 9: Kumpi tulee edullisemmaksi – pilvi vai perinteinen konesali?


Kumpi sitten tulee edullisemmaksi – pilvi vai perinteinen konesali?

Kysymys on vaikea, eikä siihen ole mitään yksiselitteistä vastausta.

Yritän vetää tässä luvussa yhteen joitakin havaintojani ja tämän artikkelin oppeja.


Miksi pilvipalvelu maksaa enemmän kuin perinteisen konesalin palvelu?

Miksi pilvipalvelun sanotaan yleensä olevan perinteistä konesalia kalliimpi? Yksi vastaus liittyy tietysti siihen, että pilvipalvelu yleensä on kalliimpi kuin perinteinen konesali. Asia ei kuitenkaan ole niin yksinkertainen.


Ihmiset eivät tyypillisesti osaa laskea kustannuksia

Kun kahta aivan eri tyyppistä asiaa verrataan keskenään, ihmiset eivät yleensä osaa verrata todellisia kustannuksia. Hyvä esimerkki tästä on omakotiasumisen vertaaminen kerrostalossa asumiseen. Moni omakotitalossa asuva sanoo, että asuminen omakotitalossa on hyvin halpaa.

Omakotiasujat usein kauhistelevat kerrostaloasumisen kallita vastikkeita. He kertovat, kuinka heidän omassa talossa asuminen on niin ja niin halpaa. Kun heiltä kysyy, mitä omakotiasuminen maksaa, he luettelevat vain lämmityksen ja vakuutuksen kustannukset. 

Jos omakotitalossa asujan luettelemaa muutamaa kulua verrataan kerrostalon yhtiövastikkeeseen, on selvää, että kerrostaloasuminen vaikuttaa kalliilta. Oikeasti kerrostalon vastikkeella kuitenkin katetaan paljon kuluja, joita moni omakotitalossa asuva ei tule ajatelleeksi.

Omakotitalo vaatii myös paljon ylläpitoa ja korjauksia. Moni ei laske näitä korjauksia kuluiksi tai ei edes tee niitä ja päästää näin talonsa rapistumaan. On selvää, että juoksevia kuluja seuratessa asuminen vaikuttaa halvalta, mutta miten käy talon arvolle?

Jos asuntojen hinnat nousevat, talon rapistumisen vaikutukset eivät käy niin selvästi ilmi kuin jos sille saisi selkeän hintalapun. Todellisuudessa talon ylläpito nielee yllättävän paljon rahaa, ja se kaikki pitäisi laskea asumisen kustannuksiin mukaan. Samoin pitäisi laskea asunnon vanhenemisen aiheuttama arvon lasku.


Omistusasuminen vastaan vuokralla asuminen

Pilvipalvelun ja perinteisen konesalin välistä eroa havainnollistaa hyvin omistusasunnossa asumisen vertaaminen vuokralla asumiseen. Moni suomalainen on edelleen sitä mieltä, että omistusasuminen on ainoa oikea vaihtoehto. He kuitenkin unohtavat omistusasunnossa asumiseen liittyvät ns. piilokulut.

Yhtiövastike voi olla paljon halvempi kuin vuokra. Yhtiövastikse ei kuitenkaan sisällä asunnon rahoituskuluja, arvonlaskukuluja eikä vaihtoehtoiskustannusta. Vuokralla asuminen ei sido yhtään pääomia.

Vuokralla asuva voi päättää sijoittaa koko asunnon vaatiman pääoman esim. osakkeisiin. Vuokralla asuva saa näin tuottoa pääomalleen. Asunnon omistaja taas sitoo pääomansa asuntoon, eikä saa siitä yhtään pääomatuloja.

Asunnon omistaja kantaa koko ajan riskiä siitä, että asunnolle tai taloyhtiölle käy jotain ja asuntoon joudutaan sijoittamaan lisää rahaa. Vuokralla asujan ei tarvitse miettiä tällaista. Jos asunto ei miellytä, vuokralainen vaihtaa tyytyväisenä asuntoa.

On luonnollista, että asumisessa ihmiset tekevät tunteisiin perustuvia ratkaisuita. Asunnon omistaminen voi luoda turvallisuutta ja pysyvyyttä, jota elämältä halutaan. Omaa asuntoa voi remontoida haluamakseen. Moni ei sen vuoksi pidä omaa asuntoa sijoituksena, eikä sitä ehkä kannatakaan pitää. 

Keskustelu pilvipalvelun ja perinteisen konesalin välillä muistuttaa erehdyttävästi keskustelua omistusasumisen ja vuokra-asumisen välillä. Aivan kuten ihmiset eivät osaa laskea omistusasumisen kaikkia kustannuksia, harva osaa laskea oman konesalin kaikki kustannukset.

Aivan kuten omistusasumisen ja vuokralla asumisen kannattavuus riippuu perheen tilanteesta, samoin perinteisen konesalin ja pilvipalvelun kannattavuus riippuu organisaation tilanteesta.

Tarkastellaan siis muutamaa erilaista tilannetta, joissa organisaation tilanne voisi ohjata ratkaisua.


Tilanne 1: Olemassa oleva oma konesali



Jos organisaatiolla on olemassa oleva konesali, jonka fyysiseen infraan on investoitu paljon, pilvipalveluista tuskin saa halvempia, koska pilvessä maksetaan uudesta konesali-infrasta ja omassa konesalissa voi olla paljon kuolletettuja investointeja, jonka vuoksi palvelutuotanto perinteisessä konesalissa on todennäköisesti halvempaa.

Tilanne kuitenkin muuttuu siinä vaiheessa, jos konesali-infraa pitää alkaa päivittämään. Tällöin voi olla houkuttelevampaa siirtää palveluita pilveen.

Ongelmaksi muodostuukin usein osaaminen tai lähinnä sen puute. Pilviympäristössä toimiminen on aika lailla erilaista kuin perinteisen, käsin kosketeltavan konesalin pyörittäminen. Oppiminen vie aikaa, ja tämän vuoksi siirtyminen pilviympäristöön pitäisi aloittaa hyvissä ajoin.


Tilanne 2: Uusi organisaatio – ei omaa IT-infraa

Mikäli yritys tai julkinen organisaatio on vasta perustettu, ei sisällä välttämättä ole vanhaa infraa riippakivenä. Tällöin on usein kustannustehokkaampaa ostaa infra palveluna. Toki pilvipalveluiden lisäksi on mahdollista valita perinteinen palvelinulkoistus. En käsittele sitä tässä yhteydessä, vaan keskityn tarkoituksella vertaamaan perinteistä konesalia ja pilveä keskenään.

Yksi merkittävä kustannuksiin liittyvä asia, jossa pilvi on paljon helpompi kuin perinteinen konesali, on palvelujen kustannusten jyvittäminen niiden käyttäjille.

Vaikka palvelutuotanto voi olla hieman halvempaa perinteisessä ympäristössä, sen todellisten kustannusten selvittäminen on yleensä erittäin vaikeaa tai jopa mahdotonta.

Pilvipalveluista saa kuitenkin tarkan hinnan, jonka palvelu maksaa. Vaikka hinta voi olla hieman perinteistä korkeampi, konkreettinen hinta on paljon helpompi laskuttaa mahdollisilta asiakasorganisaatioilta.

Tämän vuoksi olen nähnyt, että moni esimerkiksi julkisen puolen toimija valitsee mieluummin selkeästi hinnoiteltuja pilvipalveluja, kuin omasta konesalista tuotetun ”köntän”, jonka kustannuksista kukaan ei ymmärrä.


Tilanne 3: Sovelluksia modernisoiva julkishallinnon organisaatio

Otin tarkoituksella kolmanneksi esimerkiksi julkishallinnon organisaation, joka pyrkii modernisoimaan IT-infraansa. Julkishallinto pystyy hankkimaan lisenssinsä huomattavasti yksityispuolta edullisemmin. Tämän vuoksi se voi saada merkittävää etua varatuista instansseista, joihin se tuo omat lisenssinsä.

Tämä voi houkutella siirtämään kuormia pilveen ja pienentää omassa konesalissa pyörivien palvelinten määrää. Koska pilvipalvelut kuitenkin maksavat, houkuttelee se edelleen miettimään, mitä palveluita halutaan jatkossakin käyttää.

Näennäisesti ilmaiset palvelut, joita on voitu pyörittää vuosia omissa saleissa, saavat pilvessä selkeän hintalapun. Tämän hintalapun avulla voidaan keskustella sisäisesti, onko joku nimenomainen palvelu hintansa väärti vai ei.


Loppusanat


Jos olet jaksanut lukea artikkelin loppuun, on varmasti käynyt selväksi, että perinteisessä konesalissa investoinnit ovat etupainotteisia. Kustannustekijöitä on paljon, ja niiden jyvittäminen yksittäiselle virtuaalipalvelimelle on haastava tehtävä.

Perinteiseen konesaliin liittyy paljon kiinteitä kustannuksia, joista ei päästä eroon, vaikka palvelinten lukumäärää vähennetään. Tämä ei houkuttele karsimaan sovelluksia tai modernisoimaan infraa.

Julkisessa pilvessä taas ei ole juurikaan etupainotteisia investointeja. Koska ilmaista lounasta ei ole tässäkään asiassa, käyttö maksaa yleensä enemmän kuin omassa konesalissa ajettava palvelu.

Tilanne kuitenkin elää, ja on todennäköistä, että julkisen pilven hinnat laskevat edelleen, kun palvelujen käyttö ja kilpailu lisääntyvät. On kuitenkin hyvä muistaa, että palvelut voivat myös kallistua.

Mielestäni pilveä ja perinteistä konesalia ei kannata verrata keskenään ainoastaan kustannusten näkökulmasta. Kun mukana on useita eri näkökohtia, todennäköisesti jokainen organisaatio voi löytää itselleen sopivimman vaihtoehdon.

Tulen julkaisemaan artikkelisarjaan liittyen vähintään yhden kirjoituksen, jossa käsittelen pilvipalveluiden ja konesalipalveluiden teknisiä eroja, osaamiskysymyksiä, tietoturvaa ja muita näkökulmia, jotka vaikuttavat päätöksen tekoon.

Tilaa uutiskirjeeni, niin saat tiedon uusimmista artikkeleista heti niiden ilmestyttyä.

Tuntuuko siltä, että teidän IT-ympäristö ja liiketoiminnan tavoitteet eivät ihan kohtaa?

Ei hätää. Aloita IT:n liiketoimintalähtöinen kehittäminen lataamalla laatimani IT-strategiaopas.

IT-strategia opas

Tilaa ILMAINEN opas

IT-strategian laatimiseksi

Tilaan ilmaisen oppaan, jossa kerrotaan, miten voin laatia liiketoimintalähtöisen IT-strategian.

Tilaa uutiskirjeeni

Saat tiedon uusista artikkeleista suoraan sähköpostiisi.

Annan luvan tallentaa tietoni ja hyväksyn tietosuojakäytännön.