Colocation, moln eller hybrid: så väljer ni var systemen ska stå

Frågan brukar ställas som ett val mellan platser: vilket datacenter ska vi använda? Så ser sällan det verkliga beslutet ut. De flesta verksamheter har inte ett system som ska stå någonstans, utan tio eller femtio, och de har olika krav. Beslutet blir därför bättre om det bryts upp i två delar: vad som ska stå var, och sedan hos vem.

Den här genomgången går igenom de tre vanliga alternativen — colocation, molnhosting och hybrid — men lägger vikten vid de tre saker som faktiskt avgör utfallet och som sällan står i jämförelsetabellen: vad ni behöver kontrollera själva, hur kostnadsmodellen beter sig när verksamheten förändras, och hur ni når systemen när de har flyttat. Den sista är den som brukar specificeras sist, och den som märks först när något inte fungerar.

Börja med att inventera per system

Innan alternativen jämförs behöver ni veta vad som ska placeras. Gå igenom systemen ett i taget och anteckna fyra saker för varje.

Det första är känsligheten för fördröjning. Ett affärssystem som används med tangentbord och skärm hela dagen upplevs helt annorlunda än ett filarkiv som nås några gånger i veckan, och ett system som styr något fysiskt i en produktion har ytterligare andra krav. Det andra är beroenden: vilka andra system pratar det med, och hur ofta? System som utbyter mycket data med varandra bör placeras nära varandra — att dela dem mellan två platser är en av de vanligaste källorna till prestandaproblem efter en flytt.

Det tredje är bindningar. Äldre affärssystem kan vara låsta till en viss hårdvara, en licensmodell som inte tillåter virtualisering hos tredje part, eller en leverantör som bara stödjer en viss driftform. Det fjärde är vilken typ av data systemet innehåller, eftersom det avgör om juridiken lägger sig i placeringen.

Efter den övningen svarar de flesta inte längre "moln" eller "colocation" på frågan, utan något mer sammansatt. Det är ett bättre svar.

Colocation — ni äger hårdvaran, någon annan äger huset

Med colocation står er egen serverhårdvara i någon annans anläggning. Ni köper plats, ström, kyla, fysiskt skydd och nätverksanslutning, men äger och driftar maskinerna själva.

Det passar när ni har hårdvara som ska leva ett antal år, när ni behöver full kontroll över konfigurationen, när ett system är bundet till specifik hårdvara, eller när en förutsägbar och jämn kostnad väger tyngre än snabb skalning. Det förutsätter att ni har kompetens att drifta maskinerna, eller någon som gör det på uppdrag, och att ni är beredda att hantera livscykeln på hårdvaran — inklusive den dagen den ska bytas.

Två saker underskattas ofta i colocation. Den ena är att fysisk åtkomst är en del av driften: vem får åka dit, hur snabbt, och vad gör ni om något behöver bytas nattetid. Den andra är nätverksanslutningen, som är en separat fråga från platsen och behandlas längre ner.

Molnhosting — ni hyr kapacitet och köper bort driftmomentet

I molnet hyr ni kapacitet i någon annans infrastruktur och slipper hårdvaran helt. Det ger snabb uppstart, möjlighet att ändra dimensioneringen utan att köpa något, och tillgång till färdiga tjänster ni annars hade behövt bygga.

Det passar särskilt när belastningen varierar, när ni vill undvika investeringar, när ett projekt ska igång snabbt eller när ni vill lägga över drift och underhåll av plattformen på någon annan. Priset för det är mindre kontroll över underliggande lager, en kostnad som är löpande snarare än periodiserad, och ett beroende som blir svårare att bryta för varje år som går.

Det som brukar överraska är inte grundkostnaden utan hur den varierar. Kostnaden följer användningen, och användningen ökar oftast i en riktning. Överföring av data ut ur plattformen debiteras dessutom i många modeller separat, vilket betyder att arkitekturval — var data ligger i förhållande till där den bearbetas och där användarna sitter — får ekonomiska konsekvenser som inte syns i en jämförelse gjord vid ett enskilt tillfälle.

Hybrid är sällan ett val, oftare ett tillstånd

Hybrid beskrivs i broschyrer som en medveten strategi: det bästa av två världar. I praktiken uppstår den oftast av sig själv. Några system flyttades till molnet, några blev kvar, och resultatet kallas hybrid i efterhand.

Det är inte nödvändigtvis fel — för de flesta verksamheter är en blandning det rimliga läget. Men skillnaden mellan en planerad hybrid och en oplanerad är stor. I den planerade vet ni var gränssnitten går, vilka system som pratar över vilken förbindelse och vad som händer om den förbindelsen försvinner. I den oplanerade upptäcks beroendena när något slutar fungera, och ingen har en samlad bild av vad som pratar med vad.

Om ni landar i hybrid, gör den då till ett medvetet läge. Rita upp vilka flöden som korsar gränsen mellan platserna, hur stora de är och hur känsliga de är för fördröjning. Just de flödena är de som ställer krav på uppkopplingen, och de är sällan de ni tror.

Juridiken: vad som faktiskt gäller om placeringen

Det sägs ofta att GDPR kräver att data lagras i Sverige. Det gör den inte. Regelverket ställer krav på hur personuppgifter behandlas och skyddas, och det reglerar överföring till länder utanför EU och EES särskilt — men det pekar inte ut ett land som lagringsplats.

Det som däremot är verkliga överväganden: vart data överförs och på vilken rättslig grund, vilken leverantör som är personuppgiftsbiträde och vad biträdesavtalet säger, om en leverantör kan omfattas av lagstiftning i ett annat land som ger myndigheter där åtkomst, och vilka underleverantörer leverantören i sin tur använder. Utöver det kan sektorsspecifika regler och krav i era egna avtal — med kunder, i en upphandling eller från en försäkringsgivare — lägga på ytterligare villkor. De kraven är ofta strängare och mer konkreta än dataskyddsregleringen.

Närhet har samtidigt praktiska fördelar som inte har med juridik att göra: kortare fysiskt avstånd ger lägre fördröjning till användare på plats, och en anläggning i närheten är enklare att besöka. Det är goda argument i sig. De ska bara inte förväxlas med ett rättsligt krav som inte finns.

Kostnadsmodellerna beter sig olika över tid

Den ekonomiska skillnaden mellan alternativen ligger mindre i nivån och mer i formen. Colocation är i huvudsak en investering plus en förhållandevis jämn löpande kostnad, och den är förutsägbar men trög: den ändras inte nedåt bara för att behovet minskar. Moln är rörligt och följer användningen, vilket är en fördel när behovet varierar och en nackdel när ingen håller koll.

Jämför därför inte en månadskostnad mot en annan. Jämför i stället hur de två modellerna beter sig i tre scenarier: om verksamheten växer snabbt, om den krymper, och om ingenting händer på flera år. Räkna också in det som brukar hamna utanför kalkylen — nätverksanslutning till platsen, redundans, backup och hur den lagras, licensskillnader mellan driftformerna, arbetstid för drift och övervakning, samt vad det skulle kosta att flytta tillbaka eller vidare. Det sista är i praktiken priset på er handlingsfrihet.

Vägen dit är en del av beslutet

Här ligger den vanligaste luckan. Placeringen av systemen upphandlas noggrant, och uppkopplingen fram till dem blir en rad i slutet. Men när systemen inte längre står i huset är förbindelsen ut ur huset det enda som ger er åtkomst till dem. Från och med flytten är uppkopplingen inte en stödfunktion — den är förutsättningen för att kunna arbeta.

Det förändrar kraven på ett konkret sätt. Trafik som tidigare gick i det lokala nätet passerar nu förbindelsen, och det mesta av den går uppåt. Ett avbrott som förr betydde "vi kommer inte åt internet" betyder nu "vi kommer inte åt affärssystemet". Och en förbindelse utan reservväg blir en enskild punkt som kan slå ut hela verksamheten, oavsett hur redundant anläggningen i andra änden är.

Fyra frågor hör därför till samma beslut som placeringen. Hur stor blir trafiken över förbindelsen efter flytten, och särskilt uppströms? Finns en reservväg, och går den i ett annat fysiskt spår och helst i ett annat underliggande nät? Behövs en direktförbindelse fram till anläggningen eller molnleverantören i stället för trafik över öppet internet, och vad kräver det i så fall? Och hur ser uppkopplingen ut i andra änden — vilken operatör eller korskoppling används in i hallen, och är den redundant?

Har ni flera kontor och systemen på ett tredje ställe blir styrningen av trafiken en fråga i sig: vilken väg som används när, vad som prioriteras när kapaciteten är begränsad och vad som händer automatiskt vid ett avbrott. Det är precis den typen av styrning SD-WAN är byggt för.

Det som gör flytten dyrare än planerat

Fyra mönster återkommer. Det första är att system som pratar mycket med varandra hamnar på olika sidor av en förbindelse, vilket ger prestandaproblem som ser ut som kapacitetsbrist men är ett placeringsfel. Det andra är att backupen inte flyttas i samma takt som systemen, så att kopior under en period ligger på samma ställe som originalet. Det tredje är att nätberoenden upptäcks sent: fasta IP-adresser, brandväggsregler och integrationer där en motpart låst upp er på ett IP-nummer. Det fjärde är att förbindelsen dimensionerats efter behovet före flytten i stället för efter behovet efteråt.

Samtliga fyra går att upptäcka i förväg genom att rita upp flödena innan något flyttas. Ingen av dem är billig att upptäcka efteråt.

Frågor att ställa innan ni bestämmer er

Om anläggningen: vilka operatörer finns inne i hallen, och kan vi välja? Hur ser redundansen ut för ström, kyla och nätverk? Vem äger korskopplingen fram till vår utrustning och vad kostar en ny? Hur får vi fysisk åtkomst, och hur snabbt?

Om molnleverantören: var behandlas och lagras data, vilka underleverantörer används, hur ser biträdesavtalet ut och vad kostar det att föra ut data? Hur tar vi med oss data om vi avslutar?

Om uppkopplingen: vad går att leverera på vår adress, är kapaciteten dedikerad och symmetrisk, finns en reservväg i ett annat fysiskt spår, och går det att få en direktförbindelse fram till den plats systemen står på? Vem övervakar förbindelsen, och vem kontaktar vi vid fel?

Så jobbar vi

Bredband3 driver inga egna datacenter och säljer ingen hallplats. Vår del är vägen dit: uppkopplingen från er adress till de platser där systemen står, och redundansen som gör att åtkomsten inte hänger på en enda väg. Vi är operatörsoberoende och äger inget eget nät, vilket betyder att vi kan utgå från vad som faktiskt går att leverera på just er adress i stället för att anpassa förslaget efter en egen infrastruktur.

Kundtjänst och support är vår egen och sitter i Sverige. Vad som går att leverera och vilka åtaganden som gäller beror på adress och teknik, och skrivs in i avtalet.

Står ni inför en flytt av systemen? Skicka adressen och en bild av vilka flöden som kommer att gå över förbindelsen efteråt, så tittar vi på vad som går att leverera och vad en reservväg skulle innebära. Begär offert så återkommer vi.

Vill ni gå vidare hittar ni mer om molntjänster och uppkoppling för molnet, företagsfiber med dedikerad kapacitet, redundans och reservvägar och uppkoppling för fastighetsbolag.