Onko omassa konesalissa edullisempaa? Alkaako hintojen nousu sitten, kun olen koukussa pilvipalveluihin? Vakoileeko pilvipalveluntarjoaja dataani? Nämä ja kuusi muuta myyttiä saavat NordHeron myytinmurtajat peräänsä!
Useimmille organisaatioille pilvipalvelut ovat vielä varsin uusi asia. Osalla on jo useita pilvikokeiluja takana tai käynnissä, mutta harvassa firmassa pilvipalveluiden päällä pyörii vielä puoltakaan infrastruktuurista. Pilvipalveluiden hyödyntämistä jarruttaa osassa organisaatioita ennen kaikkea ennakkoluulot. Tilannetta kuvaa hyvin aforismi:
Ennakkoluulo on luovuuden suurin este, se estää jo alkuunsa sen mikä on tarkoitus saavuttaa.
Siispä on aika haastaa muutamia yleisimmin vastaan tulleita myyttejä liittyen pilvipalveluihin. Lue läpi ja anna oma tuomiosi; murtuuko myytit vai vahvistuuko ennakkoluulot!
Myytti #1: Omassa konesalissa on edullisempaa
Jotta tätä voisi purkaa auki, pitäisi ensin sopia, mitä verrataan. Pelkästään tarvittavan laitteiston ostohintaako? Entä mikä arvo lasketaan sille, että kapasiteetti on käytettävissä heti ostopäätöksen jälkeen? Tarvitaanko laskentakapasiteettia oikeasti läpi vuorokauden, kuukauden ja vuoden tasaisesti? Otetaanko laskennassa huomioon palvelinten asennus-, ylläpito- ja huoltotyötä? Otetaanko huomioon rahoituskustannukset? Ajatellaanko vain virtuaalikoneiden ajamista, vai otetaanko huomioon myös muut pilvipalveluiden tarjoamat kyvykkyydet?
Käytännössä näitä asioita ei voida useinkaan aukottomasti verrata, ja todistusaineistot todistavat enemmän tekijänsä tarkoitusperistä kuin tasapainotetuista faktoista.
Yksi aihepiiriin liittyvä myytti kuuluu:
Pilvipalveluiden etuna on pay-as-you-go, eli liikkeelle voi lähteä nopeasti ilman investointikustannuksia, mutta pitkässä juoksussa pilvipalveluiden operatiiviset kustannukset ylittävät oman konesalin kustannukset.
Tämä pitääkin varmasti paikkaansa, jos tarkastelu rajoitetaan pilvipalveluiden virtuaalikonekapasiteettiin (esim. AWS:n EC2) ja pelkästään pay-as-you-go-hinnoitteluun (AWS:ssa nimetty On-demand-hinnoitteluksi).
Huomioitava on, että pilvipalveluissa on käytössä myös muunlaisia hinnoitteluja. Fiksu etenemismalli onkin se, että ottaa aluksi käyttöön On-demand-hinnoiteltuja virtuaalikoneita, ja sitten kun kapasiteetin tarve stabiloituu tai tarvevaihtelut alkavat olemaan hyvin ennustettavia, kannattaa kustannuksia alkaa optimoimaan. Optimoinnissa käytettäviä keinoja ovat mm. (termit AWS:stä, vastaavat löytyvät muiltakin pilvitoimijoilta):
- Tarvittavan kapasiteetin skaalaaminen tarpeen mukaan AWS Auto Scaling Grouppeja hyödyntäen
- Kapasiteetin ajastus; kehitys- ja testausympäristöjä tarvitaan usein ns. virka-aikaan mutta harvemmin yöaikaan. Samoin eräajoympäristöjä ei välttämättä tarvita ympärivuorokautisesti.
- AWS:n hukkakapasiteetin ostaminen markkinahintaan, eli AWS Spot Instances -hinnoittelun hyödyntäminen, jonka avulla mahdollisuus saada laskentatehoa jopa 90% edullisempaan hintaan verrattuna On-demand-hintoihin
- AWS:n Savings planien hyödyntäminen eli sitoutuminen ostamaan tietty määrä kapasiteettia 1 tai 3 vuoden sopimuksella - mahdollisuus jopa 72% kustannussäästöön On-demand-hinnoitteluun verrattuna
- Dedikoitujen virtuaalikoneiden ostaminen kerralla pidemmäksi ajaksi AWS Reserved Instances -hinnoittelulla. Alennusprosentti jopa 75% verrattuna On-demand-hinnoitteluun, mikäli kapasiteetti maksetaan sataprosenttisesti ennakkoon.
Pilvipalveluissa on mahdollista saada aikaan merkittäviäkin kustannussäästöjä, mutta ilman työtä ja osaamista säästöt eivät kotiudu. Kun siirryt pilvipalveluihin, siirryt samalla kustannussuunnittelu-maailmasta kustannusten aktiivisen monitoroinnin ja optimoinnin maailmaan.
Myytti #2: Amazon on kilpailijani - en halua käyttää AWS:ää
Tiesitkö, että AWS edustaa vain 13% koko Amazonin liikevaihdosta, mutta jopa 71% Amazonin liikevoitosta (lähde: Geekwire.com 10/2019). AWS syntyi Amazonin ideasta myydä heidän oman verkkokauppa-infran ylijäämäkapasiteettia, mutta vuosien varrella AWS on muodostunut niin merkittäväksi ja kannattavaksi liiketoiminnaksi, että Amazon todennäköisesti ajaisi alas ennemmin verkkokauppansa kuin AWS-liiketoiminnan.
Jos tämä asia askarruttaa, suosittelen miettimään asiaa oman liiketoiminnan näkökulmasta. Kummasta on enemmän hyötyä liiketoiminnallesi/haittaa kilpailijallesi:
- Kieltäydyt olemasta AWS:n asiakas ja näin hankaloitat Amazonin elämää. Eli Amazonilta jää saamatta arviolta muutamia tuhansia tai kymmeniä tuhansia euroja. Huomattakoon että koko Amazonin vuoden 2019 liikevaihto oli 290 miljardia USD ja käyttökate 36,3 miljardia USD. Vertailukohtana Suomen valtion budjetti 2020: 57,6 miljardia EUR.
- Nielaiset kerran ja arvioit, miten voisit hyötyä tilanteesta parhaiten. Todennäköisesti kannattavaa on ottaa kaikki irti nopeasti ja helposti käyttöön otettavista kyvykkyyksistä, joita maailman johtavalla pilvipalveluiden tarjoajalla n. 200 palvelun portfoliostaan löytyy.
Suositeltava strategia on siis ennemmin pitää huoli omasta kilpailukyvystä ja innovaatioiden jalkautusnopeudesta, kuin että keskittyisi Suomen valtiota monenkertaisesti suuremman jättiläisen jarruttamiseen.
Myytti #3: Pilvipalveluntarjoaja vakoilee dataani - en halua tallentaa dataani pilveen
Ei varmaan olisi pitkäjänteisesti järkevää se, että puret kättä joka sinua ruokkii. Vaikea siis ajatella, että pilvipalveluntarjoaja, esimerkiksi Google, luvatta vakoilisi maksavien asiakkaiden sensitiivistä dataa.
Google ja vakoilu on kuitenkin yhdistelmä, jolla on tässä asiayhteydessä merkitystä. Nimittäin 2013 Googlelle kävi ilmi, että Yhdysvaltojen turvallisuuspalvelu NSA oli todennäköisesti murtautunut Googlen dataverkkoon ja ilmeisesti salakuunnellut Googlen dataliikennettä. Googlen johto nosti tästä suuren julkisen metelin ja aiheesta kirjoitettiin tuolloin paljon, esim. The Guardian-lehdessä: https://www.theguardian.com/technology/2013/oct/30/google-reports-nsa-secretly-intercepts-data-links
Tämän seurauksena Google on viime vuosina panostanut konesaleissa käytetyistä piirilevyistä lähtien siihen, että vastaavaa ei pääsisi tapahtumaan uudestaan. Googlen pilvessä data on oletuksena vahvasti salattuna sekä dataa liikuteltaessa (in transit) että tallennusmedioilla (at rest). Eli salaamatonta dataa voi Googlen pilvipalvelussa käsitellä vain, jos pilvipalvelun käyttäjä (hallinnoija/kehittäjä) nimenomaisesti ottaa itse salauksen pois päältä. Datasi on siis varsin hyvin suojattu sekä Googlelta itseltään että mahdollisilta tunkeutujilta.
Loppukaneettina: Pilvipalveluiden suunnittelussa pilvialustasta riippumatta pitää muistaa, että palveluntarjoaja, esim. Google Cloud, on vastuussa pilvipalvelun itsensä tietoturvallisuudesta (security of the cloud) ja asiakas on vastuussa pilvipalvelun päälle rakennettavien sovellusratkaisujen tietoturvallisuudesta (security in the cloud).
Myytti #4: En voi käyttää pilvipalveluja, koska viranomaisvelvoitteet estävät sen
Tähän myyttiin törmää usein ja näkökulmia on paljon. Käsittelen tätä myyttiä sen vuoksi hieman muita pitemmin.
Viranomaisvaatimuksia usein tulkitaan väärin, tai sitten ei olla itse edes perehdytty viranomaisvaatimuksiin, vaan toistetaan muilta kuultua. Ongelman ytimessä on kuitenkin usein se, että viranomaisvaatimukset on laadittu vuosia sitten, ja ne eivät enää välttämättä vastaa tietojenkäsittely-ympäristöämme. Ja tästä syystä säädöksistä voidaan vetää hyvinkin erilaisia tulkintoja.
On toki olemassa vaatimuksia, jotka ehdottomasti edellyttävät että data ja sen ympärille rakennettu logiikka täytyy pyöriä Suomen maaperällä ja jopa omassa kontrollissa olevassa verkossa joka on eristetty muista verkoista. Mutta valtaosassa toimialoista ja vaatimuksista riittää, että organisaation johto tunnistaa mahdolliset riskit toiminnan jatkuvuudelle ja on varautunut näiden riskien varalta. Tällaisia riskejä voivat olla esimerkiksi pilvipalvelutoimijan toiminnan loppuminen tai sopimusten irtisanominen, pitkäkestoiset katkokset pilvitoimijan palvelutuotannossa, massiiviset Internet-yhteyskatkokset jne.
Hyvin yksinkertainen riskienhallintakeino on käyttää pilvipalveluja vain virtualisointialustana, jolloin virtuaalikoneet tai esim. Kubernetes-työkuormat voidaan helpohkosti siirtää konesalista tai pilvialustalta toiselle. Mutta kun tasapainotellaan riskejä, niiden toteutumistodennäköisyyksiä sekä niiden vastakohtana pilvipalveluiden tarjoamia kyvykkyyksiä, on useinkin järkevin vaihtoehto ottaa pilvestä kaikki hyöty irti. Miten tahansa ratkaisusi toteutat, sen elinkaari on kuitenkin vain n. 3-10 vuotta. On siis melko todennäköistä, että palvelu on jo useaan kertaan rakennettu uudelleen erilaisia teknisiä ratkaisuja hyödyntäen, ennen kuin pelätty riski toteutuu.
Toipumissuunnitelma on siltikin hyvä ja jossain tapauksissa täysin välttämätön olla olemassa. Hyvää arkkitehtuurisuunnittelua onkin suunnitella kokonaisuus joustavaksi hybridiratkaisuksi, jossa työkuormia voidaan tarvittaessa siirtää pilven reunalta omaan konesaliin. Pilvipalvelutoimijoilla on jatkuvasti kasvava portfolio yhdistää omia konesaleja pilvipalveluun. Esimerkiksi AWS Direct Connectin avulla yhdistät oman konesalin ja AWS-pilven verkkotasolla, AWS Storage Gateway -tuotteiden avulla pystyt varmuuskopioimaan oman konesalin tallennusmedioilla olevaa dataa AWS-pilveen tai tuoda esimerkiksi AWS:n S3:ssa oleva data organisaation sisäisessä verkossa käytettäväksi.
AWS Outposts on mielenkiintoinen uusi, omaan konesaliin asennettava fyysisen räkki, jossa voit ajaa AWS:n kautta hallinnoitavia palveluita paikallisesti. Näitä palveluja ovat esimerkiksi EC2-virtuaalikoneet & EBS-levyt, S3-bucketit (tulossa 2020), Kubernetes-työkuormat EKS:llä, Amazon RDS -tietokantapalvelut, jne. AWS Outposts -palvelu on AWS:n hallinnoima palvelu, ja konesalissasi olevan Outposts-räkin kyvykkyydet kehittyvät automaattisesti sitä mukaa, kuin AWS kehittää palvelua eteenpäin.
Yhteenvetona: Pilvipalveluiden mahdollisuudet ovat usein merkittävästi suuremmat, kuin niihin liittyvät riskit. Ja pilvipalvelutoimijat kehittävät jatkuvasti enemmän kyvykkyyksiä, jotta voit valita, ajatko työkuormia ja käsitteletkö dataa pilvessä vai omassa verkossa.
Oma erityisaiheensa on henkilödata ja sen käsittely. EU:n yleisen tietosuoja-asetuksen mukaisesti EU-kansalaisten henkilödataa pitäisi lähtökohtaisesti käsitellä EU-alueella. Datan vienti pois EU-alueelta on sallittu ainoastaan erityistapauksissa, eli esimerkiksi vain niihin maihin joiden kanssa EU:lla on sopimukset henkilödatan vastuullisesta käsittelystä, tai niille toimijoille jotka ovat sitoutuneet noudattamaan EU:n henkilödatan käsittelyn käytäntöjä, tai mikäli datan käsittelyn kohteena oleva henkilö on nimenomaisesti itse antanut suostumuksensa datan siirtoon.
Kaikilla merkittävillä pilvipalvelutoimijoilla on mahdollisuus valita käytettäväksi konesaliksi jokin EU-alueella oleva konesali, Googlella jopa Suomessa oleva konesali. Pilvipalvelun hallinnoijan/kehittäjän tulee kuitenkin huomioida, että osa pilvipalvelualustalla olevista palveluista voi olla ns. globaaleja palveluja, eli niiden osalta et voi valita käytettävän konesalin sijaintia. Tällaisia palveluja ovat AWS:ssä mm. DNS-palvelu Route 53 ja käyttäjä- ja pääsynhallintapalvelu IAM. AWS on kuitenkin ilmoittanut, että kaikki sen tarjoamat palvelut ovat GDPR-yhteensopivia, eli ne kunnioittavat kaikkia tietosuoja-asetuksen vaatimuksia riippumatta siitä, missä päin maailmaa dataa käsitellään. Lue lisää AWS:n GDPR-yhteensopivuudesta: https://aws.amazon.com/blogs/security/all-aws-services-gdpr-ready/
Myytti #5: Omassa konesalissani on parempi tietoturva
Jos näin on, sinun tietoturvaosaamisella on varmasti kysyntää. Turvallisuuden tunnetta voi nostaa se, että tiedät palvelinten ja datan sijaitsevan lähistöllä olevassa luolassa. Tai se että tunnet räkkejä ja verkotuksia asentavat it-kaverit henkilökohtaisesti. Turvallisuuden tunnetta voi myös nostaa se, että tiedät ettei sinun konesalisi kiinnosta hakkereita ja muita ilkiöitä samalla tavalla kuin esim. Amazonin konesali.
Tässä on kuitenkin jutun pihvi. Globaaleja pilvijättejä ja heidän konesaleja vastaan yritetään hyökätä joka päivä, joten heille DDoS-hyökkäysten ja tietomurtautumisten yritykset ovat jokapäiväistä arkea ja heillä on todennäköisesti maailman parhaat havainnointi-, reagointi- ja torjuntakyvykkyydet näiden tilanteiden varalle.
Kuten jo aiemminkin sanottu, turvallisuus on sekä pilvipalvelun tarjoajan että asiakkaan yhteispeliä - security of the cloud & security in the cloud. Pilvipalvelun tarjoaja ei voi mitään sille, jos päätät asentaa pilvessä olevalle virtuaalikoneelle reikäisen vanhan version Wordpress-palvelusta ja palvelusi korkataan sen takia. Tai jos tarkoituksella tai epähuomiossa siirrät dataa asiakkaasi koneelta pilveen salaamattomana ja man-in-the-middle nappaa datan siirtotieltä itselleen.
Myytti #6: Minulla on käytössäni softalisenssejä, jotka vaativat oman dedikoidun palvelimen
Tämä voi tosiaankin olla tilanne. Kannattaa kuitenkin varmistaa lisenssin myyjältä, onko ymmärryksesi lisenssistä ajan tasalla tai löytyykö lisensöijältä vaihtoehtoista lisenssimallia, joka mahdollistaisi työkuormien ajon pilvialustalla. Mikäli ohjelmistotalo haluaa rakentaa tietään tulevaisuuteen, se todennäköisesti on jo ottanut huomioon sen, että uudet järjestelmät halutaan hyvin usein toteuttaa pilvipalvelumallilla.
Joskus lisenssiehdot edellyttävät, että lisenssinhaltijan pitää pystyä aukottomasti todistamaan lisenssiä käytetyn vain tietyssä yhdessä palvelimessa ja lisensoidulla CPU-määrällä. AWS mahdollistaa tämän AWS EC2 Dedicated Hosts -palvelulla. Tällöin saat haluamastasi AWS:n konesalista todellakin fyysisen, vain sinulle dedikoidun serverin käyttöösi ja voit kytkeä palvelimen AWS License Manager -palveluun, jonka avulla voit todentaa lisenssiehtojen mukaisen käytön. Näin pystyt hyödyntämään esimerkiksi vanhoja Microsoft- tai Oracle-lisenssi-investointeja samalla kun rakennat uutta joustavuutta ja uudenlaisia kyvykkyyksiä pilveen.
Myytti #7: En voi käyttää pilvipalveluja, koska se vaatii Internet-yhteyden
Tämä on haasteellinen asia, koska lähtökohtaisesti julkiset pilvipalvelut ovat Internetissä. Kysymys pitää jakaa kolmeen erilaiseen skenaarioon:
- Organisaatiossa on paljon toimipisteitä eri puolella maailmaa, ja keskitetyn palvelun käyttäminen on tuskaista latenssiongelmien takia
- Verkkoyhteydet eivät ole luotettavia kaikkiin toimipisteisiin, ja yhteys saattaa välillä olla esimerkiksi tuotantolaitokseen kokonaan poikki
- Toimintaympäristö todella määrittää sen, että yhteyksiä julkiseen Internetiin ei voi käyttää
Ensimmäiseen skenaariossa pilvipalvelut tarjoavat paljon paremman ratkaisumallin, kuin perinteiset yhdestä konesalista maailmanlaajuisesti tarjottavat palvelut. Esimerkiksi AWS Cloudfront -palvelulla (CDN-ratkaisu) levität palvelusi staattiset komponentit eri puolille maailmaa nopeasti ladattavaksi, AWS Elasticache -palveluilla rakennat tietokantojesi eteen maantieteellisesti hajautetun välimuistikerroksen ja Amazon S3 Transfer Acceleration -palvelulla nopeutat tiedostojen lataamista maapallon toiselle puolelle kymmenillä prosenteilla hyödyntämällä AWS:n Edge-lokaatioita.
Voit itsekin helposti kokeilla S3 Transfer Acceleratorin voimaa - AWS on rakentanut testipalvelun, jossa sinun selaimestasi lähetetään testitiedosto eri puolilla maapalloa oleviin konesaleihin sekä suoraan että käyttäen S3 Transfer Acceleratorin Edge-verkostoa. Esimerkiksi Sydneyn konesaliin ladattaessa sain 67% nopeamman latauksen Edge-verkoston kautta kuin suoraan Sydneyyn yhdistämällä. Kokeile itse täällä: https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html
Toiseen skenaarioon pitää tietysti hakea ensin ratkaisua verkotusta parantamalla ja esimerkiksi rakentamalla kaksi eri operaattorin kautta kulkevaa Internet-yhteyttä. Mutta jos riski verkkoyhteyden katkeamisesta on silti merkittävä, tai mikäli esimerkiksi laajamittaisen tuotantolaitteiston (valmistava teollisuus, kaivos, laiva,…) toiminta on riippuvainen yhteyden takana olevista palveluista, voi olla järkevä harkita esim. AWS Outposts -tyyppistä palvelua osana kokonaisratkaisua.
Esimerkkinä tästä Volkswagen on rakentamassa omien sanojensa mukaan maailman suurinta valmistavan teollisuuden IoT-ratkaisua, joka yhdistää kaikki VW:n yli sadan tuotantolaitoksen tuotantolinjat AWS:n analytiikka- ja tekoälypalveluihin. Jotta tuotantolinjat voivat varmasti lähettää jatkuvasti katkeamatonta IoT-tietovirtaa pilveen, jokaisen tuotantolaitoksen yhteyteen asennetaan AWS Outposts -palvelu toimimaan linkkinä tuotantolaitoksen ja AWS-pilven välissä. Lue lisää esim. täältä: https://www.businessinsider.com/volkswagen-amazon-web-services-vw-industrial-cloud-2019-3?r=US&IR=T
Kolmannessa skenaariossa pitää vielä tunnistaa se, onko yhteydet omasta verkosta muualle totaalisesti kielletty, vai onko nimenomaan ip-pakettien reitittäminen julki-internetissä se, mitä pitää välttää. Mikäli oman verkon yhdistäminen ulkomaailmaan on totaalisesti kielletty, ei pilvipalveluiden käyttö ole mahdollista. Mutta mikäli halutaan lisätä turvallisuutta ja pienentää latenssia oman verkon ja AWS:n välillä, on ratkaisuna AWS Direct Connecting käyttöönotto. Direct Connect hyödyntää VLAN-virtuaalilähiverkkotekniikkaa, jonka avulla yhdistät oman verkkosi maantieteellisesti lähimpään AWS Direct Connect -pisteeseen ja sitä kautta suoraan omaan VPC-verkkoosi (Virtual Private Cloud) AWS:ssä. Esimerkiksi Suomessa lähin AWS Direct Connect -piste löytyy Helsingistä, yhdistettynä AWS:n runkoverkossa suoraan Frankfurtin konesaliin.
Myytti #8: Sitten kun olen koukussa, alkaa hintojen nosto
Tämä on perusteltu huoli. On aina riski investoida kehityspanoksia alustalle, jonka hinnoittelu voi muuttua milloin tahansa.
Toistaiseksi nämä huolet ovat kuitenkin olleet pääosin aiheettomia. Pilvipalvelumarkkinoilla on jatkuvasti kovempi kilpailu, kun alan suuret jättiläiset yrittävät tehdä selvää toisistaan. Asiakkaan näkökulmasta tämä tarkoittaa laskevia hintoja. Esimerkiksi AWS on vuosien varrella tiputtanut hintojaan kymmeniä kertoja.
Sitä mukaa, kun pilvipalvelut valtaavat alaa, ne saavuttavat yhä suuremman ekonomian hyötyjä ja pystyvät sitä kautta ostamaan yhä edullisemmin tarvitsemansa komponentit ja kehittämään omaa teho-hyötysuhdettaan entistä paremmaksi. Internetistä löytyy vino pino artikkeleja, joissa on selvitetty AWS:n palveluiden hinnoittelumuutoksia vuosien varrelta. Tässä niistä eräs, joka toteaa että AWS on laskenut hintojaan kymmeniä kertoja, mutta ei ole kertaakaan tehnyt hinnankorotuksia: https://www.stayclassyinternet.com/articles/investigating-AWS-pricing-over-time/
Toinen huomioitava asia tässä on oma suuruuden ekonomiasi. Saat pilvipalveluista sitä enemmän säästöä, mitä enemmän niitä käytät. AWS:n hinnoittelun mottona on jo vuosia ollut:
Pay-as-you-go. Save when you reserve. Pay less by using more.
Eli liikkeelle voit lähteä ilman mitään etukäteisinvestointeja. Jos sitoudut käyttämään resursseja 1 tai 3 vuoden sopimuksella etukäteen, saat merkittäviä alennuksia. Ja mitä enemmän käytät palveluita, sen alhaisemmaksi niiden yksikköhinta laskee.
Loppuhuomautuksena tähän teemaan: Kuten jo aiemmin todettu, pilvipalvelut vapauttavat sinut kapasiteetin ennakkosuunnittelusta. Mutta tilalle tulee kapasiteetin ja kustannusten jatkuva monitorointi ja optimointi.
Myytti #9: Olen jo ulkoistanut konesalini, ongelma siis ratkaistu
Ongelmia on monenlaisia. Konesalin ulkoistamisella olet ratkaissut ongelman, jossa palvelininfran ylläpito ja siihen liittyvät AMS-palvelut on siirretty oman henkilöstösi vastuulta sopimuskumppanisi vastuulle. Todennäköisesti edelleen itse maksat dedikoiduista palvelimista, niiden käyttöjärjestelmistä, varusohjelmistoista, niiden päivityksistä jne. Konesalikumppanillasi voi olla usean asiakkaan yli toimivia hyviä käytäntöjä palvelutuotannossaan, ja kenties jonkin verran automatiikkaakin ylläpitotehtävissä verrattuna aiempaan tilanteeseen. Kuitenkin muutokset kapasiteetissa ovat aina muutosprosessin ja tikettijärjestelmien avulla hoidettavia asioita, ja aikajänne ideasta toteutukseen voi kestää päiviä, viikkoja tai jopa kuukausia. Kokonaisuuden hallintaan tarvitaan paljon asiakaskohtaista käsityötä.
Pilvipalveluissa automaation aste on jotain aivan muuta. Ja automaation avulla tarvitsemasi muutokset ympäristöihin toteutetaan sekunneissa tai enintään minuuteissa. Puhumattakaan siitä, että pilvipalvelut tarjoavat merkittävän määrän kyvykkyyksiä, joita ulkoistetusta konesalistasi ei löydy, tai joita sinne ei ole kustannusmielessä mitään järkeä rakentaa.
Lue NordHeron aiemmista blogeista, minkä takia pilvipalvelut ovat jotain ihan muuta kuin ulkoistettu konesali (https://www.nordhero.com/posts/keskity-lisaarvoon/) ja miten varmistat, että juuri sinä saat radikaalisti enemmän hyötyä irti pilvi-investoinnistasi (https://www.nordhero.com/posts/parempi-pilvimigraatio/).
