Cloud eller eget serverrum: Budgetposter og beregningsmodel

Cloud eller eget serverrum: Samme belastning og budgetperiode

Det er nærliggende at stille to tilbud op side om side og sammenligne vCPU, RAM og lagerplads. Men to servere med samme specifikationer kan være bygget på vidt forskellige platforme.

Byg sammenligningen på jeres egne omkostningstal for cloud og eget serverrum. Brug samme budgetperiode, samme arbejdsbelastning og samme krav til drift og gendannelse. Sammenlign først det samlede månedsbudget og derefter prisen pr. anvendt kapacitetsenhed, hvis enheden beskriver samme leverance i begge modeller.

Eget serverrum kaldes også on-premise. Microsoft Azure, AWS og Google Cloud er eksempler på public cloudleverandører (Sentia). Budgetgrundlaget er de valgte ydelser og den konkrete aftale, så leverandørens navn alene fortæller ikke, hvad løsningen koster.

For et typisk SMV-produkt findes der ikke et generelt månedsbeløb for cloud-drift på AWS, Azure eller Google Cloud. Prisen afhænger af jeres eget forbrug, og udbydernes prismodeller er svære at sammenligne (Weapp). Beløbet skal derfor hentes i jeres egen aftale og beregnes ud fra jeres brugsmønster, ikke et fast tal.

Opgør indkøb, aftaler, forbrug og internt arbejde som månedlige budgetposter. Hent beløbene fra fakturaer, tilbud og aftaler, og beregn de variable poster ud fra jeres forventede brug. Læg posterne sammen for hver driftsmodel, før totalen deles med den kapacitet, der faktisk anvendes.

Cloud skal ifølge Peytz nedbringe virksomhedens udgifter til hardware, software, drift og administration markant. Det er den påstand, de to kolonner skal efterprøve med jeres egne beløb i kroner pr. måned.

Tallet er kroner pr. måned divideret med den kapacitet, der reelt bruges. Dimensioneres der efter ét månedligt peak, bliver setuppet alt for stort i 29 dage, indtil der den ene dag er brug for den store regnekraft. Prisen pr. udnyttet enhed bliver derfor højere end prisen pr. provisioneret enhed.

Ifølge Rackhosting kan den ene være en relativt simpel virtuel server. Den anden kan ligge på en redundant platform med enterprise storage, snapshots, backup, redundante netværk og mulighed for disaster recovery. Prissedlen dækker ikke det samme, selv om specifikationerne er identiske.

Cloud hosting handler derfor ikke kun om CPU, RAM og pris. Hvor data ligger, hvem der driver infrastrukturen, og hvordan backup, sikkerhed og drift er skruet sammen, er mindst lige så vigtigt (Rackhosting).

Den samlede økonomi har også poster uden for spec-listen. Det gælder strøm og service på eget udstyr, backup og redundans, dataplacering, sikkerhed og hvor stor en del af den betalte kapacitet, du reelt bruger.

Forskellen er ikke, om der betales, men hvornår og for hvad. Eget serverrum betales forud i hardware og derefter løbende i strøm, service og driftstimer. Cloud betales løbende; i abonnementsmodeller kan prisen følge antallet af pladser og stige, når organisationen vokser.

Cloududbydernes prismodeller er svære at sammenligne, fordi omkostningen afhænger af brugen. En platform, der ser billig ud i et regneeksempel, kan blive den dyreste i praksis (Weapp). Sammenlign derfor på jeres eget brugsmønster, ikke på listepriser.

Hver post skal ende som et beløb i kroner pr. måned, ellers kan den ikke lægges ind i kolonnen. Det gælder både cloud og eget serverrum.

Det tal, der flytter mest i beregningen, er udnyttelsesgraden. Uden en målt udnyttelsesgrad i begge kolonner kan de to modeller ikke sammenlignes.

Eget serverrum opgøres af strøm, service, hardware og afskrivning, køling, UPS/batteribackup, fysisk sikring, overvågning, patching og driftstimer uden for normal arbejdstid. Hver post skal have sit eget beløb i kroner pr. måned.

Hardware på eget udstyr betales forud og afskrives over tid, mens cloud er en løbende driftsudgift. Det flytter de store beløb fra et engangskøb til en løbende månedspris.

Cloud opgøres af forbrug af regnekraft og lagerplads, pladser pr. bruger, licenser, backup og snapshots, disaster recovery, dataplacering og de kompetencer, der skal til for at drive løsningen.

Cloudkolonnen bygges af udbydernes listepriser og jeres egen aftale. Eget-serverrum-kolonnen bygges af fakturaer for strøm, service og hardware. Først når begge kolonner har beløb i kroner pr. måned, er regnestykket komplet.

Budgetposter i eget serverrum: udstyr, strøm og drift

Den mest håndgribelige besparelse ved cloud er strømregningen til den fysiske server på kontoret plus eventuel service på den (nhl-data.dk). Begge poster forsvinder ud af budgettet, når serveren forlader lokalet.

Mål serverens elforbrug over en repræsentativ periode, og omregn det til månedens kWh. Strømposten beregnes som månedens kWh gange den anvendte pris pr. kWh; brug fakturaens relevante priselementer og samme momsgrundlag som i resten af budgettet. Mærkeeffekten på strømforsyningen er ikke en måling af serverens faktiske forbrug.

Kølingens energiforbrug skal med i strømposten for et eget serverrum.

Fordel indkøbsbeløbet for servere, storage og netværksudstyr over den periode, budgettet dækker. Den månedlige fordeling er indkøbsbeløbet divideret med periodens antal måneder; brug samme princip for tilhørende installation. Medtag ikke både hele indkøbet og den månedlige fordeling i samme omkostningstotal, men vis engangsbetalingen særskilt i likviditetsbudgettet.

På eget udstyr betales hardware, licenser og infrastruktur forud og afskrives over år. Cloud reducerer netop udgiften til dyrt IT-hardware, licenser og infrastruktur, fordi man kun betaler for det, man bruger – ikke for overhead (Peytz).

Bliver serveren stående, består udgifterne af flere lag. Ud over strøm og service kommer indkøb og afskrivning af servere, storage og netværksudstyr, køling, UPS/batteribackup, fysisk sikring af lokalet, overvågning, opdatering og patching samt en person, der har ansvaret, når noget fejler uden for normal arbejdstid.

Køling, UPS/batteribackup og fysisk sikring opgøres ud fra de installationer og serviceaftaler, serverrummet kræver. Fordel fælles udgifter efter en dokumenteret fordelingsnøgle, og undgå at medtage kølingens strømforbrug igen, hvis det allerede indgår i elmålingen. Overvågning, patching og beredskab beregnes som forventede arbejdstimer gange den interne timeomkostning eller ud fra en ekstern driftsaftale.

Flere af posterne skalerer ikke med belastningen. De løber, uanset om maskinen bruges eller ej.

Ingen af disse poster har en fælles listepris. De skal prissættes enkeltvis i kroner pr. måned for det udstyr, I vælger, og deles med den kapacitet, der reelt bruges.

Cloud fjerner ikke alle disse poster. Strøm og service på eget udstyr forsvinder, men backup, redundans, sikkerhed og dataplacering er stadig omkostninger. De flytter fra dit budget til en leverandørs prisliste, hvor de er sværere at gennemskue, fordi de ikke står på en spec-liste over vCPU og RAM.

Eget serverrum giver fysisk kontrol over hardware og dataplacering, mens cloud giver mulighed for hurtig skalering (Peytz) og driftsmæssig enkelhed via abonnementer.

De to modeller kan derfor ende med hver sin pris for samme system. Belastningens størrelse og stabilitet er blandt de forhold, der påvirker, hvilken model der giver de laveste langsigtede omkostninger.

Strømforbruget ganges med elprisen pr. kWh og fordeles pr. måned. Brug prisen fra jeres egen aftale eller faktura.

Brug en gennemsnitspris over en repræsentativ periode i strømposten. Lad ikke månedsbudgettet afhænge af prisen på én enkelt dag.

Service og support er en selvstændig budgetpost. Fordel beløbet på aftalens dækningsperiode, og kontrollér, om samme support allerede indgår i en anden aftale.

Budgetposter i cloud: abonnement, forbrug og kapacitet

Cloud betales typisk løbende – som abonnement pr. måned, pr. bruger eller efter forbrug af regnekraft og lagerplads. Prisen bliver en driftsudgift frem for en hardwareinvestering, men regningen fortsætter, så længe løsningen kører.

Cloud kan være en færdig tjeneste eller en løsning, hvor virksomheden selv administrerer virtuelle servere. Jo mere kontrol virksomheden har over systemet, desto større bliver dens eget ansvar for drift og sikkerhed. Budgettér derfor efter den konkrete ansvarsfordeling frem for at behandle alle cloudløsninger som fuldt administrerede.

Alle tre udbydere i toppen kan levere en komplet portefølje af services og en høj grad af sikkerhed (Sentia). Teknikken er derfor sjældent det, der afgør valget – og dermed heller ikke det, der afgør prisen.

Cloudkolonnen får listepriser fra udbyderne, men de er ikke det endelige tal. Beløbet pr. måned afhænger af jeres forbrug og af, hvor stor en del af kapaciteten der reelt bruges (Weapp; Peytz).

Der findes ikke én fælles cloudpris i kroner pr. måned for AWS, Azure eller Google Cloud. Prisen afhænger af brugen, og en platform, der ser billig ud i et regneeksempel, kan blive den dyreste i praksis (Weapp).

Den pris, du betaler, er ikke nødvendigvis den reelle omkostning, hvis en del af den provisionerede kapacitet ikke udnyttes.

Betaler du for mere kapacitet, end du bruger, ligger prisen pr. brugt enhed over listeprisen. Regn derfor ikke på pris pr. provisioneret enhed, men på pris pr. udnyttet enhed.

Arkitekturvalgene kan påvirke driftsomkostningen, allerede før systemet bygges.

Cloud giver mulighed for hurtig skalering (Peytz), mens udvidelse af lokal kapacitet kan kræve køb af hardware. Beskriv i budgettet, hvornår kapaciteten forventes skaleret op og ned, og hvem der udfører ændringerne. Udnyttelsesgraden skal måles i begge modeller; den er ikke automatisk fast i eget serverrum eller høj i cloud.

I abonnementsmodeller kan prisen følge antallet af pladser og stige, efterhånden som antallet af brugere vokser. En fast cloudpris pr. måned er derfor sjældent fast, hvis organisationen vokser.

Skeln mellem kapacitet, der er til rådighed, kapacitet, der er i brug, og forbrug, der faktureres. En løsning, som kan skaleres ned, giver først en budgetmæssig besparelse, når aftalens betalingsvilkår og den faktiske drift tillader det. Registrér derfor både driftsperioder og eventuelle faste kapacitetsbetalinger.

Brug jeres belastningsmønster og aftalens vilkår til at budgettere posterne.

AWS har historisk tiltrukket teknisk tunge virksomheder, der udvikler egne applikationer, ofte Linux-baserede (Sentia). Mængden af valgmuligheder kan virke overvældende for nye brugere, og hver valgmulighed er en post, der kan prissættes.

Uforudsete poster hører også til cloudkolonnen. Dataoverførsel, support, ekstra lagerplads og ændringer ved kontraktfornyelse kan være poster, der skal med. Overdimensionerede ressourcer bør gennemgås, så budgettet følger det faktiske forbrug.

En cloudaftale kan indeholde både faste pladser og variable forbrugspriser. Skriv de to dele op hver for sig, så den faste og den variable del af regningen ikke blandes sammen.

Betalingen følger pay-as-you-go-princippet, hvor kun den kapacitet, man anvender, betales. En løsning kan modtage 600.000 nye brugere den ene dag og skaleres ned til 10.000 den næste, og 100 nye instanser kan etableres på et øjeblik (Peytz).

Beregn regnekraft som forventet faktureret forbrug gange den aftalte enhedspris, og læg eventuelle faste kapacitetsbetalinger til. Beregn lager på samme måde med aftalens definition af lagermængde og periode. Kontrollér særskilt, om læse- og skriveoperationer, dataoverførsel og ekstra kopier af data udløser betaling, så budgettet følger den faktiske afregningsmodel.

Adgangen til kompetencer er den mest undervurderede post. En platform, man ikke kan finde folk til, bliver dyr og sårbar, fordi hver ændring bliver dyr og afhængigheden af enkeltpersoner stor (Weapp). En marginalt billigere drift betyder ikke meget, hvis løsningen ikke kan bemandes.

Cloududgifter består ikke kun af regnekraft og lagerplads. Microsoft har gjort det muligt at købe Microsoft 365 Business Premium eller Business Standard samlet med Microsoft 365 Copilot Business i én bundle-licens. Ifølge nhl-data.dk giver samlelicensen en markant besparelse på Copilot.

Beløbet for samlelicensen skal hentes i den konkrete licensaftale; uden et beløb i kroner kan posten ikke lægges ind i cloudkolonnen.

Saml cloudposterne i samme valuta og på samme momsgrundlag som budgettet for eget serverrum. Når en pris er i dollars, omregnes det beregnede månedsbeløb med budgettets valgte valutakurs. Gem kurs, enhedspris, forbrug og aftalevilkår sammen med beregningen, så ændringer i regningen kan forklares.

I Azure kan virksomheder reducere omkostningerne ved at bruge eksisterende Windows Server- og SQL Server-kernebaserede licenser med Software Assurance eller et abonnement (Microsoft Azure). Undersøg i den konkrete beregning, om virksomheden kan udnytte denne mulighed.

Læg regnekraft, lager, brugerabonnementer, licenser og øvrige betalte ydelser sammen til cloudens månedsbudget. Medtag kun en licens særskilt, hvis den ikke allerede er indeholdt i en anden pris. Hold kapacitetsudnyttelsen uden for omkostningssummen; den bruges bagefter til at beregne prisen pr. anvendt enhed.

Backup, redundans og sikkerhed i driftsbudgettet

Redundans og backup blandes ofte sammen, men løser to forskellige opgaver. En redundant cloud-platform håndterer fejl i dele af infrastrukturen uden nødvendigvis at påvirke driften.

Backup, snapshots og disaster recovery skal hver have et beløb i kroner pr. måned i begge kolonner. De kan ikke lægges sammen til én sikkerhedspost.

Backup løser noget andet. Ved sletning, ødelæggelse eller ransomware hjælper det ikke nødvendigvis, at serverplatformen er redundant. En hostingløsning bør derfor vurderes ud fra flere lag (Rackhosting).

Ransomware, sletning og korruption rammer data – ikke den underliggende platform. Derfor hjælper redundans ikke nødvendigvis, og backup løser en anden opgave (Rackhosting).

Et snapshot fastholder en tilstand, mens backup skal understøtte gendannelse af data, og disaster recovery omfatter genetablering af driften. Beskriv formål, opbevaring og gendannelsesmulighed for hver funktion. Afklar derefter, hvilke funktioner der er inkluderet i platformen, og hvilke der kræver særskilt lager, aftaler eller arbejde.

Backup, snapshots og disaster recovery har ingen fælles listepris. De skal prissættes særskilt i begge kolonner. For forretningskritiske systemer kan længere nedetid hurtigt blive dyr (Rackhosting).

Enterprise storage, snapshots, redundante netværk og mulighed for disaster recovery kan variere fra platform til platform. De fremgår ikke af en specifikation som antal vCPU og RAM (Rackhosting).

To cloud-servere med samme antal vCPU og samme RAM kan derfor være bygget på vidt forskellige platforme (Rackhosting).

For en forretningskritisk applikation, database, webshop eller ERP-løsning kan længere nedetid hurtigt blive dyr (Rackhosting). Derfor bør en hostingløsning vurderes ud fra hele infrastrukturen og ikke kun ud fra serverens specifikationer (Rackhosting).

Spørgsmålet om, hvad redundans koster, hænger derfor sammen med, hvor kritisk den understøttede løsning er. For forretningskritiske systemer kan længere nedetid hurtigt blive dyr (Rackhosting).

For et internt testsystem er svaret et andet end for en webshop.

Redundans og backup skal vurderes hver for sig, selv når de sælges i samme pakke. Registrér pakkens samlede pris og de funktioner, den omfatter, i stedet for at lægge den samme betaling ind flere gange. Tilføj kun merudgifter til de funktioner eller den kapacitet, der mangler.

On premise kan se økonomisk attraktivt ud, når de månedlige driftspriser holdes op mod en allerede afskrevet server. Hardwarefornyelse, licenser, sikkerhedsværktøjer, strøm, backupkapacitet, specialisttimer og beredskab skal med i den samlede omkostning.

Backup prissættes efter, hvor meget data der kopieres, hvor ofte, hvor længe kopierne opbevares, og hvor hurtigt de skal kunne gendannes. Det er de knapper, der styrer beløbet i kroner pr. måned.

Kritiske omkostningsfaktorer i begge modeller

Dataplacering, GDPR og kontrol: Krav og driftsarbejde

Når man køber cloud hosting, er det første spørgsmål: Hvor ligger vores data? Svaret er ikke altid enkelt. Data kan ligge i ét land, backup i et andet, og platformen kan omfatte leverandører og underleverandører på tværs af landegrænser.

Dansk hosting handler derfor ikke kun om, at der står en server i Danmark. Det handler også om, hvem der driver infrastrukturen, hvor backup befinder sig, hvilke underleverandører der anvendes, og hvem der har adgang til miljøet (Rackhosting).

For nogle virksomheder er det uproblematisk. For andre – med persondata, følsomme oplysninger eller særlige compliancekrav – kan det være afgørende at have bedre kontrol over både data og infrastrukturen bag (Rackhosting).

Rammen for det er GDPR. Europa-Kommissionen vedtog den 10. juli 2023 en tilstrækkelighedsafgørelse for EU-U.S. Data Privacy Framework efter EU-Domstolens Schrems II-afgørelse fra 2020 (Datatilsynet). Virksomheder skal fortsat afdække overførsler af personoplysninger til USA i hele databehandlerkæden og opdatere bilag B i standard databehandleraftale fra Datatilsynet (Kromann Reumert).

Kontrol er en omkostningsdriver. Den kan betyde et andet platformvalg, et andet backup-setup eller en dyrere leverandør, der kan dokumentere placering og adgang.

Brug dataplacering som et krav til løsningen, før tilbuddene sammenlignes. Hvis kravet ændrer valg af platform, backup eller driftsaftale, skal budgettet afspejle prisen på den valgte løsning. Dataplacering er dermed ikke automatisk et særskilt tillæg til en pris, der allerede omfatter den ønskede placering.

Praktisk betyder det, at dataplacering skal ind i regnearket som en selvstændig post. Dertil følger spørgsmålene: Hvor ligger primærdata, hvor ligger backup, hvilke underleverandører indgår, og hvem har adgang til miljøet?

Notér placering af primærdata og backup, underleverandører og adgangsforhold sammen med hvert tilbud. Beregn særskilt det interne eller eksterne arbejde, der kræves for at kontrollere og dokumentere forholdene. Medtag en ekstra betaling, hvis den faktisk følger af aftalen, men undgå at opfinde en særskilt pris for hvert kontrolkrav.

Kontrolkrav og udgiftsposter har forskellige roller i budgettet. Kravet afgør, om løsningen kan vælges, mens fakturaer, aftaler og arbejdstid afgør, hvilke beløb der skal med. Hold derfor kravene synlige uden at tælle en inkluderet funktion som en ekstra omkostning.

Kan svaret ikke gives entydigt, er der en risiko og et kontrolarbejde, som endnu ikke er prissat.

Fysisk placering alene afgør ikke, hvor meget sikkerhedsarbejde virksomheden skal udføre. Cloududbyderens certificeringer dækker ikke nødvendigvis kundens egne efterlevelseskrav. Afsæt derfor ressourcer til virksomhedens egne opgaver med adgang, konfiguration og dokumentation frem for at antage, at de forsvinder ved flytningen.

Den offentlige sektor har ofte krav og forventninger, der taler for, at data bliver i Europa. Særligt følsomme data, for eksempel helbredsoplysninger, gør spørgsmålet tungere – og i de situationer vejer juraen tungere end bredden, så et europæisk alternativ giver mening (Weapp).

Sørg for en databehandleraftale med cloudleverandøren, og afklar placeringen af data og adgangsforhold.

Eget udstyr giver fysisk kontrol, men også ansvar for strøm, køling, hardwareudskiftning, netværk, overvågning, backup og beredskab. Opgør derfor både de købte ydelser og den arbejdstid, virksomheden fortsat skal levere.

Et europæisk alternativ kan være relevant, når jura og dataplacering vejer tungere end bredden (Weapp).

Mellemvejen: Budget for eget udstyr i et datacenter

Mellem eget serverrum og fuld cloud ligger leje af rack eller plads i et professionelt datacenter. Virksomheden ejer stadig hardwaren, men køber strøm, køling, fysisk sikkerhed og netadgang hos udbyderen.

Hent pladsprisen og afregningsvilkårene i datacenterets tilbud. Afklar, om strøm, køling, fysisk sikkerhed og netadgang er inkluderet, forbrugsafregnet eller særskilt prissat. Brug derefter aftalens opdeling i budgettet, så inkluderede ydelser ikke lægges til igen.

Mellemmodellen ændrer ikke på, at hardwaren skal købes og afskrives. Den flytter kun strøm, køling, fysisk sikkerhed og netadgang over på udbyderens faktura.

Datacenter-tjenester kan variere, og det bør indgå som en driftsomkostning, når prisen pr. rack eller plads sammenlignes.

Undersøg også, om plads- eller driftsaftalen omfatter backup, snapshots og disaster recovery. Sammenlign funktionernes omfang med cloudtilbuddet, og tilføj kun de ydelser og den kapacitet, der mangler. En lav pladspris kan ikke vurderes isoleret fra det arbejde og den infrastruktur, virksomheden selv skal levere.

Pladsprisen er en del af mellemmodellens budget, ikke hele dens totalomkostning. Læg den månedlige hardwarefordeling, særskilt afregnet forbrug, licenser, manglende backupfunktioner og virksomhedens driftstid til. Sammenlign først den samlede månedsudgift med cloud, og brug derefter samme kapacitetsmål til at vurdere udnyttelsen.

Sammenlignet med cloud flytter denne model ansvaret for platformen tilbage til virksomheden. Backup, redundans, snapshots og disaster recovery er fortsat egne poster, som skal dimensioneres og betales – de forsvinder ikke, fordi udstyret står i et datacenter.

Til gengæld giver modellen kontrol over hardware, dataplacering og de underleverandører, der indgår. Det er her, den adskiller sig fra public cloud.

Rackprisen skal derfor deles med den kapacitet, der reelt bruges, før den kan stå i samme kolonne som cloud.

Prisen pr. rack eller plads skal hentes hos den konkrete datacenterudbyder og lægges sammen med hardware, backup, snapshots og disaster recovery.

Bed om et tilbud, der skelner mellem plads, forbrug og driftsydelser. Afklar også, hvilke opgaver tilbuddet overtager, og hvilke timer, aftaler og indkøb virksomheden stadig skal budgettere med.

Beregn månedsbudget og pris pr. anvendt kapacitetsenhed

Regnearket skal have to kolonner: cloud og eget serverrum. Hver række skal have et beløb i kroner pr. måned; poster uden beløb kan ikke indgå i sammenligningen.

Sæt følgende poster op som rækker i et regneark: hardware og afskrivning, strøm og køling, service og vedligehold, interne driftstimer til overvågning og patching.

Sammenlign den fulde totalomkostning over den periode, budgettet dækker, ikke kun månedsprisen.

Cloudkolonnen får udbydernes listepriser. Eget-serverrum-kolonnen får strøm, service, hardware, køling, UPS, sikring, overvågning, patching og driftstimer.

Tilføj udgifter til backup, redundans, snapshots, disaster recovery, sikkerhed og kontrolarbejde, hvor de ikke allerede er inkluderet. Hold krav til dataplacering og underleverandører i særskilte felter ved siden af budgetposterne. Registrér også kapacitetsudnyttelse og skaleringsmuligheder som beregningsforudsætninger, ikke som ekstra beløb i omkostningssummen.

Cloudkolonnen bygges ud fra jeres eget forventede brugsmønster, ikke ud fra listepriser (Weapp). Eget-serverrum-kolonnen bygges af strøm og service fra jeres egne fakturaer (nhl-data.dk).

Læg en række ind for licenser. Cloud reducerer udgiften til licenser og infrastruktur (Peytz), men Microsoft 365 Copilot Business kan købes samlet med Business Premium eller Business Standard i én bundle-licens (nhl-data.dk).

To kolonner er nok: én for cloud og én for eget serverrum. Begge skal ende i samme enhed, nemlig pris pr. måned pr. udnyttet kapacitetsenhed.

Det betyder danske kroner pr. måned divideret med den kapacitet, der reelt bruges. Med et månedligt peak bliver setuppet dimensioneret efter peaket og står alt for stort i 29 dage (Peytz), så prisen pr. udnyttet kapacitetsenhed bliver højere end prisen pr. provisioneret enhed.

Læg jeres cloudbeløb og jeres eget-serverrum-beløb ved siden af hinanden. Del begge tal med den samme, reelt anvendte kapacitet, og I har prisen pr. udnyttet kapacitetsenhed i begge kolonner.

Brug fakturaer og aftaler til at dokumentere de udgifter, der allerede betales. Supplér med tilbud på nye indkøb og med forventet forbrug og arbejdstid. Notér for hver budgetpost, om beløbet bygger på en eksisterende betaling, et tilbud eller et skøn, så usikkerheden kan vurderes uden at skjule den i totalen.

Månedsbudgettet for eget serverrum er summen af den månedlige hardwarefordeling, strøm, køling, service, licenser, backup, fysisk sikring og driftstid. Cloudbudgettet er summen af faste abonnementer, beregnet forbrug, særskilte licenser, dataoverførsel, backup, support og virksomhedens resterende driftstid. Fjern overlap i begge summer, så en ydelse, der indgår i en aftale, kun tælles med gennem aftalens pris.

Skaleringen har sine egne tal: 100 nye instanser kan etableres på et øjeblik, og en løsning kan modtage 600.000 nye brugere én dag og skaleres ned til 10.000 den næste (Peytz). Den forskel hører hjemme i cloudkolonnen som en udnyttelsesgrad.

Beregn budgettet for både den normale belastning og spidsbelastningen med de samme forudsætninger i begge modeller. Beskriv, hvor længe hver belastning varer, og hvilken kapacitet der skal være til rådighed. Lad aftalernes betalingsvilkår afgøre cloududgiften, og lad det nødvendige udstyr og driftsarbejde afgøre udgiften til eget serverrum.

Vis ubrugt kapacitet som en analyse af det budget, der allerede er opgjort. Betalingen for kapaciteten ligger i totalen og skal ikke lægges til igen som en ekstra udgift. Registrér i stedet betalt kapacitet og faktisk anvendelse, så det bliver synligt, hvor en nedskalering eller bedre udnyttelse kan ændre økonomien.

Strøm og service til den lokale server falder væk, hvis udstyret flytter ud (nhl-data.dk). De skal stå som egne rækker i kolonnen for eget serverrum, så besparelsen kan læses direkte.

Før dem igennem for begge modeller. Noter for hver post, hvem der ejer den, og om den er en fast eller variabel udgift.

Stil de samme spørgsmål til begge løsninger: Hvor ligger data, og hvor ligger backup? Hvilke underleverandører er involveret, og hvem har adgang til miljøet?

Er redundans og backup dækket som to separate funktioner, og hvad sker der ved datatab, korruption eller ransomware? Hvad koster nedetid for den applikation, serveren understøtter? Og hvor stor en del af den kapacitet, vi betaler for, bruger vi reelt?

Prisen pr. anvendt kapacitetsenhed er det samlede månedsbudget divideret med månedens anvendte enheder. Brug samme definition i begge modeller, eksempelvis gennemførte opgaver for den samme applikation under ens driftskrav. Læg ikke vCPU, RAM og gigabyte sammen til en fælles kapacitetsmængde; uden et ensartet mål bør sammenligningen ske på månedsbudgettet for samme arbejdsbelastning.

Uden et tal for udnyttelsesgrad i begge kolonner kan de to modeller ikke sammenlignes. En hardwarefaktura og en cloudregning bliver først sammenlignelige, når begge er delt med den kapacitet, der reelt bruges.

Tilføj en række for kompetencer. En platform, I ikke kan finde folk til, bliver dyr og sårbar, og en marginalt billigere drift betyder ikke meget, hvis løsningen ikke kan bemandes (Weapp).

Start med to konkrete tal: jeres cloudaftale og jeres eget-serverrum-regning, begge i kroner pr. måned. Del hvert tal med den kapacitet, der reelt bruges, og før dem ind i hver sin kolonne.

Brug fakturaer for strøm, service og hardware som kilde til eget-serverrum-kolonnen. Cloudkolonnen bygges af aftalen om forbrug, pladser og licenser. Så står begge kolonner med beløb i kroner pr. måned.

Sammenligning af månedsomkostninger: Cloud vs. eget serverrum

Sammenhold budget, kapacitetsudnyttelse og driftsansvar

Det konkrete svar på, hvad cloud koster sammenlignet med eget serverrum, står i to kolonner med kroner pr. måned. Uden beløb for begge modeller er der ingen sammenligning.

Cloud kan fjerne strømregningen til den fysiske server og den service, man har haft på den (nhl-data.dk), men til gengæld betaler man løbende.

Cloudpriserne skal holdes op mod jeres eget forbrug. Eget-serverrum-kolonnen skal have strøm, service, hardware, backup og driftstimer i kroner pr. måned.

Der findes ingen fælles cloudpris i kroner pr. måned for AWS, Azure eller Google Cloud. Omkostningen afhænger af jeres eget forbrug, og udbydernes prismodeller er svære at sammenligne (Weapp).

Prismodellerne er svære at gennemskue, og en platform, der ser billig ud i et regneeksempel, kan blive den dyreste i praksis (Weapp). Det gælder, uanset om regnestykket laves for cloud eller for eget udstyr.

Eget serverrum giver kontrol over hardware og dataplacering, men kræver investering i hardware, drift, backup og redundans. Redundans er ikke det samme som backup, når data mistes, ødelægges eller krypteres af ransomware (Rackhosting).

Det tal, der kan afgøre sammenlægningen, er udnyttelsesgraden. Betaler man for mere kapacitet, end man bruger, koster hver brugt enhed mere end listeprisen.

Sammenligningen har et konkret format: kroner pr. måned pr. udnyttet kapacitetsenhed i begge kolonner. Dimensioneres eget udstyr efter et månedligt peak, står setuppet alt for stort i 29 dage (Peytz), og prisen pr. brugt enhed bliver højere end prisen pr. provisioneret enhed.

Der er ingen listepris, der kan afgøre valget. Forskellen ligger i udnyttelsesgraden og i, hvor mange poster der flytter med fra hardware til abonnement.

Svaret afhænger af to forhold, som begge kan besvares konkret: Hvor meget af den kapacitet, vi betaler for, udnytter vi reelt? Og hvem har ansvaret for backup, redundans og dataplacering – og kan de entydigt svare på, hvor data og backup befinder sig, og hvilke underleverandører der indgår?

Cloud er ikke en fast pris. Betalingen følger pay-as-you-go, og 100 nye instanser kan etableres på et øjeblik (Peytz). Det gør cloudkolonnen nem at skalere op – og let at betale for kapacitet, der ikke bruges.

Der findes ikke et generelt månedsbeløb for cloud-drift på AWS, Azure eller Google Cloud. Tallet skal hentes i jeres egen aftale og først bruges, når det er delt med den kapacitet, I reelt bruger, og holdt op mod jeres egne fakturaer for strøm, service og hardware.

Adgangen til kompetencer vejer tungere end prisen pr. beregningsenhed i et regneark. Spørg derfor ikke kun, hvad platformen koster, men hvor let det er at finde mennesker, der mestrer den (Weapp).

Cloud koster det, der står i aftalen med AWS, Microsoft Azure eller Google Cloud, opgjort i kroner pr. måned pr. udnyttet kapacitetsenhed. Eget serverrum koster strøm, service, hardware, køling, UPS, sikring, overvågning, patching og driftstimer i samme enhed.

Sammenligningen har et fast format: kroner pr. måned pr. udnyttet kapacitetsenhed. Fyld begge kolonner med jeres egne tal, og genberegn, når aftalen eller belastningen ændrer sig.

Start med strøm og service, fordi de allerede står på en faktura i kroner i dag. Byg resten af kolonnen op post for post, indtil begge modeller står med et beløb pr. måned og kan lægges sammen.