Skyhosting eller delt webhotell – hva kjøper du egentlig?

«Skyhosting» høres mer moderne ut enn delt webhotell, men ordene sammenligner ikke det samme. Delt beskriver at flere kunder bruker en felles plattform eller kapasitet. Sky beskriver hvordan datakraft, lagring og tjenester gjøres tilgjengelig og fordeles.

Et delt webhotell kan kjøre på skyinfrastruktur. En virtuell server i en offentlig sky kan fortsatt dele fysisk maskinvare med andre. Ingen av ordene forteller alene om siden blir rask, robust, sikker eller enkel å drifte.

Den nyttige sammenligningen er derfor ikke «gammel server mot sky». Den er:

1. Hvilken tjenestemodell får dere?
2. Hvem har ansvar for hvert lag?
3. Hvilke ressurser kan faktisk skaleres?
4. Hva skjer ved feil og trafikktopper?
5. Hva blir totalprisen for en fungerende løsning?

Kort svar

• Velg delt webhotell når nettstedet passer den støttede plattformen, dere ønsker en forutsigbar pakkepris og ikke trenger egen infrastruktur.
• Velg administrert skyplattform når applikasjonen trenger dokumentert elastisitet eller spesialiserte tjenester, men dere vil kjøpe bort mest mulig plattformdrift.
• Velg IaaS eller virtuelle maskiner i skyen når dere trenger kontroll over operativsystem og nettverk, og har et team som kan drifte det.
• Velg statisk hosting eller ferdig levert nettside når behovet er en rask informasjonsside uten database, serverkode og pluginvedlikehold.

Sky er ikke et mål i seg selv. Den enkleste modellen som oppfyller kravene, er ofte den beste.

Hva betyr delt webhotell?

På et tradisjonelt delt webhotell kjører flere nettsteder på en felles, administrert hostingplattform. Leverandøren bestemmer normalt operativsystem, webserver, database, støttede programversjoner og ressursgrenser. Kunden får et kontrollpanel og tilgang til sitt avgrensede område, ikke full serverkontroll.

Leverandøren kan blant annet dele eller begrense:

• prosessorkapasitet og minne
• samtidige prosesser og forbindelser
• diskytelse, lagringsplass og antall filer
• databasekapasitet
• utgående e-post
• månedlig datatrafikk

Dette er ikke nødvendigvis en svakhet. En godt administrert plattform kan fordele kostnader, oppdateringer og kompetanse på mange kunder. Men dere må få vite hvilke grenser som gjelder, og hvordan leverandøren håndterer en kunde som bruker uvanlig mye kapasitet.

Hva bør «sky» bety?

NIST beskriver fem kjennetegn ved reell skydatabehandling: selvbetjening ved behov, nettverkstilgang, delte ressursbasseng, rask elastisitet og målt tjenestebruk. Definisjonen skiller også mellom programvare som tjeneste, plattform som tjeneste og infrastruktur som tjeneste. Se NISTs definisjon av cloud computing .

I hostingmarkedet brukes «cloud» ofte løsere. En leverandør kan kalle én virtuell server for skyhosting uten automatisk skalering, flere tilgjengelighetssoner eller forbruksprising. Be derfor om en teknisk tjenestebeskrivelse i stedet for å tolke produktnavnet.

Vanlige modeller er:

Virtuell maskin i skyen

Dere leier datakraft, lagring og nettverk, men drifter vanligvis operativsystem, brannmur, webserver, database, applikasjon, overvåking og backup selv. Dette ligner en VPS, selv om infrastrukturen har flere skyfunksjoner.

Administrert applikasjonsplattform

Dere publiserer kode eller en støttet applikasjon uten å drifte hele operativsystemet. Plattformen kan tilby utrulling, logging og skalering, men ansvaret for kode, data, identiteter og konfigurasjon forsvinner ikke.

Serverless eller funksjoner

Kapasitet tildeles når kode kjører, ofte med pris per bruk. Det kan passe hendelsesstyrte oppgaver og API-er, men har grenser for kjøretid, oppstart, regionale tjenester og kostnad ved svært mange kall.

Objektlagring og statisk edge-hosting

Ferdige filer distribueres uten en tradisjonell applikasjonsserver. Det kan gi enkel og robust levering av en bedriftsside, men dynamiske funksjoner trenger andre tjenester.

Sammenlign ansvar før funksjoner

Jo mer kontroll dere kjøper, desto mer ansvar følger vanligvis med. Denne tabellen viser typiske forskjeller, men avtalen er alltid fasiten:

«Administrert» er ikke en standard. Bruk en konkret ansvarsmatrise for hosting før dere sammenligner pris.

Automatisk skalering krever en skalerbar applikasjon

Skyplattformer kan legge til og fjerne instanser etter belastning. Det betyr ikke at en eksisterende applikasjon automatisk kan bruke dem.

Horisontal skalering krever ofte at:

• applikasjonen ikke er avhengig av lokal sesjon på én instans
• opplastede filer ligger på delt eller distribuert lagring
• jobber og køer kan behandles av flere arbeidere uten duplikater
• databasen tåler flere forbindelser og økt belastning
• cache og eksterne API-er ikke blir neste flaskehals
• nye instanser rekker å starte før toppen er over
• minimum, maksimum og skaleringssignaler er riktig satt

Microsofts offisielle veiledning for autoskalering understreker at tjenester bør være stateless, at skalering må styres av relevante målinger, og at database- eller køskalering ofte ikke er automatisk.

En treg databasespørring blir ikke nødvendigvis raskere av ti webservere. En lås i applikasjonen kan bli verre. Et tredjeparts-API med fast rategrense kan stoppe hele flyten. Lasttest den faktiske brukerreisen og mål p95-svartid, feilrate, kø, database og kostnad samtidig.

Høy tilgjengelighet følger ikke med ordet sky

En arbeidslast i skyen kan kjøre på én instans i én sone med én database. Da har dere fortsatt flere enkeltpunkter som kan stoppe løsningen.

Dokumentert høy tilgjengelighet kan kreve:

• minst to applikasjonsinstanser
• lastbalansering og helsesjekker
• databasereplikering eller en administrert HA-konfigurasjon
• distribusjon over flere tilgjengelighetssoner
• uavhengig DNS, sertifikater og hemmelighetshåndtering
• overvåking og varsling som noen reagerer på
• testet tilbakeføring og gjenoppretting

Flere regioner er enda en egen arkitektur. Data må replikeres på en kontrollert måte, avhengigheter må finnes i begge regioner, og failover må testes. Det øker kostnad og kompleksitet.

Backup løser et annet problem enn høy tilgjengelighet. Replikaer kan kopiere en sletting eller korrupt endring med en gang. Dere trenger fremdeles en gjenopprettingsplan med testede kopier .

Sky er ikke automatisk raskere

Ytelsen bestemmes av hele kjeden: DNS, nettverk, cache, webserver, applikasjon, database, bilder, skrifter, JavaScript og eksterne tjenester.

Et delt webhotell med god cache kan slå en underdimensjonert skyserver. En statisk side levert nær brukeren kan være raskere enn begge. Og en stor skyinstans kan fortsatt gi en treg nettside når nettleseren må laste mange megabyte eller vente på tredjepartsskript.

Sammenlign med en representativ side og mål:

• Core Web Vitals i felt for mobilbrukere
• p50, p95 og p99 for serversvartid
• feilrate og tidsavbrudd
• cachetreff og belastning på origin
• CPU, minne, disk, database og kø
• oppstartstid ved oppskalering

Følg måleplanen for en raskere nettside før dere konkluderer med at hostingen er problemet.

Fast pris eller mange små forbrukslinjer

Delt webhotell prises vanligvis som en pakke. Det gjør budsjettet enkelt, men overforbruk kan utløse oppgradering, begrensning eller en utydelig rimelig-bruk-vurdering.

Skykostnaden kan bestå av:

• datakraft per tid eller kjøring
• blokk-, fil- og objektlagring
• databasekapasitet og lagring
• forespørsler og funksjonskall
• utgående datatrafikk
• lastbalanserer, offentlig IP og gateway
• logginnsamling, søk og oppbevaring
• backup, snapshots og replikaer
• sikkerhetstjenester og nøkkelhåndtering
• supportavtale
• utvikler- og driftstid

Forbruksprising kan være effektiv når bruken svinger, men dårlig konfigurert logging, egress eller autoskalering kan gi overraskelser. Sett budsjetter og varsler før produksjon, og test hva én normal brukerreise faktisk koster.

Sammenlign total kostnad over minst 24 måneder med samme krav til ytelse, oppetid, backup, support og arbeid. En serverlinje på 300 kroner kan være dyrere enn et abonnement på 1 000 kroner hvis det siste inkluderer driften dere ellers må gjøre selv.

Sikkerhet er et delt ansvar

Skyleverandøren sikrer infrastrukturen den kontrollerer. Kunden har fortsatt ansvar for deler av løsningen. Hvor grensen går, avhenger av om dere kjøper IaaS, plattform eller ferdig programvare.

AWS beskriver dette som sikkerhet av skyen hos leverandøren og sikkerhet i skyen hos kunden. Kunden har blant annet ansvar for egen data, applikasjon og den konfigurasjonen tjenesten gir tilgang til. Se AWS sin veiledning om delt sikkerhetsansvar .

Før kjøp bør dere fordele ansvar for:

• administratorbrukere, MFA og nøkkelrotasjon
• nettverksregler og offentlig eksponering
• oppdatering av operativsystem, kjøretid, CMS og kode
• kryptering og tilgang til data
• logger, deteksjon og hendelseshåndtering
• sårbarheter i biblioteker og plugins
• backup, restore og sletting

En skykonto med brede administratorrettigheter er ikke sikrere enn et kontrollpanel bare fordi leverandøren har store datasentre.

Portabilitet og leverandørbinding

Delt webhotell kan binde dere til et kontrollpanel, en bestemt databaseversjon eller proprietære backupformater. Sky kan binde dere til administrerte databaser, køer, identitet, funksjonsmiljøer og infrastrukturkode.

Mer standardisert infrastruktur gir ikke automatisk en enkel flytting. Be om svar på:

1. Hvordan eksporteres kode, filer, database, DNS og konfigurasjon?
2. Kan data eksporteres uten å starte hele den gamle tjenesten?
3. Hvilke proprietære API-er må bygges om?
4. Hvor lang tid og hvor mye nedetid krever en flytting?
5. Hva koster utgående data og parallell drift under migreringen?
6. Hvor lenge beholdes data etter oppsigelse?

Ta en prøveeksport før løsningen blir kritisk. Et arkiv som aldri er åpnet, er ikke en testet flytteplan.

Hvilken modell passer ulike nettsteder?

Dette er startpunkter, ikke fasit. En enkel side kan ha strenge krav, og en stor side kan være teknisk enkel når innholdet er statisk og cachebart.

Spørsmål leverandøren bør svare skriftlig på

1. Er tjenesten delt webhotell, administrert plattform eller infrastruktur vi drifter selv?
2. Hvilke CPU-, minne-, I/O-, database-, prosess- og trafikkgrenser gjelder?
3. Hvilke ressurser skalerer automatisk, etter hvilke målinger og innen hvor lang tid?
4. Hva er maksimal kapasitet, og hva skjer når den nås?
5. Kjører løsningen i flere soner eller bare på én instans?
6. Hvem oppdaterer hvert lag og reagerer på varsler?
7. Hva inngår i backup, hvor lagres kopien og når ble restore sist testet?
8. Hvilken målemetode, unntak og kompensasjon gjelder for SLA?
9. Hvilke kostnader kommer i tillegg til grunnprisen?
10. Hvordan eksporterer og flytter vi hele løsningen?

Et presist «nei» er mer verdifullt enn et løst løfte om «ubegrenset sky».

Hva Vymo tilbyr

Vymos standardtilbud er én enkel, mobiltilpasset bedriftsnettside som Vymo setter opp og leverer gjennom Cloudflare. Nettsiden og hosting de første 12 månedene er gratis. Deretter koster hosting fra 49 kroner per måned, fakturert årlig.

Dette er ikke en kundestyrt skykonto, VPS eller generell applikasjonsplattform. Standardtilbudet inkluderer ikke et selvbetjent kontrollpanel for servere, et løfte om automatisk applikasjonsskalering, flere regioner, en tilgjengelighets-SLA eller drift av kundens egen kode, database og integrasjoner.

For en registrert virksomhet som trenger en ryddig side med tjenester og kontaktinformasjon, kan den enkle leveransen fjerne mye unødvendig teknisk arbeid. Se nøyaktig hva den gratis nettsiden inkluderer .

Trenger dere nettbutikk, innlogging, booking, egen applikasjon eller dokumenterte kapasitetskrav, bør arbeidslast og ansvar avklares før plattformen velges. Beskriv behovet for Vymo eller bruk sjekklisten over når dere ber andre leverandører om tilbud.