Så lyckas du med företagets molnstrategi

Public cloud, private cloud, multi-cloud, hybrid cloud… Molnet ska göra IT-driften enklare, men det är lätt att gå vilse bland begrepp och möjligheter, licensmodeller, kostnader och lagstiftning kring datalagring. Läs våra goda råd om hur du kan flytta dina data och applikationer till molnet, och få ut det mesta för dina investeringar.

Cloud, eller molnet, är i princip inget annat än stora datacenter uppkopplade via internet, och som finns över hela jordklotet. Även om grunden är enkel finns det många saker att tänka på när verksamheten ska lägga en bra och framtidsinriktad molnstrategi.

Låt oss börja med en definition. De olika molnnamnen har lite olika betydelse beroende på vem som använder dem och i vilket sammanhang begreppen används. Här specificerar vi bara de begrepp som används här utan att diskutera definitionerna vidare.

Molnstrategi
Övergripande strategi för att flytta lösningar och licensmodeller från on-prem till molnbaserade tjänster/molnplattformar.

Molnplattformar
Plattformstjänster från kommersiellt tillgängliga molnleverantörer som Oracle (OCI), Amazon (AWS), Google, Microsoft Azure. Kallas ofta public cloud på engelska.

On-prem
Licensmodeller och infrastruktur som är kopplade till lokala, fysiska lösningar, ett lokalt datacenter som driftas av företaget eller andra.

Public cloud
Kommersiella, offentligt tillgängliga molntjänster tillgängliga över internet (t.ex.: AWS, Azure, OCI).

Molnplattformsarkitektur
Teknisk arkitektur beskriver olika kombinationer och lösningar av plattformstjänster från olika leverantörer.

Det här är de vanligaste begreppen:

• EU sovereign cloud - Molnplattform som är fysiskt placerad och drivs i EU och helt underställd EU:s regelverk för databehandling.
• Single cloud - Där det bara finns en molnleverantör för alla molnbaserade tjänster och lösningar.
• Multi-cloud - Där molnplattformar från två eller flera molnleverantörer är en del av helhetslösningen.
• Hybrid cloud - Där on-prem-lösningar är integrerade i molnplattformen.
• Private cloud (här också “cloud at customer”) -  Hårdvara och all hantering av data sker hos kunden i kundens datacenter, men driftas och licensieras som om detta vore ett public cloud.

Valen som påverkar molnresan

Att ha en tydligt definierad och kommunicerad molnstrategi är en förutsättning för att ta till sig molnet och en molnplattformsarkitektur med molnets flexibilitet, skalbarhet och licensmodeller. Molnstrategin ska vara förankrad i ledningen, och vara tydligt förklarad och accepterad av alla berörda parter i företaget. Molnmigreringen i sig behöver inte vara särskilt tids- eller arbetskrävande men medför ofta extraarbete. Det beror på att man under förberedelserna upptäcker tekniska skulder, otillräcklig dokumentation och vill lägga tid på större förändringar i IT-infrastrukturen och/eller applikationsportföljen.

Det är mycket vanligt att planera med en "lift-and-shift" strategi, dra slutsatsen "move-and-improve", och avsluta med ett "rip-and-replace" tillvägagångssätt. Men vad menas egentligen med dessa olika begrepp?

Lift-and-shift: Lösningar flyttas oförändrade från on-prem till molnet. Avsikten är att det ska bli mindre risk- och efterarbete vid flytten. Det är bland annat lättare att jämföra prestanda och funktionalitet.

Move-and-improve: Förändringar görs i flyttprocessen. Det kan till exempel vara större applikationsuppgraderingar, nya databasversioner, uppgraderingar som kräver mer testning och verifiering efter flytt. Förändringar i prestanda och funktionalitet måste förväntas, inte som en konsekvens av byte av plattform, utan som en förändring av applikation och lösning.

Rip-and-replace: Teknik, mjukvara och applikationsplattformar förändras avsevärt i flyttprocessen. Här skapar vi en ny lösning i molnet som kräver betydande testning och verifiering innan produktion.

Vilken/vilka molnplattformar man väljer beror ofta på företagets interna IT-kompetens, hur stora kostnaderna är kopplade till olika leverantörer, om data som behandlas omfattas av nationella regler eller andra regelverk. Ofta kan kraven på molnplattformen resultera i en molnplattformsarkitektur som involverar flera molnplattformar, en specifik fysisk lokalisering av data och tydliga definitioner av behörig åtkomst till lösningen, samt support och drift av plattformen.

Förutsättningarna för valet av molnarkitektur

•  Klassificering av de uppgifter som behandlas.
• Teknik och system.
  
  • Kostnader relaterade till licenser, tjänster och infrastruktur.
•  Fysisk lokalisering av data, redundans och latens.

1. Offentlig (allmänt tillgänglig (via webb)/öppen).
2. Data med en speciell skyddsnivå (intern/konfidentiell/strikt konfidentiell).
3. EU-reglerad (med förbehåll för nödföreskrifter, personuppgifter).
4. Nationellt reglerad (med förbehåll för nödregler, samhällskritiska system, SCADA).

Det är utfallet av denna klassificering som avgör om de aktuella data kan placeras i hybrid cloud, private cloud, public cloud eller on-prem-lösning. Till exempel måste systemen följa nationella riktlinjer för fysisk och logisk säkerhet. Detta gör det svårt att placera dessa data i en kommersiell molntjänst. Men det kan vara av stor vikt att analysera historiska SCADA- och sensordata för prediktiva lösningar. Denna bearbetning av historisk data kan troligen göras med fördel i molnet (hybrid molnplattformsarkitektur).

Data med hög skyddsnivå, konfidentiell/mycket konfidentiell, eller data som regleras av nationella bestämmelser kanske inte kan skapas i en offentlig molntjänst med standardkrypterade databastjänster. Men om data behandlas i en molnlösning med system som «säkrar» obehörig åtkomst från molnoperatören ("operator access control") och har speciella metoder för förvaring och säkerhet av krypteringsnycklar utanför databassystemet (cloud vault), kommer dessa data i många fall också att kunna behandlas i molnet.

Teknologi och system
I vissa fall kan lösningarna som flyttas förenklas och förbättras avsevärt genom att utnyttja tjänster som specifika leverantörer tillhandahåller. Det kan vara allt från Windows-tjänster hos Azure till Kubernetes-tjänster och autonoma databassystem hos Oracle. Det är också tydligt att leverantörer som Microsoft och Oracle gör det mycket fördelaktigt att köra sina tjänster på sina plattformar. Här kommer en multi-cloud-ansats att ge "best-of-breed" tekniskt och ekonomiskt, vilket gynnar kunden.

Kostnaderna för licensanvändning och infrastruktur varierar också betydligt mellan olika leverantörer. Azure är i de flesta fall billigast för Windows, men kan vara dyrast för Linux eller andra operativsystem och infrastrukturtjänster. Kostnader för datalagring, kapaciteter som RAM, blocklagring och cpu, liksom data till och från lösningen (ingress och egress), kommer också att påverka de totala kostnaderna avsevärt. Att fastställa den totala kostnaden kan vara en komplex uppgift. Kostnaden kommer för många att vara avgörande för valet av molnplattform, och arkitekturen samt lösningens design kommer väsentligt att påverka kostnaderna.

Fysisk placering av data, redundans och latens
Vi började med att påpeka att molnlösningar i grund och botten är stora datacenter med olika fysiska platser. Var dessa datacenter är placerade och den fysiska strukturen av dem är av stor betydelse i hybrid- och multi-cloud-lösningar. Detta beror på att fysisk avstånd till och mellan datacenter resulterar i väntetider i kommunikationen. Denna väntetid (latency) kommer i vissa situationer, beroende på lösningens arkitektur, att ha stor påverkan på användarupplevelsen och dataprocesseringen. Det är därför viktigt att förstå konsekvenserna av valet av datacenterregioner och begreppen "Availability Domain" och "Fault Domain".

En molnregion (cloud region), som exempelvis Amsterdam, har två molnleverantörer, Oracle Cloud Infrastructure (OCI) och Microsoft Azure. Tillsammans har de flera fysiska datacenter för sina molntjänster i Amsterdam. Dessa fysiska datacenter kallas "Availability Domain" (AD). Varje AD har flera "Fault Domain" (FD), vilket innebär att ett fysiskt datacenter har flera separata datarum med egen infrastruktur, kommunikation och strömförsörjning för ökad säkerhet och backup. I en multi-cloud-arkitektur är det av stor betydelse att ha så låg latens som möjligt mellan molnplattformarna. I vissa fall delar de stora molnleverantörerna samma fysiska datacenter. Det kan därför vara av stor betydelse att välja specifika "Availability Domains" för molnleverantörerna. På detta sätt får man en samlokalisering av fysiska datarum. Med rätt arkitekturtjänster i ett multi-cloud kan man i vissa fall uppleva en latens som är lika eller lägre än den man har i egna lokala datacenter.

Viktigast av allt: en genomtänkt strategi och bra plan

En lista med begrepp som vi har tagit upp i detta relativt långa blogginlägg kan vara överväldigande för många. Ändå är det viktigt att förstå de många, komplexa aspekterna när man väljer en molnplattformsarkitektur och gör en plan för molnmigrering.

Informationen ovan är baserad på den erfarenhet vi skaffat oss genom många molnmigreringar och etablering av molnlösningar för kunder.
Vi vill vara med våra kunder i början av denna process för att på bästa sätt ta hand om alla aspekter i valet av rätt molnplattformsarkitektur.

Ommund Øvrelid, Lösningsarkitekt Cegal

«Molnsanningar» har också en begränsad livslängd. Nya tjänster och licensmodeller introduceras ständigt och nya datacenter etableras. Det är viktigt att börja planera för molnmigrering så snart som möjligt, men med arkitektoniska principer och mekanismer/skript som möjliggör anpassning till kommande förändringar. 

Multi-cloud kan ge ditt företag fler fördelar än single cloud /on-prem, men det beror givetvis på dina behov, mål och utmaningar.

Det viktigaste för framgång är i alla fall en genomtänkt strategi, bra planering och ledning av hela migreringsprojektet vid övergång till en multi-cloud-strategi.

Med vår expertis inom molntjänster får du en trygghet när du väljer oss som partner, och våra mycket skickliga konsulter tillför ett betydande värde till din verksamhet.

Ommund Øvrelid

Relaterat innehåll

Microsoft moln

Redaktionen SE Cegal vill bygga ett enastående, nästa...