fbpx

Tunnistatko nämä 7 tilannetta joissa oma konesali on parempi kuin pilvi?

Kumpi valita: oma konesali vai julkipilvi?

Käsittelen tässä kirjoituksessa seitsemää eri tilannetta, joissa oma konesali voi olla järkevämpi kuin julkipilvi.

Kun olet lukenut kirjoituksen, ymmärrät paremmin, missä tilanteissa julkipilvi ei välttämättä ole ykkösvaihtoehto.

Palvelujen siirtäminen pilveen herättää tunteita puolesta ja vastaan.

Oma konesali on parempi

Jotkut ovat sitä mieltä, että pilvi tuo etuja perinteiseen konesaliin verrattuna, mutta toisten mielestä pilveen siirtyminen ei läheskään aina kannata. Oma konesali olisi siis parempi. Hämmentävää eikö totta?

Koska markkinassa on paljon pilvipalveluksi brändättyjä palveluita, jotka saattavat oikeasti olla lähempänä perinteistä konesalipalvelua kuin ”oikeaa” pilveä, käsitellään lyhyesti, mitä tarkoitan julkipilvellä.

Mikä on julkipilvi?

Käytän pilven määritelmänä yhdistelmää kahdesta eri määritelmästä: Yhdysvaltojen hallinnon National Institute of Standards and Technology -organisaation (NIST) pilvipalvelun määritelmästä ja Thomas Erlin Cloud Computing (Concepts, Technology & Architecture) -kirjan määritelmästä.

  • Itsepalvelu (self-service). Pilvipalvelussa 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 käsityötä.
  • Kattavat verkkoliitännät (Ubiquitous network access). Pilvipalvelu on kytketty lähtökohtaisesti internetiin.
  • Resurssipoolit (Resource pooling). Pilvipalvelu perustuu jaettujen resurssipoolien hyödyntämiseen.
  • Joustavuus (Rapid Elasticity). Yksittäisen palvelun kuluttamia resursseja voidaan skaalata reaaliaikaisesti tarpeen mukaan joko kasvattamalla palvelussa mukana olevien noodien määrää tai kokoa.

Olen käsitellyt aidon pilvipalvelun ominaisuuksia tarkemmin kirjoituksessani Näin tunnistat aidon pilvipalvelun.

Kun puhun pilvipalvelusta, sen tulee siis täyttää yllä olevat kriteerit. Tarkoitan julkipilvellä palvelua, jota voi ostaa ensisijaisesti kolmelta isolta pelurilta: Amazon AWS, Microsoft Azure ja Google Cloud.

Tämän lisäksi on paljon palveluntarjoajia, joilta voi ostaa samantyyppistä palvelua. Usein palvelutarjoama on kuitenkin kapeampi tai ominaisuuksissa ei päästä näihin aidon pilvipalvelun kriteerit täyttäviin palveluihin.

Pilven voi toteuttaa hyvin myös omaan konesaliin, jos käytössä on riittävän hyvä nippu ohjelmistoja, jolla kaikki mainitut ominaisuudet toteutetaan.

Tässä kirjoituksessa käsittelen siis tilanteita, joissa voi olla järkevää pysyä poissa näiden kolmen ison palveluntarjoajan palveluista ja toteuttaa palvelut joko privaattipilvenä tai perinteisemänä konesalipalveluna.

1. Asiakkaiden vaatimukset tai regulaatio estää pilvisiirtymän

Julkisessa hallinnossa ja kriittisen infrastruktuurin parissa työskennelleet ovat varmasti törmänneet siihen, että pilvisiirtymä kohtaa suurta vastustusta.

Yksi syy vastustukselle voi olla regulaatio. Useimmiten regulaatio koskee datan sijaintia. Hyvin tyypillisesti data täytyy pitää EU:n sisällä. Se ei sinänsä vielä estä pilvipalvelujen käyttöä.

Vaikka regulaatio ei sinänsä estäisi pilvipalvelujen käyttöä, on hyvinkin mahdollista, että vaatimuksia tulkitaan siten, että siirtymä julkipilven käyttäjäksi ei tunnu realistiselta.

Myös organisaation asiakkaat voivat olla sitä mieltä, että pilvi sisältää aivan liikaa riskejä.

”Meillä on niin tiukasti suojattavaa tietoa, että emme halua pilveen, koska muut voivat päästä tietoihin käsiksi pilvessä.”

Onko tämä validi argumentti? Käsitellään tätä hieman.

Pilvi mahdollistaa korkean tietoturvatason

Pilvipalvelu mahdollistaa hyvin korkean tietoturvatason. Esimerkiksi tietojen salaaminen on hyvin helppoa. Tiedot voidaan salata aina kun niitä siirretään, aina kun tieto on tallennettuna pilveen jne. Palveluntarjoajat tarjoavat salaamiseen ja salausavainten hallintaan monia valmiita rajapintoja ja ratkaisuita.

Ongelmaksi muodostuu enemmän luottamus. Vaikka tekninen ratkaisu olisi kuinka hyvä tahansa, tietoja kuitenkin käsittelee organisaatio tai sen työntekijät, joita asiakas ei ole päässyt itse valitsemaan ja tarkastamaan.

Julkipilvi vaatii aina luottamusta palveluntarjoajaan

Vaikka pilvipalvelu mahdollistaa korkeamman turvatason kuin perinteinen konesalipalvelu, jää palveluun silti komponentti, jonka ylittäminen voi olla vaikeaa: asiakkaan pitää luottaa siihen, että palveluntarjoaja huolehtii tietoturvasta.

Joissain tilanteissa tällaista riskiä ei haluta ottaa. Silloin vaihtoehdoksi jää yksityisen pilvipalvelun (private cloud) rakentaminen omaan tai paremmassa kontrollissa olevan palveluntarjoajan konesaliin.

2. Sovellukset vaativat alleen perinteisen infran

Perinteiset sovellukset ovat hyvin tyypillinen syy jättää pilvipalvelut väliin. Jos yritys ei itse kehitä sovelluksiansa, ei se myöskään pääse modernisoimaan sovelluksien rakennetta.

Perinteisen sovelluksen voi kuitenkin siirtää pilveen sellaisenaan.

Kun palvelimia siirretään pilveen sellaisenaan, puhutaan lift-and-shift-siirrosta. Vaikka palvelininfran voi sinänsä siirtää sellaisenaan pilveen, se ei välttämättä tuo niitä hyötyjä, joita on lähdetty hakemaan.

Perinteinen sovellus - pilvi

Lift-and-shift-siirto on maineeltaan hieman kyseenalainen strategia, koska moni organisaatio on siirtänyt palvelimiaan pilveen ja pettynyt tuloksiin. Infra onkin yhtäkkiä maksanut paljon enemmän kuin aiemmin, mutta mitään varsinaisia hyötyjä ei ole saatu.

Monella ns. tavallisella organisaatiolla ei ole omaa sovelluskehitystä eikä sitä kautta itse tehtyjä sovelluksia, joita modernisoimalla voisi saavuttaa suuria hyötyjä. Silloin voi olla ihan realistista jatkaa on premises -sovellusten osalta aivan perinteisessä konesalissa.

Tämä ei tarkoita, etteikö lift-and-shift-siirto olisi joissain tilanteissa järkevä. Jotta siitä voisi olla hyötyä, pitää organisaation tietää, mitä tekee ja olla valmis panostamaan ylläpitotapojen muutokseen ja palvelinten optimoimiseen.

Jos haluat lukea lisää mahdollisesta lift-and-shift-siirrosta, lue kirjoitukseni Voisiko oman konesalin siirtää pilveen?

3. Latenssivaatimukset vaikeuttavat pilven käyttöä

Lähtökohtaisesti julkipilvi on fyysinen konesali. Googlen Haminan konesalia lukuun ottamatta nämä konesalit sijaitsevat tyypillisesti kauempana kuin oma konesali tai palveluntarjoajan konesali sijaitsi.

Jos konesalin vie riittävän kauaksi käyttäjistä, alkaa käyttäjien ja konesalin välinen matka aiheuttamaan viivettä sovellusten käyttöön.

Pilvi latenssi

Mitä kauempana käyttäjät ovat konesalista, sitä pidempään datapakettien pitää matkata käyttäjältä konesaliin ja takaisin. Tämä aiheuttaa latenssia, joka voi alkaa näkymään käyttökokemuksessa.

Voisiko vain osan sovelluksesta viedä pilveen?

Välillä suositellaan sovelluksen viemistä osittain pilveen. Tämä tarkoittaa usein sitä, että palvelun asiakasrajapinta (front-end) tarjotaan pilvestä. Tietokanta saatetaan kuitenkin pitää jostain syystä omassa konesalissa.

Yksi syy sovelluksen hajauttamiseen voi olla halu pitää tietokanta omassa konesalissa.

Tällaisessa skenaariossa sovelluksen sisäiset latenssit voivat muodostua liian suuriksi. Sovellus voi alkaa toimimaan arvaamattomasti, jos tietokantakyselyt kestävät pidempään kuin sovelluskehittäjä on ottanut sovellusta suunnitellessa huomioon.

On hyvin yleistä, että perinteistä sovellusta ei haluta hajauttaa sekä pilveen että omaan konesaliin.

Jos koko järjestelmää ei kannata jostain syystä viedä pilveen, voi hyvinkin olla, että sisäiset latenssit estävät myös osittaisen viemisen pilveen.

Silloin oma tai palveluntarjoajan konesali on tälle kyseiselle sovellukselle hyvä vaihtoehto.

4. Pilvipalvelu muodostaa arkkitehtuuriin pullonkauloja

Pilvipalvelu voi muodostaa arkkitehtuuriin pullonkauloja. Tämä syy on sukua edelliselle. Palvelun sijoitusta mietittäessä joudutaan aina miettimään sitä, missä muut sovellukset ovat. Syntyvää järjestelmää pitää aina tarkastella kokonaisuutena. Muodostuuko infraan pullonkauloja?

Onko tietoliikenteessä kohteita, jotka hajottavat vikaantuessaan kokonaisuuden? Toisin sanoen: Onko kokonaisuudessa single-point-of-failure-tyyppisiä kohteita?

Kokonaisarkkitehtuuri

Jos käyttäjät ovat internetissä, tällaisia ei todennäköisesti synny, mutta jos käyttäjät ovat tietyissä toimipisteissä ja toimipisteen sisäinen tietoliikenneverkko tai internet-liittymät muodostavat kriittisiä pisteitä, voi se olla jollekin organisaatiolle syy pitäytyä lähempänä olevassa konesalissa.

Pilven puolesta puhujat ovat tietysti sitä mieltä, että kriittiset kohdat pitää kahdentaa. Se ei kuitenkaan ole aina mahdollista tai järkevää kustannusmielessä.

Yksi näkökulma liittyy tietoliikenneyhteyksien katkeamiseen. Entä jos tietoliikenneyhteydet käyttäjäorganisaation ja pilven välillä katkeavat tai ne katkaistaan? Entä jos myös digirajat maiden välillä katkaistaan.

Kyse on aika pitkälti business casesta, jossa vaakakupin toisella puolella ovat pilven hyödyt ja toisella puolella erilaiset vika- tai poikkeustilanteet ja niiden aiheuttamat ongelmat.

Pullonkaulaongelma ei koske ainoastaan pilvipalvelua. Yhtä hyvin omassa konesalissa oleva sovellus voi muodostaa pullonkaulan, jonka pilvi ratkaisisi.  Asiaa pitää siis aina tarkastella kokonaisuutena.

Tilaa ILMAINEN opas

Opas pilvi konesali

Pilvistrategian laatimiseksi

Tilaa ilmainen 32-sivuinen opas, jossa kerron, mitä ottaa huomioon, kun haluat uudistaa IT-ympäristöä pilvipalvelujen avulla.

 

 

5. Tarve päättää päivitysaikatauluista itse

Julkipilvessä on tarjolla palveluntarjoajan päivitysaikataulut. Pilvipalvelujen tarjoaja ei säädä palvelinten käynnistysaikatauluja asiakkaan toiveiden mukaan.

Asiakkaat voivat valita joistakin aikatauluvaihtoehdoista, joiden mukaan palveluntarjoaja voi käynnistellä alustapalvelimia. Tämä voi olla asiakkaalle ongelma.

Jos sovellus on kriittinen eikä se saa olla alhaalla käynnistysten aikana, pitää se tietysti klusteroida.

Pilvi päivitysaikataulu

Jos sovellus klusteroidaan, pitää klusterin muut noodit laittaa palvelimille, joiden käynnistysaikataulut eroavat toisistaan. Näin haluttu määrä klusterin noodeja pysyy päällä, vaikka alustoja päivitetäänkin.

Tämä ei välttämättä ole mikään ongelma, jos sovellus tukee klusterointia.

Entä jos sovellus ei tue klusterointia? Silloin klusterointi pitää tehdä virtuaalipalvelintasolla niin, että alustoja päivitetään eri aikoina.

Palvelinten päivittäminen voi myös vaatia sovellukselta joitain ylläpitotoimia tai ainakin sen varmistamista, että kaikki toimii, kun palvelin nousee bootista. Yhteistyö sovellustoimittajan kanssa voi olla syy, jonka vuoksi päivitysaikataulut halutaan päättää itse.

Jos organisaatio siis haluaa itse päättää, milloin alustapalvelimia päivitetään, voi se olla yksi syy pitää palvelimet ihan perinteisessä konesalissa. Asia ei tietenkään ole aivan näin yksinkertainen, mutta päivitysaikatauluja joutuu miettimään, jos harkitsee sovellusten siirtämistä pilveen.

6. Pilven kustannukset vaikeasti ennakoitavissa

Jokainen pilvipalvelujen kustannuksia vertaillut tai sitä yrittänyt tietää, että palvelun lopulliset kustannukset selviävät vasta sitten, kun palvelu on käytössä.

Asiakkaan ongelmana on siis epäselvä hinnoittelu.

Palveluntarjoaja veloittaa erikseen tietoliikenteestä. Yleensä palveluun sisään tuleva liikenne ei maksa erikseen, mutta ulospäin menevä liikenne maksaa.

Palvelun sisäiset replikoinnit voivat joko kuulua palvelun hintaan tai sitten niistä joutuu maksamaan erikseen. Kustannukset riippuvat usein siitä, tehdäänkö replikointia regioonan (konesalikokonaisuuden) sisällä vai kahden tai useamman regioonan välillä.

Mitä korkeampi jalostusaste palvelussa on, sitä vaikeammaksi kustannusten arviointi voi muuttua. Jos kyseessä on esimerkiksi Serverless Computingia hyödyntävä palvelu, voivat kustannukset nousta hyvinkin suuriksi, jos palvelua käytetään suunniteltua enemmän.

Moni on pettynyt erityisesti lift-and-shift-menetelmällä tehtyjen pilvisiirtymien tulokseen, koska aivan samanlainen palvelu voi maksaa julkipilvessä paljon enemmän kuin perinteisemmässä konesalissa.

Jotta pettymyksiltä voisi välttyä, on tärkeää perehtyä pilven hinnoittelumalleihin, mutta myös optimointimahdollisuuksiin.

Jos haluat lukea lisää optimointimahdollisuuksiin, joita liittyy pilvessä ajettaviin tavallisiin palvelimiin, lue kirjoitukseni Tiedätkö nämä 5 tapaa säästää pilveen siirrettyjen palvelinten kustannuksissa?

Epäselvät kustannukset voivat kuitenkin olla syy, jonka vuoksi perinteisempi konesali on hyvä vaihtoehto tuottaa haluttuja palveluita.

Erityisesti silloin, jos palvelun kuorma on hyvin vakaa eikä vaihtele paljoakaan, voi hyvin olla, että pilvipalvelu ei tuo hyötyä verrattuna perinteiseen toteutukseen.

7. Pilviosaamisen puute

Hyvin normaali syy pysyä perinteisessä konesalissa on osaamisen puute. Voi olla, että itseltä tai tutulta it-kumppanilta puuttuu pilvessä tarvittavaa osaamista.

On inhimillistä, että uudet asiat arveluttavat. Pilvi näyttäytyy monelle hyvin epämääräisenä möykkynä, josta on vaikea saada kiinni.

osaaminen voi olla vanhentunutta

Jos on tottunut tekemään asioita perinteisessä konesalissa, siirtyminen pilvimaailmaan voi tuntua pelottavalta.

Tietty varovaisuus onkin paikallaan, koska esimerkiksi pilven tietoturva vaatii aivan erilaista lähestymistä verrattuna perinteisen maailman tietoturvaan.

Monessa organisaatiossa on yksinkertaisesti niin paljon tekemistä ja niin vähän aikaa perehtyä uusiin asioihin, että pilvi tuntuu vieraalta vaihtoehdolta.

Siksi voi olla, että kun tulee aika hankkia uusia palvelinalustoja tai uudistaa sopimus palveluntarjoajan kanssa, on helpompi vain jatkaa samalla tavalla kuin aiemmin.

Tilaa ILMAINEN opas

Opas pilvi konesali

Pilvistrategian laatimiseksi

Tilaa ilmainen 32-sivuinen opas, jossa kerron, mitä ottaa huomioon, kun haluat uudistaa IT-ympäristöä pilvipalvelujen avulla.

 

 

Yhteenveto

Käsittelin tässä kirjoituksessa seitsemää syytä, miksi oma konesali voi olla parempi ratkaisu kuin julkipilvi. Syitä pysyä erossa pilvipalveluista olisi varmasti muitakin, mutta nämä ovat yleisiä syitä, joiden vuoksi pilvipalvelu ei aina ole se järkevin ratkaisu.

Tuntuivatko syyt tutuilta? Vai tuntuiko siltä, että yksikään syy ei ole riittävän hyvä olla käyttämättä pilven palveluja?

Mitä hyötyjä pilvestä olisi verrattuna perinteiseen konesaliin? Lue kirjoitukseni Pilvipalvelut – 7 syytä miksi pilvestä on hyötyä liiketoiminnalle.

Voit myös ladata ilmaisen oppaan, jossa kerron lisää siitä, miten voit laatia pilvistrategian. Jos haluaisit riippumatonta sparrausapua oikean suunnan löytämiseen, tutustu siihen, miten voin auttaa löytämään oikean suunnan kehitykselle.

Tilaa uutiskirjeeni

Saat tiedon uusista artikkeleista suoraan sähköpostiisi.

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

Vieritä ylös