Data-alustojen mahdollisuudet tukea organisaation FinOps tavoitteita ja toteutusta, osa 2 / 3: Julkipilven ja oman konesalin eroavaisuudet

Jani Savolainen

Tässä blogisarjan toisessa osassa kiteytän oman konesalin ja julkipilven keskeisiä eroavaisuuksia osana data-alustojen FinOps-toteutuksia. Vaikkakin yhteneväisyyksiä löytyy monella osa-alueella, useat eroavaisuudet johtuvat perustavanlaatuisista eroista kustannusrakenteissa, resurssiallokaatioissa sekä toimintamalleissa näiden kahden ympäristön välillä. Selvimmin tilannetta voidaan kuvata vertailemalla data-alustoja FinOps:n näkökulmasta:

Kustannusmalli ja palvelun hinnoittelu

Kustannusmallin erot ovat selkeät ja avautuvat parhaiten klassisen Capex / Opex -ajattelun kautta:

Julkipilvi	Oma konesali
Pay-as-You-Go: Kustannukset perustuvat resurssien kulloiseenkin käyttöasteeseen ja ne laskutetaan kuukausittain, mikä tarjoaa yksityiskohtaisen näkyvyyden resurssikulutukseen (esim. laskentateho, datan liikkuminen ja tallennus).	Kiinteät kustannukset: Kustannukset ovat kiinteän kaltaisia, joita voidaan jaksottaa erilaisilla maksujärjestelyillä. Infrastruktuuriin (laitteistot, lisenssit, tilat) tehdään mittavia etukäteisinvestointeja. Konesalin käyttökustannukset (esim. jäähdytys ja sähkö) ovat luonteeltaan toistuvia.
Joustava hinnoittelu: Asiakas voi optimoida omia kulujaan sitoutumalla tiettyihin palveluihin ja kapasiteettiin ja saada tätä kautta säästöjä. Julkipilvi tarjoaa asiakkaalle ketterän tavan kuluttaa käytön mukaan ja välttää etukäteisinvestointeja. Ketteryyden mukana saattaa tulla korkeammat kustannukset ja ne on syytä analysoida yhdessä liiketoiminnan hyötyjen kanssa.	Staattinen hinnoittelu: Kustannusten määrä on vakio käytöstä riippumatta. Kustannuksia voidaan kohdentaa käyttäjien mukaan, mutta organisaation kokonaiskustannus on kohdentamisen lähtökohta ja rajoittaa siten organisaation sisäisiä hinnoittelumahdollisuuksia. Organisaatio voi saavuttaa kustannustehokkuutta erilaisilla konsolidoinneilla ja optimoinneilla, joiden avulla käyttäjille jaettavaa kokonaiskustannusta saadaan pienemmäksi.

Resurssien skaalautuvuus

Resurssien skaalautuvuus ja joustavuus ovat merkittäviä tekijöitä organisaation FinOps -matriisissa, jossa pyritään kustannusoptimoimaan tarvittavia resursseja. Optimoinnissa on tyypillisesti kyse julkipilven joustavuuden ja oman konesalin kustannustehokkuuden sekä suorituskyvyn yhteensovittamisesta. Yksinkertaistetusti sanottuna julkipilvi on hyvä ratkaisu sellaisiin tarpeisiin, joissa resurssitarvetta on vaikea ennustaa ja oma konesali perustelee usein paikkansa silloin, kun resurssitarve on hyvin tiedossa.

Julkipilvi	Oma konesali
Skaalautuvuus tarpeen mukaan: Resursseja voidaan skaalata ylös- tai alaspäin dynaamisesti työkuormaperusteisesti. Julkipilvestä resursseja on saatavilla käytännössä rajattomasti.	Rajoitettu skaalautuvuus: Skaalaaminen saattaa edellyttää jossain vaiheessa uuden laitteiston hankintaa, asennusta ja konfigurointia, mikä vie aikaa. Alaspäin skaalautuminen voi olla hankalaa.
Elastisten työkuormien tuki: Ihanteellinen vaihteleviin työkuormiin, kuten eräajoihin tai koneoppimiseen sekä voimakkaasti kausiluontoisiin tapahtumiin ja uusien palveluiden käyttöönottoon.	Kapasiteettisidonnaisuus: Konesalin fyysinen kapasiteetti rajoittaa suorituskykyä ja skaalautuvuutta ja voi johtaa tilanteisiin, joissa resurssit loppuvat ilman lisäinvestointeja.

Kustannusten allokointi ja vastuullisuus

Kustannusten allokointi on julkipilvessä helpompaa. Toisaalta julkipilvessä voi joutua maksamaan samasta käyttökapasiteetista enemmän kuin omassa konesalissa. Oman konesalin kustannukset kuormittavat organisaatiota 24/7 -periaatteella, kun taas julkipilvestä ostetut palvelut ovat hinnoiteltu käytön mukaisesti. Jos asiakkaan toiminta keskittyy esimerkiksi kahdeksalle tunnille päivässä, miksi maksaa ylimääräisestä 16 tunnista?

Julkipilvi	Oma konesali
Yksityiskohtainen kustannusten kohdistaminen: Kustannukset voidaan kohdistaa tietyille projekteille, ryhmille tai sovelluksille erilaisten tunnisteiden, tilien tai tilausten kautta.	Karkea kustannusten kohdistaminen: Kustannukset ovat vähemmän yksityiskohtaisia ja jaetaan usein arvioiden tai kiinteiden prosenttiosuuksien perusteella, ellei yksityiskohtaista käytön seurantaa toteuteta. Kustannusten kokonaissumma, eli kohdennettava kustannus, pysyy kuitenkin aina samana.
Showback / Chargeback: Alkuperäiset työkalut, kuten Azure Cost Management tai AWS Cost Explorer, mahdollistavat yksityiskohtaiset kustannusten kohdentamiset.	Räätälöity Showback / Chargeback: Kattavan mallin toteuttaminenvaatii manuaalista kohdentamista tai kolmansien osapuolten ratkaisujen hankintaa.

Näkyvyys ja monitorointi

Data-alustan kustannusten ja palveluiden laadun näkyvyyden ja monitoroinnin osalta on hyvä valita sellainen ratkaisu, joka palvelee sekä oman konesalin ja julkipilven osalta yhtenä kokonaisuutena.  Omien konesalien ja julkipilvien data-alustojen kustannukset ovat usein omissa lokeroissaan, jolloin niiden vertaileminen voi olla haastavaa.

Julkipilvi	Oma konesali
Kustannusoptimointimahdollisuudet: seuranta on helppoa, mutta kustannusoptimointi vaatii perehtymistä ja samanlaista syväosaamista kuin omien konesalien osalta. Julkipilvien osalta kustannusoptimoinnin mahdollisuudet ovat merkittäviä ja vaikuttavia, koska optimoimalla saadaan nopeasti näkyviä vaikutuksia organisaation kokonaiskuluun.	Kustannusoptimointimahdollisuudet: Omien konesalien kustannusten optimoinnin osalta on ennemminkin kyse resurssien optimaalisesta ja tehokkaasta hyödyntämisestä, kuin kustannustason alentamisesta. Eli samalla resurssimäärällä saadaan tehtyä enemmän. Tämä sen takia, että tehdyt investoinnit ovat määrittäneet kokonaiskustannusten minimitason. Tämän takia omien konesalien ja julkipilvien vertailua olisi hyvä tehdä samalla pöydällä, jolloin pystytään objektiivisesti päättämään kustannustehokkain tapa tuottaa tarvittavia palveluita.
Palvelukohtaiset kustannustiedot kokonaiskustannusten alentamiseksi: Lähes välitön pääsy käyttötietoihin mahdollistaa ennakoivan kustannusten hallinnan lyhyellä aikavälillä palvelukohtaisesti. Organisaatio maksaa vain käyttämistään resursseista.	Palvelukohtaiset kustannustiedot kokonaiskustannusten oikealle jyvittämiselle: Käyttötiedot mahdollistavat kustannusten jyvittämisen, mutta jyvitettävää kokonaiskustannustasoa ei pystytä alentamaan nopeasti. Tällä kuitenkin varmistetaan kustannusten oikeudenmukainen kohdentaminen.

Optimointistrategiat

Julkipilven ja omien konesalien data-alustojen optimointimahdollisuuksissa on paljon samankaltaisuuksia, joskin omassa konesalissa työkuormien konsolidointimahdollisuudet ovat monipuolisempia ja kustannustehokkuuden osalta voidaan saavuttaa tyypillisesti huomattavasti suurempia parannuksia kuin julkipilvissä.

Julkipilvi	Oma konesali
Työkuormien optimointi (Right-Sizing) ja konsolidointi: Työkuormia voidaan konsolidoida  tietokanta- tai tietokantainstanssitasolla isompiin julkipilven hallinnoituihin instansseihin (Managed Instance) tai palvelimiin laitteistojen käytön optimoimiseksi. Lisäksi voidaan optimoida  virtuaalikoneiden ja tallennustasojen (storage tier) kokoa käyttötapausten perusteella kustannusten säästämiseksi.	Työkuormien optimointi (Right-Sizing) ja konsolidointi: Työkuormia voidaan konsolidoida  tietokanta-, tietokantainstanssi- ja  virtuaalikonetasolla isompiin palvelimiin laitteiston käytön optimoimiseksi Lisäksi voidaan optimoida  virtuaalikoneiden kokoa käyttötapausten perusteella kustannusten säästämiseksi.
Varatut instanssit (reserved instance) ja säästösuunnitelmat: julkipilvissä on mahdollisuus edullisimpiin hintoihin, jos on valmis sitoutumaan tiettyyn määrään resursseja.Tällöin joudutaan tekemään kompromissi julkipilven täysin kulutukseen perustuvan laskutuksen osalta.	Elinkaaren hallinta: Konsolidoimalla ja optimoimalla työkuormia voidaan varmistaa, että käytössä olevat laitteistot tuottavat optimaalisen hyödyn. Vanhentuneet ja rajallisen lisähyödyn tuottavat vanhemmat investoinnit voidaan korvata kokonaistaloudellisimmilla ratkaisuilla. Vaihtoehtoina on myös laitteistojen elinkaaren jatkaminen.
Dynaaminen resurssien skaalaus: Julkipilvissä on mahdollisuus automaattiseen resurssien skaalaamiseen käytön tarpeiden mukaan.	Työkuorman ajoitus: Tämä optimoi kuormituksen suorittamisen ajoitus virta- ja jäähdytyskustannusten vähentämiseksi. Ajoittamalla työkuormien suorittamista voidaan varmistaa resurssien tehokas käyttö ja myös leikata kuormituspiikkejä. Tällä eliminoidaan muun muassa liialliset investoinnit sekä turha sähkön ja jäähdytyksen käyttö.

Automaatio

Julkipilvissä automaatio on sisäänrakennettu, kun taas omissa konesaleissa se joudutaan rakentamaan erillisten automaatioratkaisuiden avulla. Molemmissa pystytään saavuttamaan erittäin korkea automaatioaste, mutta keinot ja tavat sen toteuttamiseen ovat erilaisia.

Julkipilvi	Oma konesali
Laajat automaatiovaihtoehdot: Mahdollisuus käyttää  serverless-teknologiaa, skriptejä ja orkestrointityökaluja dynaamiseen skaalaukseen ja resurssien hallintaan	Manuaalinen malli tai rajoitettu automaatio: Automaatio voi vaatia merkittäviä investointeja orkestrointityökaluihin (esim Ansible, Puppet tai Kubernetes, PowerShell, Dbatools)
Infrastruktuuri koodina (IaC): Palveluiden käyttöönotto ja skaalaaminen voidaan automatisoida IaC työkaluilla (esim. Terraform, Bicep).	Laitteistokohtaiset kokoonpanot: Omissa konesaleissa saattaa olla hyvinkin erilaisia laitteistokokonaisuuksia, joita ei ole suunniteltu toimimaan isona yhteisenä resurssivarantona. Virtualisointi auttaa, mutta silti laitteistokohtaiset ominaisuudet vaikuttavat optimointiin ja konsolidointiin.  SQL Governor-tyyppisissä ohjelmistoissa on erilaisia ominaisuuksia, jotka helpottavat merkittävästi erilaisten kokoonpanojen vertailua ja skenariointia kapasiteettitarpeiden ja suorituskykyvaatimusten osalta.

Taloudellinen joustavuus

Julkipilvi on taloudellisesti joustavampi malli kuin oma konesali. Niin julkipilvelle kuin omalle konesalille on omat perustellut paikkansa, mutta niiden roolien optiointi vaatii syvällisempää ymmärrystä ja laskentaa. Kategorinen kannanotto toisen edullisuudesta tai kalleudesta ei kestä tarkempaa analyysiä.

Julkipilvi	Oma konesali
Korkea taloudellinen joustavuus: Kaikki kulut ovat toimintakuluja (OPEX) ja organisaatiot voivat välttää pääoma- ja investointikustannuksia.	Korkeat pääomakustannukset (CAPEX): Vaatii pääomasijoituksia ja investointeja etukäteen ja tämä voi  vaikeuttaa sopeutumista muuttuviin taloudellisiin olosuhteisiin ja markkinamuutoksiin.
Ylikuormitus(Burst)kapasiteetti ja laajentumiskyvykkyys: Julkipilvi pystyy vastaamaanhelposti lyhytaikaisiin jaodottamattomiin työkuormiin ilman suuria investointeja.	Kapasiteettirajoitettu: Purskeiden hallinta vaatii yliprovisiointia tai ylimääräisen kapasiteetin vuokraamista, jotka molemmat ovat tyypillisesti kokonaistaloudellisesti kalliita vaihtoehtoja

Governance ja vaatimustenmukaisuus

Governancen ja vaatimustenmukaisuuden (säädökset ja standardit) suhteen julkipilvi on selkeästi vahvempi ja kustannustehokkaampi vaihtoehto kuin oma konesali. Tämä näkyy eritoten vahvasti reguloiduissa ympäristöissä. Julkipilvien osalta on hyvä pohtia oman data-alustan ja datan sijaintia. Monet julkipilvet saattavat mahdollistaa pääsyn dataan globaalisti ja datan sijainnin rajaaminen aukottomasti voi olla vaikeaa, tai jopa mahdotonta.

Julkipilvi	Oma konesali
Käytäntöjen täytäntöönpano: Esimerkiksi työkalut, kuten Azure Policy tai AWS Config, pakottavat käytön ja kustannusten hallinnan eri käyttäjätileille, joka osaltaan lisää hallinnon läpinäkyvyyttä.	Mukautettujen käytäntöjen tarve: Hyvän hallinnon (Governance)-vaatimukset  on toteutettava tyypillisesti kolmannen osapuolen työkaluilla.
Sisäänrakennettu tietoturva ja vaatimustenmukaisuus: Julkipilvet tarjoavat maailmanlaajuisten standardien (esim. GDPR, HIPAA) noudattamisen.	Mukautetut vaatimustenmukaisuustoimenpiteet: Organisaatioiden on varmistettava, että fyysiset ja toiminnalliset vaatimustenmukaisuusvaatimukset täyttyvät.

Tiimien välinen yhteistyö

Julkipilvi	Oma konesali
Tiimien välinen yhteistyö: Talous-, IT- ja erilaiset suunnittelutiimit pääsevat käsiksi itselleen relevanttiin tietoon heille optimoitujen näkymien kautta.	Siiloutuneet toiminnot: Yhteistyö eri toimintojen välillä voi olla vähemmän integroitua ja näkyä hitaampana toimintana. Uusien palveluiden käyttöönotto voi olla hidasta ja jopa häiritä liiketoimintaa. Konesaliautomaation avulla voidaan toteuttaa julkipilvimäistä automaatiota, mutta se tarkoittaa lisäinvestointeja.
Itsepalvelun hyödyntäminen: Käyttäjät voivat valmistella ja hallita tarvitsemiaan resursseja itsepalveluna. Automaation avulla pystytään eliminoimaan selkeitä käyttäjävirheitä.	Keskitetty hallinta: Tyypillisesti IT hallitsee resurssien valmisteluja, mikä voi johtaa mahdollisiin pullonkauloihin ja hitauteen palveluiden käyttöönotossa.

Loppusanat

Julkipilven ja oman datakeskuksen eroja voidaan tiivistetysti kuvata oheisella taulukolla:

Vaikka molemmat ympäristöt hyötyvät FinOps-käytännöistä, julkinen pilvi korostaa joustavuutta, läpinäkyvyyttä ja dynaamista kustannusten hallintaa, kun taas omat konesalit keskittyvät kiinteiden kustannusten optimointiin, resurssien käyttöön ja kapasiteetin suunnitteluun. Toteutusstrategiat ja -välineet eroavat toisistaan merkittävästi taustalla olevien arkkitehtuuri- ja rahoituserojen vuoksi.

Optimaaliset ratkaisut löytyvät usein näiden kahden maailman välimaastosta, niinsanotusta hybridiratkaisuista. Molemmille on paikkansa ja kustannustehokkaimman ratkaisun löytäminen vaatii molempien perinpohjaista tuntemista ja parhaiden puolien hyödyntämistä.

Julkipilvien positiiviset käyttäjäkokemukset ovat motivoineet omien konesalien ratkaisutoimittajia keskittymään pilvimäisen käyttäjäkokemuksen kehittämiseen. On hyvä muistaa, että pilvi ei ole paikka vaan toimintatapa. DB Pro:n SQL Governor -ratkaisun avulla näet sekä omien konesaliesi että julkipilven tilan ja voit tehdä tehokkaita FinOps-päätöksiä hallitusti ja keskitetysti data-alustasi suorituskykyyn ja kapasiteettioptimointiin liittyen. Voit lukea SQL Governorin ominaisuuksista tarkemmin lisää täältä: www.sqlgovernor.com

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy