fbpx

Voisiko oman konesalin siirtää pilveen?

Oletko miettinyt, voisiko koko nykyisen konesalin vain kylmästi siirtää pilveen?

Käsittelen tässä kirjoituksessa juuri sitä: mitä konesalin korvaaminen pilvipalveluilla oikein tarkoittaa?

Saat kirjoituksessa vastaukset mm. seuraaviin kysymyksiin:

Pilvi konesali pilvistrategia

- Mitä hyötyä konesalin siirrosta pilveen on?

- Mitä ongelmia palvelimien siirtämisestä pilveen voi seurata?

- Mitä ottaa huomioon, jos suunnittelee palvelinten siirtoa pilveen?

Koska koko konesalin siirtäminen pilveen on laaja aihe, käydään aluksi läpi, mitä tässä yhteydessä tarkoitan konesalin siirtämisellä pilveen.

Mitä konesalin siirtäminen pilveen tarkoittaa?

Kun puhun tässä kirjoituksessa konesalin siirtämisestä pilveen, keskityn palvelinten siirtämiseen pilveen sellaisenaan. Puhun siis palvelinten lift and shift -siirrosta pilveen, koska juuri se tulee ensimmäisenä mieleen, kun puhutaan konesalin siirtämisellä pilveen.

Termi “lift and shift” on syntynyt kuvaamaan palvelinten siirtoa perinteisestä konesalista julkiseen pilveen, esimerkiksi Azureen, AWS:ään tai Google Cloudiin.

Lift and shift -siirrossa palvelimet migroidaan sellaisenaan virtuaalialustalta pilvitarjoajan Infrastructure-as-a-service (IaaS)-palvelun alustoille.

Tällaista siirtoa voisi verrata siihen, että siirretään varastosta toiseen tavaraa. Nostetaan siirrettävät lavat trukilla autoon ja ajetaan tavara uuteen varastoon, jossa ne nostetaan omalle varastopaikalleen.

Mitä palvelimien lift and shift -siirto pilveen tarkoittaa?

Palvelimien lift and shift -siirto pilveen tarkoittaa aiemmin perinteisessä konesalissa olleen usein virtualisoidun palvelimen siirtämistä pilveen sellaisenaan. Lift and shift -siirrolla viitataan usein kokonaisten virtuaalipalvelinten ajamiseen pilvessä.

Siirron yhteydessä itse siirrettävään palvelimeen ei tehdä mitään muutoksia. Kun palvelimia siirretään pilveen, ne siirretään omasta konesalista pilvipalvelun tarjoajan virtuaalialustalle ilman, että palvelimen sisältöön varsinaisesti kosketaan.

Kyse on siis hyvin pitkälle oman konesalin korvaamisesta pilvipalvelulla. Koska pilvi tarjoaa kuitenkin paljon muitakin vaihtoehtoja työkuormien ajamiseen, saatat miettiä, miksi joku haluaisi siirtää kaikki palvelimensa pilveen. Käsitellään siis seuraavaksi sitä.

Mitä hyötyä on palvelinten siirrosta pilveen?

Hyvin usein pilviasiantuntijat väheksyvät lift and shift -siirtoa etenemisvaihtoehtona. Heidän mielestänsä silloin ei saada pilven hyötyjä täysin käyttöön. Se pitää tietysti paikkansa, mutta asia ei ole niin yksinkertainen.

Palvelinten siirtäminen perinteisestä konesalista pilveen voi tuoda monia hyötyjä. Tässä on joitakin niistä:

  • Palvelinten siirto pilveen on nopea ja kustannustehokas tapa toteuttaa pilvimigraatio. Palvelinten siirtäminen pilveen voi olla nopeaa eikä se vaadi yhtä paljon asiantuntijaresursseja kuin pilvivaihtoehdot, joissa kosketaan sovellusten rakenteeseen.
  • Palvelinten siirto pilveen ei vaadi muutoksia sovelluksiin. Kun palvelimia siirretään pilveen, ei sovelluksiin tarvitse koskea. Tämä voi olla monelle organisaatiolle kynnyskysymys. Jos halutaan saada hyötyjä pilvestä ilman, että panostetaan sovellusten muokkaamiseen, lift and shift -siirto on oikein varteenotettava vaihtoehto.
  • Halutaan eroon omaan konesaliin liittyvästä vaivasta. Konesali ei pysy ajanmukaisena itsestään. Konesalissa on paljon sen infraan liittyviä kohteita, joiden ylläpito ja uusiminen on kallista ja työlästä. Näitä ovat esim. sähkönsyöttöön, akustoihin, jäähdytykseen ja fyysiseen turvallisuuteen liittyvät investoinnit. Siirtämällä palvelimet pilveen vältetään investoinnit näihin kohteisiin.
  • Siirtämällä palvelimet pilveen vältetään vanhentuneiden palvelinten uusiminen. Joka kerta kun palvelimia pitää uusia, IT-päällikkö joutuu miettimään, mitä tehdä: hankkiako taas uudet palvelimet, ulkoistaako palvelinympäristö palveluntarjoajan konesaliin vai siirtääkö ne suoraan pilveen. Monesti pilvi on kilpailukykyinen vaihtoehto.
  • Halutaan siirtää kustannukset CapExista OpExiin. Tämä on sukua edelliselle kohdalle, mutta asiaa tarkastellaan nyt talouden näkökulmasta. Toki toinen vaihtoehto OpEx-siirtymälle on ulkoistaa omat palvelimet jollekin konesalitarjoajalle. Pilvi voi kuitenkin tuottaa tähän verrattuna muita etuja, jonka vuoksi pilvisiirtymän muut edut ajavat perinteisen ulkoistetun konesalin ohi. 
  • Halutaan nopeuttaa uusien palvelujen käyttöönottoa. Koska pilvestä löytyy palvelinkapasiteettiä heti käyttöönotettavaksi, voi lift and shift -siirrolla nopeuttaa oman IT-ympäristön kehitystä. Vaikka konesalipalveluja tarjoavalla suomalaisella toimijalla olisi vapaata kapasiteettia jaetussa ympäristössään, virtuaalipalvelinten pystytys on usein edelleen käsityötä, kun pilvessä palvelin voidaan ottaa käyttöön heti tilauksen yhteydessä. 
  • Palvelinten siirto pilveen voi tuoda kustannussäästöjä. Parhaimmillaan palvelinten siirtäminen pilveen voi tuoda kustannussäästöjä verrattuna muihin vaihtoehtoihin. 
  • Palvelinten siirtäminen pilveen voi parantaa ympäristön tietoturvaa. Siirtämällä palvelimia omasta konesalista pilveen saadaan käyttöön pilven tietoturvamekanismeja. Tällaisia ovat esim. kaksivaiheinen käyttäjän tunnistus (MFA), admin-tilien parempi suojaus, pilven tietoturvan monitorointipalvelut ja ohjelmistopohjaiset verkot (Software-defined-networking eli SDN). Pilven avulla voidaan siis päästä parempaan tietoturvaan, mitä omassa konesalissa on mahdollista.

Kannattaako palvelinten lift and shift -siirto?

Palvelinten siirtäminen pilveen sellaisenaan tarjoaa nopean tavan ottaa käyttöön monia pilven tuomia hyötyjä. Parhaimmillaan se kuitenkin toimii ensiaskeleena, joka tarjoaa pilven hyötyjä ja antaa aikaa seuraavien pilviaskeleiden ottamiselle.

Palvelinten siirtäminen pilveen sellaisenaan tarjoaa siis monia hyötyjä, jotka varmasti kiinnostavat jokaista organisaatiota. Mikseivät kaikki sitten siirrä palvelimiaan suoraan pilveen?

Lue eteenpäin, niin saat tietää, mitä ongelmia lift and shift -siirrosta helposti seuraa?

Mitä ongelmia konesalin siirtämisestä pilveen voi seurata?

Tässä osuudessa käsittelen sitä, mitä ongelmia konesalin siirtämisestä pilveen helposti seuraa, jos palvelimia siirretään pilveen sellaisenaan.

Palvelinten siirtäminen pilveen tuo selkeästi hyötyjä perinteiseen konesaliin verrattuna.

Konesali pilvessä voi aiheuttaa ongelmia

Tämän pilvistrategian ongelma liittyy vahvasti siihen, että muutos perinteiseen konesaliin verrattuna jää lopulta varsin pieneksi verrattuna muihin pilven käyttötapoihin.

Jos tyydytään siihen, että palvelimet vain siirretään pilveen ja ympäristön ylläpitoa jatketaan niin kuin mikään ei olisi muuttunut, ajaudutaan ennen pitkää ongelmiin.

Jos tyydytään siihen, että palvelimet vain siirretään pilveen ja ympäristön ylläpitoa jatketaan niin kuin mikään ei olisi muuttunut, mikään ei lopulta juurikaan muutu. Ajan myötä tämä johtaa ongelmiin.

Lift and shift -siirron jälkeisten toimenpiteiden nopeus ratkaisee sen, miten paljon hyötyä vs. uusia ongelmia siirrosta seuraa. Mistä oikein on kyse?

Jatka lukemista, niin saat tietää, miksi on näin.

Kello alkaa tikittämään

Kun palvelimet siirretään pilveen, alkaa kello käymään. Jos mitään muita muutoksia ei tehdä, aika toimii tästä lähtien IT-ympäristöä vastaan. Piirsin asian havainnollistamiseksi kuvan, joka selittää tätä problematiikkaa.

Lift and shift -strategia
Lift and Shift -siirron hyödyt alkavat laskea, kun aika kuluu.

Alussa pilvipalvelusta tuntuu olevan paljon hyötyä. Moderni pilvi rajattomine kapasiteetteineen voi tuntua hyvältä ratkaisulta jähmeän oman konesalin jälkeen.

Siirron jälkeen kello alkaa kuitenkin tikittämään. Olisi aika käynnistää seuraava muutos. Jos tätä ei tehdä, ajaudutaan ongelmiin.

Kun palvelimet siirretään sellaisenaan pilveen, ympäristön ylläpito tapahtuu yleensä hyvin samalla tavalla kuin omassa konesalissa olleen ympäristönkin. Hallinta perustuu siis manuaalisiin prosesseihin eli ylläpitäjät tekevät ylläpitotoimia käsin.

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.

 

 

Jos ylläpitotapoja ei kehitetä eikä ihmisiä kouluteta, kaikki jatkuu niin kuin aiemminkin. Jos pilviympäristön käyttöä ei pidettä kurissa selkeillä hallintakäytännöillä, alkaa pilviympäristöjen helppo pystyttäminen kääntyä itseään vastaan.

Koska verkkoja ja palvelimia on helppo pystyttää, muodostuu pilviympäristöstä helposti kaoottinen paikka. Erilaisia testi- ja kehitysympäristöjä alkaa nousemaan sinne tänne.

Jos ympäristön käyttöä ei ole dokumentoida mitenkään, hetken päästä kukaan ei oikein tiedä, mihin mitäkin palvelinta niitä alun perin tarvittiin, mitkä ympäristöt ovat kurantteja mitkä saisi jo poistaa.

Vähitellen rämettyvästä palvelinympäristöstä, joka tosin on modernissa pilvessä, alkaa muodostumaan uusi legacy, joka hidastaa kehitystä.

Vähitellen rämettyvästä palvelinympäristöstä, joka tosin on modernissa pilvessä, alkaa muodostumaan uusi legacy, joka hidastaa kehitystä.

Viimeistään tässä vaiheessa yrityksen pilviosaajat ovat todennäköisesti kypsiä koko touhuun ja alkavat katsella uusia työpaikkoja.

Kun osaajat lähtevät, on organisaatiolla käsissään sekava pilvessä pyörivä palvelinympäristö, jossa mikään ei oikeastaan ole muuttunut parempaan suuntaan.

Jotta näin ei kävisi, pitäisi käynnistää seuraava muutoshanke heti sen jälkeen, kun palvelimet on siirretty pilveen. Mistä on kyse?

Lue eteenpäin, niin saat tietää.

Kun konesali on siirretty pilveen, on aika käynnistää seuraava muutos

Konesalin siirtäminen pilveen on vain välivaihe isommassa muutoksessa.

Konesalin siirtäminen pilveen voi tuoda juuri niitä hyötyjä, mitä lähdettiin tavoittelemaan, mutta hyödyt alkavat pienentyä ja ongelmat kasvamaan, jos kehitys jätetään tähän.

Palvelinten lift and shift -siirron jälkeen on syytä varmistua kolmesta asiasta:

  1. Palvelinten asentamista ja ylläpitoa aletaan automatisoimaan. Sen sijaan että palvelimia pystytetään käsin pilvi antaa mahdollisuuden määritellä palvelinten konfiguraatiot etukäteen templateilla. Näiden palvelinten konfiguraatiot kuvaavien tiedostojen avulla voidaan palvelimista saada nopeasti saman näköisiä ilman inhimillisiä virhekonfiguraatioita.
  1. Pilven hallintamalli on vahva. Jotta voidaan estää pilven rämettyminen, pitää pilveen pystytettäviä palveluita rakentaa hallitusti. Yksinkertaisesti on kyse siitä, kuka saa tehdä ja mitä saa tehdä sekä miten asioita saa tehdä. Toki hallintamalli pitäisi rakentaa jo ennen tätä pilvisiirtymää, mutta viimeistään siinä vaiheessa, kun palvelimia on jo siirretty pilveen, on oikeasti syytä keskittyä hallintamallin toteuttamiseen.
  1. Sovellusten roadmapit. Todelliset pilvihyödyt saavutetaan ajamalla sovelluksia perinteisten palvelimien sijaan konteissa, ohjaamalla konesalia Kuberneteksella, hyödyntämällä serverless computing -ympäristöjä, PaaS-palveluita ja muita korkeamman jalostusasteen palveluita. Siksi on tärkeää muodostaa käsitys siitä, miten sovelluksia aletaan modernisoimaan.

Palvelinten siirtäminen pilveen ei siis riitä sellaisenaan. On tärkeää jatkaa muutosta, jotta saavutetaan suurempia hyötyjä.

Jos perinteinen konesali on pilvisiirtymän lähtöpiste, konesalin siirtoa pilveen lift and shift -menetelmällä voidaan pitää ensimmäisenä askeleena pilven hyödyntämisessä.

Seuraava askel voisi olla sovellusten kontittaminen ja pilkkominen mikropalveluiksi. Tähän kokonaisuuteen liittyy IaaS-palvelujen korvaaminen PaaS-palveluilla. Esimerkki tästä voisi olla tietokantojen toteuttaminen tietokantapalvelulla sen sijaan, että säilytettäisiin omia palvelimia tietokantojen alustana.

Muutos ei kuitenkaan pääty tähän, koska seuraava pilvisiirtymän askel voisi olla Serverless-ympäristön hyödyntäminen. Tällaisessa ympäristössä ei nimensä mukaan tarvita omia palvelimia, vaan laskentakapasiteettia saadaan käyttöön aina sen mukaan, kun yksittäisiä funktioita tai sovelluksen osia tarvitsee suorittaa.

Seuraava kuva esittää tätä muutosta.

pilviroadmap
Lift and shift -siirto on ensimmäinen askel pilven hyödyntämisessä.

Jos haluat lukea lisää siitä, miten konesalia ja sovelluksia voi edelleen kehittää, tässä lisää aiheeseen liittyviä kirjoituksiani:

Nykyään ollaan siis aika yksimielisiä siitä, että tavallisten palvelinten ajaminen pilvessä ei ole kovin hyödyllistä. Paljon isompia hyötyjä voidaan saavuttaa automatisoimalla ympäristön ylläpitoa ja kehittämällä sovellusarkkitehtuuria.

Mietitkö mitä osaamista konesalin siirtäminen pilveen vaatii? Lue eteenpäin, niin saat vastauksen tähän kysymykseen.

Millaista osaamista konesalin siirtäminen pilveen vaatii?

Tässä osuudessa käsittelen sitä, millaista osaamista konesalin siirtäminen pilveen vaatii. Olen itse tunnistanut ainakin viisi (5) erilaista osaamisaluetta, jotka liittyvät suoraan lift-and-shift -siirtoihin:

  1. Käytettävyystavoitteiden määrittäminen
  2. Pilven SLA:n ymmärtäminen
  3. Tietoliikenne, backupit, valvonta jne.
  4. Infran toteuttaminen koodilla (IaC)
  5. Kustannusten hallinta

Käsitellään seuraavaksi kutakin näistä yksitellen.

Määrittele käytettävyystavoitteet yhdessä liiketoiminnan kanssa

Aina kun uudelle järjestelmälle speksataan infraa ja sopivaa palvelutasoa, olisi syytä määritellä kohdejärjestelmän kriittisyys liiketoiminnalle. Sen voi tehdä helposti vastaamalla kolmeen kysymykseen:

  1. Jos sovellus jostain syystä kaatuu, kauanko se saa olla alhaalla? Vastaus tähän kysymykseen kertoo, kuinka nopeasti sovellus pitää pystyä palauttamaan toimintaan. Kyse on Recovery Time Objectivesta (RTO).
  2. Kuinka paljon dataa saa hävitä, jos sovellus kaatuu? Vastaus tähän kysymykseen kertoo, miten usein sovelluksesta pitää ottaa varmuuskopioita. Kyse on Recovery Point Objectivesta (RPO).
  3. Itse kysyn vielä kolmannen kysymyksen. RTO kertoo tavoitteen toipumiselle, mutta ei sitä, miten kriittinen järjestelmä on liiketoiminnan kannalta. Siksi kysyn, missä vaiheessa yrityksen toiminta voidaan lopettaa, jos tätä järjestelmää ei saada pystyyn. Vastaus kertoo ehdottoman takarajan, johon toipumisessa kaikissa olosuhteissa pitää päästä. Kyse on termistä nimeltään Maximum Tolerable Period of Disruption (MTPD).

Jos haluat lukea lisää näistä termeistä ja siitä, miten niitä käytetään liiketoiminnan jatkuvuussuunnittelussa ja Disaster Recovery -suunnittelussa, voit lukea seuraavia kirjoituksiani:

Tämän harjoituksen jälkeen tiedetään, millaisia katkoja sovellus kestää ja miten hyvin palautumisasiat pitää rakentaa.

Nyt on aika miettiä, millaisella ratkaisulla pilvessä voidaan päästä tähän käytettävyyteen.

Tilaa ILMAINEN opas

IT-strategian laatimiseksi

Tilaa ilmainen opas, jossa kerron, miten voit laatia käytännöllisen ja liiketoimintalähtöisen IT-strategian.

 

 

Ymmärrä pilven SLA

Yksi osaamisalue, joka tulee väkisin vastaan, kun konesalia siirretään pilveen, on pilven SLA:n ymmärtäminen.

Tarkoitan tällä eri palvelukomponenttien SLA:ta. Millaista käytettävyyttä tarjoaja lupaa erilaisille palvelutasoille ja erilaisille kokoonpanoille.

Tähän liittyvät esim. seuraavanlaiset asiat:

  • Miten Availability Setit toimivat? Milloin palveluntarjoaja ajaa ympäristöihin päivityksiä ja boottailee alustapalvelimia? Tällä voi olla iso vaikutus sovelluksessa näkyviin katkoihin. Miten palvelimet sijoitetaan eri availability setteihin?
  • Miten Availability Zonet toimivat? Pitäisikö sovellus toteuttaa kahden tai useamman availability zonen avulla? Miten palvelimet pitää sijoitella, jotta tähän päästään? Saadaanko sovellus tukemaan tällaista kokoonpanoa, jossa palvelimia voikin yhtäkkiä olla useampi?
  • Miten Availability Zone ja Region eroavat toisistaan? Riittääkö sovelluksen pyörittäminen yhden regioonan sisällä hyödyntämällä useampaa availability zonea?

Lisäksi palveluja pilveen siirtävän pitää ymmärtää, missä dataa säilytetään, montako kopiota toimittaja siitä ylläpitää ja pitäisikö data varmuuden vuoksi replikoida vielä jonnekin muualle?

Näiden asioiden päättämiseksi auttaa, jos on käynyt läpi edellisen vaiheen RTOt, RPOt, MTPD:t jne. Ne antavat selkänojaa päätösten tekemiseksi. Toki kustannuksetkin vaikuttavat asiaan samoin kuin sovelluksen arkkitehtuuri, mutta joka tapauksessa päätöksen teko on helpompaa, jos asioita on vaivautunut miettimään etukäteen.

Tietoliikenne ja backupit

Ennen kuin konesali tai sen osia voidaan siirtää pilveen, pitää ratkaista mm. se, miten käyttäjät pääsevät pilvessä pyöriviin palveluihin. Jos omaa konesalia jatketaan pilveen, pitää ratkaista konesalien liittäminen toisiinsa.

On tärkeää piirtää auki, millainen arkkitehtuurista on rakentumassa tietoliikenteen kannalta.

Samoin varmuuskopioinnin toteutus, palvelinten valvonta ja muut aivan perinteiseen konesaliin liittyvät asiat vaativat pohtimista. Ei pilvi niiden tarvetta poista. Toteutustapa voi muuttua, mutta asia itsessään ei poistu mihinkään.

Infrastructure-as-Code (IaC)

Olisi äärimmäisen hyödyllistä pyrkiä eroon käsin asennettavista palvelimista ja korvata tekeminen templateilla ja automaatiolla.

Siksi jonkun pitäisi opetella palvelinten nostaminen pystyyn koodilla. Tästä tulee olemaan paljon hyötyä ympäristön kehittämisessä. Tästä on hyötyä asioiden nopeutumisen kautta, laatu paranee, kun palvelinten konfiguraatiot vastaavat toisiaan, tietoturva paranee, kun erikoistilanteissa voidaan nostaa ympäristö pystyyn hyvin nopeasti koodin avulla.

IaC tuo paljon hyötyjä, joilla aletaan pääsemään käsiksi pilven potentiaaliin IT:n kehittämisessä. Siksi asia vaatii opettelua, jos se ei vielä ole tuttua.

Kustannusten hallinta

Pilvipalvelut voivat tuoda säästöjä, mutta ne voivat myös nostaa kustannuksia, jos asiakas ei ole tarkkana.

Siksi jokainen konesalia tai palvelimia pilveen siirtävä joutuu pohtimaan, miten huolehditaan siitä, että kustannukset eivät karkaa. En käsittele pilven kustannusten hallintaa tässä kirjoituksessa, koska tulen käsittelemään aihetta enemmän tulevaisuudessa.

Jos haluat saada ilmoituksen tämän kirjoituksen julkaisemisesta, tilaa uutiskirjeeni, niin saat sähköpostiin ilmoituksen, kun julkaisen tämän kirjoituksen.

Tässä vielä kuva, joka kokoaa osaamistarpeita, jos aikoo siirtää konesalin pilveen.

Mitä pitää osata jos vie konesalin pilveen
5 osaamisaluetta, joita tarvitaan, jos aikoo viedä konesalin pilveen.

Tarkemmat lukijat varmasti huomasivat, että en käsitellyt tässä kaikkia mahdollisia osa-alueita, joita pitää ottaa haltuun, jos palvelimiansa meinaa siirtää pilveen. Sen sijaan käsittelin joitakin asioita, jotka tulevat vastaan, vaikka ei tekisi mitään muuta, kuin siirtää palvelimet pilveen sellaisenaan.

Oletetaan, että osaamispuoli on hallussa tai ainakin on selvää, mitä aletaan ottamaan haltuun. Käsitellään seuraavaksi lyhyesti sitä, mitä pitäisi ottaa huomioon, jos suunnittelee palvelinten siirtoa pilveen.

Mitä ottaa huomioon, jos suunnittelee konesalin siirtoa pilveen?

Käsitellään lopuksi vielä hieman sitä, mitä kannattaa ottaa huomioon, jos suunnittelee konesalin siirtoa pilveen.

Pitäisin yhtenä keskeisimpänä asiana sitä, että muodostaa näkemyksen siitä, mitä aikoo pilvellä tehdä ja mitä se vaatii organisaatiolta. Asioita kannattaa miettiä vähän pelkkää palvelimien vientiä pilveen pidemmälle.

On hyvä käydä läpi oma sovelluslistaus ja muodostaa käsitys siitä, mikä on minkäkin sovelluksen kehityspolku: olisiko se hyvä ostaa jatkossa SaaS-palveluna vai pitäisikö se toteuttaa pilvessä jotenkin muuten. Onko sovellus potentiaalinen kandidaatti sijoitettavaksi esim. kontteihin?

Varmasti kaikkia kiinnostaa se, paljonko samanlainen ympäristö maksaisi pilvessä. Siksi kannattaa ajaa omassa ympäristössä pilvipalvelun tarjoajan migraatioprosessiin liittyvä kartoitus, jonka avulla saa aika hyvän arvion mahdollisen pilviympäristön kustannuksista.

Lisäksi olisi hyvä suunnitella pilven hallintamalli ja governance-käytännöt valmiiksi, jotta pilvi ei pääse rämettymään.

Tässä vielä yhteenveto tiivistettynä.

Ota huomioon nämä 4 asiaa, kun siirrät konesalia pilveen

  1. Laadi pilvistrategia, joka ottaa kantaa siihen, miten voisitte hyötyä pilvestä
  2. Tee sovelluksille roadmap
  3. Arvioi pilviympäristön kustannukset
  4. Laadi pilvelle hallintamalli

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

Onko konesalin siirto pilveen hyvä idea? Se selkeästi riippuu aika monesta asiasta. Joitakin järkeviä skenaarioita palvelinten lift and shift -siirrolle ovat:

  • Kustannusvertailun perusteella saisit pilvisiirtymästä selkeitä kustannushyötyjä verrattuna ulkoistettuun kapasiteettipalveluun tai omasta konesalista tuotettavaan palveluun, mutta et kuitenkaan ole vielä valmis muuttamaan sovellusten arkkitehtuuria.
  • Sovellukset ovat pääasiassa valmisohjelmistoja, jonka vuoksi et pääse muuttamaan niiden arkkitehtuuria, eikä sopivaa SaaS-palvelua ole tarjolla.
  • Haet parempaa kykyä palautua erilaisista vikatilanteista. Tällöin koko ympäristön tai ainakin DR-ympäristön tuottaminen pilvestä voi olla hyvinkin varteenotettava vaihtoehto.

Todennäköisesti kaikkia omassa konesalissa pyöriviä palvelimia ja sovelluksia ei ole järkevää siirtää pilveen. Sovellusten elinkaari voi olla lähellä loppua tai jokin muu syy tekee siirron kannattamattomaksi. Tällöin tuloksena on hybrid-ympäristö, jossa osa työkuormista pyörii pilvessä ja osa omassa konesalissa. Tämä on varmasti kaikkein tyypillisin skenaario, johon organisaatiot päätyvät.

Palvelinten lift and shift -siirto voi siis olla ihan järkevä idea. Usein se toimii osana isompaa muutosta, jolloin palvelinten siirtäminen sellaisenaan pilveen on vain yksi välivaihe.

Tulen käsittelemään tulevaisuudessa pilvipalveluja monelta kantilta. Jos aihe kiinnostaa, tilaa uutiskirjeeni, niin saat sähköpostiin ilmoituksen aina, kun julkaisen jotain uutta.

Tilaa uutiskirjeeni

Saat tiedon uusista artikkeleista suoraan sähköpostiisi.

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

Vieritä ylös