Sådan sammenligner du cloud, on-premise og hybrid som driftsmodel

Sammenligningsgrundlag: hvor ligger data, og hvem driver hvad?

De tre modeller handler om, hvor software og data ligger, og hvem der vedligeholder og opgraderer dem. On-premise betyder „på stedet“: løsningen står fysisk hos virksomheden selv. I cloud kan kapaciteten følge behovet via abonnementer, mens en server hos virksomheden selv giver fysisk kontrol over data. Hybrid er ikke en selvstændig teknik, men en sammensætning af de to øvrige modeller.

Før du sammenligner økonomi og funktioner, bør du for hver komponent fastlægge fire ting: hvor data fysisk ligger, hvem der patcher og opgraderer, hvor længe data bliver liggende, og hvordan de kommer ud igen, hvis aftalen ophører. Svarene viser, om du reelt har én model, eller om du har en hybrid med delt ansvar mellem flere parter. Bed om svarerne på skrift i aftalen frem for i salgsmateriale, så ansvarsgrænsen kan efterprøves senere.

Stil sammenligningen op som en matrix med de tre modeller som kolonner og kriterierne som rækker: dataplacering, hvem der patcher og opgraderer, skalering, oppetid, krav ved overførsel af personoplysninger, interne driftskompetencer, økonomi og vilkår ved ophør. Giv hvert kriterium en vægt efter, hvor afgørende det er for jer, og giv hver model en score. Så bliver forskellene målbare, og I kan se, hvor I stadig mangler svar.

Cloud: fleksibilitet og enkelhed – men med dilemmaer

Cloud er stærkest, når behovet svinger, og når du helst vil slippe for at eje og drive servere. Cloud computing giver hurtig skalering og driftsmæssig enkelhed via abonnementer. Abonnementer gør udgifterne fleksible, men bør sammenlignes med investering og drift af egen hardware, før du vælger.

Konkret kan kapaciteten følge aktiviteten i stedet for at være dimensioneret efter et maksimum. Hardwarevedligeholdelse og opgraderinger flyttes over på leverandøren.

Sammenlign oppetid konkret. Microsoft har et internt mål om at holde den månedlige oppetidsprocent over 99,5 % for Kubernetes API-serveren på det gratis niveau af Azure Kubernetes Service og henviser til serviceniveauaftalen for tjenesten (azure.microsoft.com). Skriv både udbyderens navn og det oppetidsniveau, du bliver stillet i udsigt, ind i matrixen.

Valget er dog ikke entydigt. Dansk IT's fagråd for Business & IT Alignment har erfaret, at der rejser sig en række dilemmaer for danske virksomheder og organisationer, der arbejder med cloud-løsninger; fagrådets publikation „Cloud computing – 10 dilemmaer“ samler dem. Derfor bør du afklare dataplacering, afhængighed af én leverandør, integration mod eksisterende systemer og adgangen til egne data ved ophør, inden du skriver under.

Microsoft oplyser, at priserne på Azures prissider kun er estimater og ikke faktiske pristilbud, og at de faktiske priser afhænger af aftaletypen med Microsoft, købsdatoen og valutakursen (azure.microsoft.com). Hent derfor tal i prisberegneren, og bed om et skriftligt tilbud. Rabat opnås ved at forpligte sig til et fast timebeløb i 1 eller 3 år eller ved at købe en reservation på et eller tre år for en bestemt instans (azure.microsoft.com).

On-premise: kontrol og datasuverænitet – mod større driftsansvar

On-premise er modpolen: løsningen står „på stedet“, og virksomheden har fysisk kontrol over serverne og dataenes placering. Modellen er relevant, hvis et konkret krav eller et bevidst valg kræver, at data bliver i egne lokaler. Du bestemmer selv over hardware, netværk og opgraderingsrytme og er ikke afhængig af en leverandørs skalerings- og prisvilkår.

Prisen er, at ansvaret for vedligeholdelse og opgraderinger bliver dit eget. Det omfatter løbende patching, overvågning, backup og test af gendannelse, udskiftning af hardware ved fejl og udløb samt dimensionering efter spidsbelastning.

Spidsbelastningen er den konkrete trade-off mod cloud: du køber og driver kapacitet til det travleste tidspunkt, også når den står ubrugt resten af året. Cloud kan i stedet skalere hurtigt efter behov.

Har du ikke interne kompetencer til opgaverne, skal de opbygges eller købes som driftsaftale. Så er en del af ansvaret igen flyttet ud af huset.

Gør driftsansvaret målbart, før du sammenligner: opstil et årshjul for patching, overvågning, backup, test af gendannelse og udskiftning af hardware. Sæt timer på hver opgave, og læg dem ind i matrixen sammen med hardwareinvesteringen og kapaciteten til spidsbelastning. Så bliver det synligt, om on-premise er billigere, eller om forskellen spises op af intern arbejdstid.

Hybrid: når private og offentlige miljøer kombineres

Hybrid betyder, at en del af driften ligger on-premise eller i en privat cloud, mens en anden del ligger i public cloud. Miljøerne er forbundet, så data og identiteter kan bevæge sig mellem dem. Det er ikke et kompromis uden valg, men en bevidst opdeling, hvor hver komponent placeres der, hvor kravene passer bedst.

I praksis lægges systemer tæt på fysisk udstyr, systemer med behov for meget lav svartid og data med særlige krav til fysisk placering typisk on-premise eller i privat cloud. Udviklings- og testmiljøer, nye applikationer og periodiske spidsbelastninger lægges ofte i public cloud, hvor der kan skaleres hurtigt via abonnement.

Fordi komponenterne kan have forskellige ejere, skal ansvaret for vedligeholdelse og opgraderinger afklares for hver del. Aftal også, hvordan data bevæger sig, hvem der har adgang, og hvordan netværk, identitet og logning hænger sammen på tværs; ellers bliver fejl sværere at finde. Microsofts Azure Arc styrer ressourcer på tværs af on-premise og flere cloudplatforme, og Azure Arcs Multicloud Connector understøtter i dag kun AWS som hyperscaler ved siden af Azure (hartiga.de).

Beslutningsmodel: sådan vælger du driftsmodel med vægtede kriterier

Start med datafølsomhed: hvilke data behandler systemet, og hvilke krav gælder for, hvor de må ligge? Skal data efter et konkret krav blive inden for virksomhedens fysiske rammer, peger det mod on-premise eller privat cloud under egen fysisk kontrol. Overføres personoplysninger til lande uden for EU/EØS eller til internationale organisationer, skal de særlige regler i databeskyttelsesforordningens kapitel V iagttages; det gælder også, hvis en virksomhed uden for EU/EØS drifter IT-systemer eller håndterer kundeservice for jer (Datatilsynet).

Vælg overførselsgrundlag, så snart du kender overførslen. Datatilsynet peger på standardkontrakter, bindende virksomhedsregler og ad hoc-kontrakter som mulige grundlag for at overføre personoplysninger til et tredjeland (Datatilsynet). Skriv grundlaget ind i aftalen og i matrixen, så cloud, on-premise og hybrid vurderes efter samme krav.

Dernæst kontrolbehov: hvor meget af vedligeholdelse, opgraderinger og konfiguration vil du selv styre, og hvor meget vil du overlade til en leverandør? Her ligger den centrale trade-off, fordi ansvaret for netop disse opgaver typisk placeres forskelligt i de to modeller.

Derefter skalering: svinger belastningen markant over døgnet eller året, taler hurtig skalering og abonnementsmodel i cloud for sig. Er belastningen jævn og forudsigelig, er argumentet svagere.

Så interne driftskompetencer: hvem patcher, overvåger, tester gendannelse og skifter hardware, hvis du vælger on-premise? Er kompetencerne til stede i dag, eller skal de ansættes eller købes?

Til sidst økonomi: cloud fjerner de tunge investeringer i egne servere og gør udgifterne mere fleksible. On-premise indebærer egen hardwareinvestering, efterfølgende udskiftning og kapacitet klar til spidsbelastning.

Læs aftalevilkårene som en del af sammenligningen: bindingstid, opsigelse, prisjustering og hvordan data og konfiguration udleveres ved ophør. Azure-rabatterne er netop knyttet til forpligtelser på et eller tre år, så en lavere pris kan betyde længere binding (azure.microsoft.com). Vej til sidst kriterierne efter de vægte, I satte i matrixen, og beslut på det samlede billede frem for enkeltpunkter.

Når fleksible udgifter og fraværet af egne serverinvesteringer vægter højest, taler det for cloud; ønsket om fysisk kontrol med data taler for on-premise. Hvis kun dele af porteføljen er omfattet af placeringskravene, kan hybrid være relevant, hvis ansvar og dataflow er afklaret komponent for komponent.