17.11.2023 | Blogi Markkinakatsaus Poiminnat Teknologiat

Microsoft Fabric yleisesti saataville – tutustu päivitettyyn hinnoittelumalliin!

Microsoft Ignite toi viimein meille kaikille dataintoilijoille hartaasti odotettuja uutisia, kun Microsoft Fabric julkaistiin yleisesti saataville (GA). Joulu jo marraskuussa, kelpaa! Ignite toi mukanaan paljon mielenkiintoisia julkistuksia Fabricin osalta. Kaiken keskiössä on kuitenkin se, että nyt Fabric on maturiteetiltaan virallisesti julkaistu tuote, jota voidaan tosissaan alkaa hyödyntämään data-alustana. Toki tiedämme, että paljon ominaisuuksia on vielä kehityksen alla Preview-tilassa ja road map on pitkä, mutta tärkeä virstanpylväs vakavasti otettavana datatuotteena on nyt saavutettu.

Nyt kun organisaatiot voivat turvallisin mielin alkaa suunnittella Fabricin käyttöönottoa, on hyvä hetki perata Fabricin hinnoittelua vähän syvällisemmin – aihe, jota olen päässyt esittelemään lukuisia kertoja asiakkaillemme viime kuukausien aikana. Koska suurin osa Fabricia käsittelevästä materiaalista on englanniksi, tehdään poikkeus ja kirjoitetaan tällä kertaa suomeksi.

Hinnoittelun komponentit

Fabric paketoi ennen erillisenä hankitut analytiikkaalustan palaset yhden SaaS-palvelun sisälle, siispä tuotteella on vain yksi hinta – tai näin Microsoftilla sanovat. Tämä pitää siinä mielessä paikkansa, sillä Fabricin sisällä et maksa esimerkiksi Data Factoryn ja Synapse Data Warehousen käytöstä erikseen. Todellisuudessa Fabricin hinnoittelu kuitenkin koostuu itseasiassa kolmesta komponentista:

  1. Fabric-kapasiteetista eli laskentatehosta
  2. OneLake-tallennustilasta
  3. Käyttäjäkohtaisesta Power BI -lisensoinnista

Ennen kuin siirrytään tutkimaan miten kunkin komponentin hinta muodostuu, käydään vielä läpi pari oleellista Fabric-käsitettä, jotta pystymme paremmin keskustelemaan aiheesta.

  • Jotta Microsoft Fabric ympäristö pystytään luomaan, tarvitaan Microsoft Entra Tenant (entinen Azure AD). Yleensä organisaatiolla on käytössä yksi tenant.
  • Työtila (Workspace) on säiliö, johon Fabric-komponentit luodaan. Työtilat ovat tuttuja Power BI:stä jo entuudestaan, ja niiden luomien tapahtuu täysin samalla tavalla – asetuksista valitaan vain lisesointimalliksi Fabric-kapasiteetti. Työtiloja voi olla useita, ja jokainen Fabric-työtila liittyy johonkin Fabric-kapasiteettiin. Usea työtila voi käyttää samaa Fabric-kapasiteettia.

Kaikki tässä kirjoituksessa esitetyt hinnat ovat voimassa julkaisuhetkellä ja voivat muuttua ajan mittaan.

Fabric-kapasiteetti

Fabric-kapasiteettia mitataan kapasiteettiyksiköillä (Capacity Unit, CU) saatavilla olevaa laskentatehoa. Kapasiteettia on saatavilla eri kokoisia ja hintaisia, kuten oheinen taulukko kuvaa. F2-kapasiteetti sisältää 2 kapasiteettiyksikköä ja niin edelleen. Fabric-kapasiteetilla saat käyttöön kaikki Fabricin komponentit (Synapsen komponentit, Data Factoryn, Data Activatorin jne.), lukuun ottamatta Power BI:n käyttäjälisenssejä, joita vaaditaan raporttien julkaisuun ja käyttämiseen Power BI Service -portaalissa. Tarkastellaan Power BI -lisenssien osuutta hieman myöhemmin, mutta todettakoon että Fabric-kapasiteetin suuruus vaikuttaa tähän käyttäjäkohtaiseen lisensointitarpeeseen.

Kuva 1: Fabric-kapasiteetin hinnoittelu Pohjois- ja Länsi-Euroopan Azure-alueilla

Fabric-kapasiteetti provisioidaan Azure-portaalista. Tämä on hyvin yksinkertainen prosessi, ja jo muutamassa minuutissa Fabric-kapasiteetti on käytössäsi. Kapasiteetin hinnoitteluun on käytettävissä kaksi mallia: sekuntipohjainen Pay-as-you-go -hinnoittelu, sekä juuri julkaistu vuosikohtainen Reservation-hinnoittelu. Pay-as-you-go -hinnoittelussa minimissään laskutetaan yksi minuutti, ja tämän jälkeen laskutus jatkuu sekuntipohjaisesti kapasiteetin ollessa päällä, riippumatta siitä onko palvelussa työkuormaa vai ei. Taulukossa esitetty hinta muodostuu Fabric-kapasiteetin ollessa päällä 24/7 kuukauden ajan. Pay-as-you-go -hinnoittelulla kustannuksia on kuitenkin mahdollista optimoida sulkemalla kapasiteetti silloin, kun sille ei ole tarvetta, tai skaalata sitä tarpeen mukaan. Tämä prosessi voidaan automatisoida.

On kuitenkin syytä muistaa, että kapasiteetin ollessa pois päältä mitkään Fabricin palvelut eivät ole käytettävissä. Tämä on ehkä merkittävintä Power BI -raporteille, mikäli ne on julkaistu Fabric-kapasiteettia hyödyntävään työtilaan, ja mikäli ne käyttävät DirectLake-yhteyttä – jos kapasiteetti on pois päältä, eivät raportitkaan toimi tällöin. Tätä pystytään kiertämään julkaisemalla Power BI -raportit omaan työtilaansa, joka hyödyntää esimerkiksi Power BI Pro -lisenssin tarjoamaa kapsiteettia. Tällöin raportti on import-tilassa, ja sitä koskevat pro-lisenssin rajoitteet esimerkiksi tietomallin koon osalta.

Vuodeksi kerrallaan sitouduttavaan Reservation-hinnoittelun tuntihinta on noin 40 prosenttia edullisempi verrattuna Pay-as-you-go:hon. Tällöin laskua ei kuitenkaan pysty samalla tavalla optimoimaan sulkemalla tai skaalaamalla kapasiteettia tarpeen mukaan. Sopivaa hinnoittelumallia valitessa käyttötarve tuleekin analysoida tarkasti: mikäli Fabricin palveluiden tulee olla saavutettavissa 24//7, on Reservation hinnoittelu parempi valinta. Toisaalta jos tarve Fabric-palveluille on vain tiettyinä kellonaikoina tai satunnaisesti, voidaan edullisempaan hintaan päästä Pay-as-you-go -mallilla. Mikään ei myöskään estä esimerkiksi pitämästä yhtä Reservation-hinnoittelun piirissä olevaa kapasiteettia pohjalla, ja luomaan rinnalle Pay-as-you-go -kapasiteettia adhoc-tarpeita varten. Ylipäätään organisaatiolla voi olla olemassa useita kapasiteetteja rinnakkain tarpeen mukaan, jolloin eri työtiloille voidaan kohdistaa sen tarvetta vastaava kapasiteetti.

Kapasiteetin tason lisäksi hintaan vaikuttaa Azure-alue, josta Fabric-provisioidaan. Fabric ei ole saatavilla tällä hetkellä kaikilla alueilla. Suomen kannalta relevanteimmat EU-sijainnit ovat todennäköisesti Länsi- (Alankomaat) ja Pohjois-Eurooppa (Irlanti) sekä Keski-Ruotsi. Oheinen taulukko kuvaa Länsi- ja Pohjois-Euroopan alueiden Microsoft Fabric-hintoja blogin kirjoitushetkellä. Taulukosta huomaa, että varsinkin suuremmissa kapasiteeteissa hintaero näiden kahden alueen välillä alkaa jo olla huomattava, eli alueen valintaan kannattaa kiinnittää huomiota. Keski-Ruotsin hinnoittelu oli identtinen Pohjois-Euroopan kanssa. Hintaa puntaroidessa on toki hyvä ottaa huomioon myös pidemmän etäisyyden aiheuttama latenssiero sekä organisaation datahallintasäännöt.

Mikäli organisaatiolla on olemassa tällä hetkellä Power BI Premiumin P-luokan kapasiteetti, rinnastuvat ne Fabric F64:ään ja sitä suurempiin kapasiteetteihin. Sallimalla Microsoft Fabricin käytön Admin-portaalista pystytään samalla kapasiteetilla luomaan myös Fabric-objekteja. Power BI Premium -kapasiteetin admin pystyy esimerkiksi Power BI -sovelluksen avulla tarkastamaan CPU:n käyttöasteen – mikäli koko kapasiteettia ei hyödynnetä, pystytään Fabric-kuormaa lisäämään ilman haittaa olemassa olevalle Power BI -käytölle.

Microsoft hyödyntää Power BI:stä tuttuja tasoitus- (smoothing) ja rajoitus- (throttling) -operaatioita myös Fabric-kapasiteetille. Tasoituksella mahdollistetaan hetkellisesti pääsy suuremman kapasiteetin piiriin, jotta operaatiot suoriutuvat nopeasti. Tällöin kapasiteettia käytetään tulevaisuuden kapasiteettisaldosta. Näitä käyttöpiikkejä tasataan hetkillä, jolloin kapasiteetti ei ole aktiivisesti käytössä. Näin tarvittava kapasiteetti voidaan siis valita keskimääräisen tarpeen pohjalta, ei maksimipiikkien mukaan. Rajoituksella tarkoitetaan tilannetta, jossa tulevaisuuden kapasiteettia on käytetty liikaa, ja Fabric alkaa rajoittaa operaatioiden suoritusta, mikä vaikuttaa käyttökokemukseen. En tässä artikkelissa mene yksityiskohtiin eri rajoitusmetodeista, mutta samoin kuten aiemmin Power BI:ssä, erilaiset operaatiot jaetaan interaktiiviseen (esim. raporttien käyttö) ja taustakuormaan (esim. tietovarastolataukset). Taustakuormien tasausperiodi on vuorokausi (24h), interaktiiviset kuormat tasataan minimissään viiden minuutin tasolla. Fabric-kapasiteetin käyttöä voidaan monitoroida aiemmin mainitun Power BI -sovelluksen avulla. Tasoitus- ja rajoitus-operaatiot ovat kapasiteettikohtaisia toimenpiteitä.

OneLake-tallennustila

OneLake on Fabricin tallennustila, josta kaikki eri Fabric-komponentit voivat lukea ja tallentaa datan. Oheisessa taulukossa OneLake muistin hinnat Pohjois- ja Länsi-Euroopan Azure-alueella. Yleiskäyttöisen OneLake-tallennustilan hinta on hyvin kohtuullinen, noin 22€/TB/kk. Tätä tallennustilaa käytetään suurimmalle osalle OneLake-datastasi. Kun uusi työtila luodaan, generoituu sille oma OneLake-kansio, johon tiedot tallennetaan. Muut työtilat voivat oikopolkujen (shortcut) avulla kysellä toisten työtilojen dataa. Kun työtila poistetaan, katoaa myös OneLake-kansio. Taustalla tiedot kuitenkin ovat tallessa asetetun säilytysajan (7-90 päivää), jonka ajan kyseisestä OneLake-säilytystilasta vielä maksetaan. OneLake-tallennustila on käytettävissä, vaikka Fabric-kapasiteetti olisikin suljettuna.

Kuva 2: OneLake-tallennustilan hinnoittelu Pohjois- ja Länsi-Euroopan Azure-alueilla

Yleiskäyttöisen OneLake-tallennustilan lisäksi on määritetty OneLake-, Cache- ja Business Continuity & Disaster Recovery (BCDR) -tallennustilan hinnoittelu. Cache-hinnoittelua käytetään reaaliaikaisen analytiikan KQL-tietokannan sekä monitorointiin hyödynnettävän Data Activatorin välimuistiin. Välimuistista data on saatavilla hyvin nopeasti, mutta hinta on myös kymmenen kertaa kalliimpi verrattuna normaaliin tallennustilan hintaan. Välimuistiin tallennettavat tiedot ja säilytysaika onkin siis syytä suunnitella tarkasti.

Uusin lisäys Fabricin tallennustilatarjoomaan on BCDR-tallennustila luomaan turvaa datalle katastrofien sattuessa. Fabricin BCDR-kyvykkyydet yleisesti eivät kata vielä kaikkia Fabricin komponentteja, mutta BCDR-tallennustilan avulla OneLakessa oleva data turvataan toiselle Azure-alueelle. BCDR-muistin hinta on korkeampi kuin normaalin tallennustilan hinta ja tämä pitää erikseen ottaa käyttöön Fabric kapasiteetin admin-portaalista.  Power BI on automaattisesti BCDR:n piirissä, kuten tähänkin asti.

Power BI -käyttäjälisenssit

Fabric ei ole muuttanut oikeastaan mitään suhteessa Power BI -käyttäjälisenssien tarpeeseen verrattuna aiempaan. Raporttien tekeminen Power BI Desktopilla on edelleen ilmaista, myös silloin kun hyödynnetään Fabricin dataa. Kun puolestaan Power BI -raportti halutaan julkaista ja jakaa Power BI Service -portaalissa myös muille organisaation jäsenille, tarvitaan maksullinen Power BI -käyttäjälisenssi – käytännössä tämä tarkoittaa yleensä Power BI Pro -lisenssiä, joka maksaa 9,4€/käyttäjä/kk. F64:ää pienemmillä Fabric-kapasiteeteilla niin raporttien käyttäjät kuin kehittäjätkin tarvitsevat nämä käyttäjälisenssit, samoin kuin aikaisemminkin, mikäli organisaatiolla ei ole käytössään Power BI Premium -kapasiteettia. Kuten aiemmin mainittiin, F64:stä alkaen Fabric-kapasiteetit rinnastuvat Power BI Premiumin P-luokan kapasiteetteihin, ja samat käytänteet käyttäjälisenssien osalta jatkuvat, sillä ainoastaan kehittäjät, jotka julkaisevat raportteja, tarvitsevat käyttäjälisenssit näillä suuremmilla Fabric-kapasiteeteilla.

Yhteenveto

Fabric-hinnoittelu on saanut lisää sävyjä tuotteen maturiteetin kasvaessa, ja alun punch line ”yksi hinta” voi tuntua nyt hieman liioittellulta. Silti on huomattava, että hinnoittelu on suhteellisen yksinkertainen verrattuna erikseen provisioitaviin palveluihin, joiden kapasiteettitarve tulee arvioida yksitellen. Edellä mainittujen varsinaisten Fabric-kustannusten lisäksi saattaa muodostua toki joitain muita kustannuksia tapauksesta riippuen. Tietoliikennekustannusten laskutusperiaatteen osalta minkään ei pitäisi olla oleellisesti muuttunut verrattuna aiempaan, Microsoft on kuitenkin julkaisemassa Fabriciin liittyvän verkkoliikenteen hinnoittelun tulevaisuudessa. Käyttötapauksesta riippuen saatetaan joutua käyttämään Fabricin ulkopuolisia palveluita, jotka maksavat erikseen. Data Governanceen hyödynnettävä Microsoft Purview integroituu Fabriciin tiiviisti, mutta se hinnoitellaan erikseen.

Hinnoittelusta puhuttaessa tietenkin olennaiseksi nousee kysymys: paljonko kapasiteettia tarvitaan? Tämän aiheen käsittelyyn tarvittaisiin kokonaan oma kirjoitus, ja suoraa, kaikille sopivaa vastausta tähän ei edes ole mahdollista antaa. Tarvittavaan kapasiteettiin kun huomattavasti vaikuttavat erilaiset käyttötapaukset, sisältäen datan ja lähteiden määrän, raporttien ja niiden käyttäjien lukumäärän, ja niin edelleen. Hyvä nyrkkisääntö on kuitenkin aloittaa provisioimalla pienin F2-kapasiteetti, alkaa rakentaa Fabric-ympäristöä tätä hyödyntäen, ja aktiivisesti seurata Fabric Capacity Metric Appia kapasiteetin riittävyyden arvioimiseksi.

Me Evitecillä olemme päässeet auttamaan jo muutamia asiakkaitamme matkalla Fabric-edelläkävijöiksi, ja mielellään autamme teitäkin alkuun pääsemisessä!

Kirjoittaja

Henni Niiranen

Data Consultant

Työeläkeyhtiö Elo halusi uudistaa ja nopeuttaa asiakasyritystensä työkykyjohtamista. Uusi verkkopalvelu tekee työeläkevakuuttamiseen liittyvien asioiden hoitamisesta helppoa ja nopeaa yrityksille, työnantajille ja tilitoimiston edustajille. Profit Software auttoi Eloa rakentamalla modernin tietovaraston palvelun perustaksi.

 

Verkkopalvelun lähtökohtana oli aikaisemmin manuaalisesti tehdyn työn digitalisointi ja automatisointi sekä uusien toiminnallisuuksien kehittäminen Elon asiakasyritysten tarpeisiin. (lisää…)

Vakuuttamiseen ja varainhoitoon erikoistunut LähiTapiola-ryhmä joutui kehittämään myös raportointiaan osana EU:n laajuista vakuutusyhtiöiden Solvenssi II –vakavaraisuusohjelmaa. Yksi käytännön haasteista liittyi kertomustyylisen raportoinnin tuottamiseen, johon haluttiin rakentaa uusi toimintaprosessi LähiTapiolassa. Uuden toimintaprosessin mahdollisti Profit Softwaren toimittama ryhmäraportoinnin kokonaisuus.

Kuvassa vasemmalta Ville Lilja, Annina Pietinalho, Elina Saartoala

LähiTapiola-ryhmän rakenne käsittää 22 vakuutusyhtiötä, joista jokainen tuottaa omat viranomaisraportit. Lisäksi osa raportoinnista tehdään ryhmätasolla. Raportoinnista on numeerisen tiedon lisäksi merkittävä osa kertovaa raportointia, joka muistuttaa paljon esimerkiksi yritysten vuosikertomuksia. Kertovan raportoinnin suurimpia haasteita on sen tuotantoprosessin eli sisällön tuottamisen rakentaminen tehokkaaksi.

–Lähtökohtana meillä oli, että tiesimme yleistasolla, kuinka kertovan raportoinnin työmme haluaisimme järjestää organisaatiossamme. Keskustelimme muutaman tietojärjestelmätoimittajan kanssa ja valitsimme Profit Softwaren ehdottaman ratkaisumallin, koska se vastasi kuvaamaamme prosessia sekä edellytti vain vähäisiä muutoksia olemassa oleviin tietojärjestelmiimme, kertoo projektista vastannut LähiTapiolan hankepäällikkö Elina Saartoala.

Teho irti olemassa olevasta järjestelmästä

LähiTapiolan käytössä oli jo Microsoftin Sharepointiin perustuva intranet-ratkaisu. Kertovan raportoinnin kokonaisuus rakennettiin osaksi intranetiä hyödyntämällä mahdollisuuksien mukaan Sharepointin omia toiminnallisuuksia.

–Asiakkaan esittämän tarpeen ratkaiseminen edellyttää IT-toimittajalta myös malttia – että ei lähdetä heti rakentamaan uutta tietojärjestelmää, vaan katsotaan mitä jo valmiina olevasta voidaan hyödyntää. Profit Software ymmärsi tämän tarpeemme erinomaisesti ja he lähtivät ratkomaan haastetta meidän kannaltamme järkevällä tavalla, Saartoala sanoo.

Kertovan raportoinnin suurimpia haasteita ovat aikataulut ja raportin kirjoittamiseen osallistuvien henkilöiden työn koordinointi. Järjestelmän rakentamisen aikana LähiTapiolassa myös huomattiin, että eri raportteihin sisältöä tuotetaan eri tavalla, eli kehitettävän toimintamallin ja sitä tukevan tietojärjestelmän piti olla myös joustava.

–Ryhmässä ja yhtiöissä raporttien kirjoittamiseen, muokkaamiseen ja julkaisemiseen osallistuvat niin ylimmän johdon edustajat, johtavat asiantuntijat kuin myös viestintäihmiset. Uuden järjestelmän myötä raporteista vastaavat henkilöt tietävät tarkemmin mikä kunkin raportin tilanne on ja voivat tukea työtä paremmin. Lisäksi kaikkien raporttien tuottamiseen osallistuvien henkilöiden työaikaa säästyy, kun prosessi on selvä ja sitä tukeva Sharepoint-toteutus on helppokäyttöinen, kertoo riskienhallintapäällikkö Annina Pietinalho LähiTapiolan riskienhallintapalveluista.

Tietojärjestelmä, jonka käyttäjät haluavat ottaa käyttöön

Projekti toteutettiin iteroiden, joka edellytti tiivistä yhteistyötä LähiTapiolan ja Profit Softwaren tiimien välillä. Toteutustapa valittiin tällaiseksi myös siksi, että tarkkaa teknistä määrittelyä ei lopputuloksesta ensin tehty, vaan IT:n sijasta pääosissa olivat LähiTapiolan toivoma toimintaprosessi ja tulevan järjestelmän käyttäjien toiveet.

–Haimme molemmat käytännönläheisiä, jokapäiväisessä työssä toimivia ratkaisuja. Olimme erittäin tyytyväisiä Profit Softwaren tiimin joustavaan toimintaan ja itsekin pyrimme välttämään turhaa byrokratiaa, Saartoala kertoo.

LähiTapiolassa ollaan oltu varsin tyytyväisiä uuteen järjestelmään, se on vastannut ennalta asetettuja prosessikuvauksia ja on osoittautunut helpoksi omaksua.

–Olen meillä kouluttanut henkilöitämme ottamaan käyttöön uuden toimintaprosessin ja järjestelmän raporttien tuottamiseen. Saamani palaute on ollut positiivista, käyttäjät ovat kokeneet, että sovellus on oikeasti tukenut raportointityötä. Sovelluksen käyttö ei edellytä kokonaan uusien ohjelmistojen tai järjestelmien omaksumista, mikä helpottaa loppukäyttäjän arkea. Olemme ottamassa ratkaisua laajemminkin käyttöön esimerkiksi vuosikertomuksen ja hallituksen toimintakertomuksen tuottamisessa, kertoo matemaatikko Ville Lilja LähiTapiolasta.