Prestandaoptimering: när lagringsarkitektur avgör allt

ML-träning med FSx for Lustre

Ett av de tydligaste exemplen på hur infrastrukturval direkt påverkar affärsresultat kommer från ML-området. Genom att designa en optimerad FSx for Lustre-lösning – med rätt dimensionering av throughput och strategisk placering av beräkningsinstanser – halverades laddningstiderna för träningsdata.

Det låter kanske som en rent teknisk detalj, men konsekvensen är affärskritisk: forskningsteam som kör hundratals experiment per vecka fick tillbaka halva sin väntetid. I en miljö där time-to-market för nya ML-modeller avgör konkurrenskraften är det en enorm skillnad.

Vad vi lär oss: Prestandaoptimering handlar sällan om att köpa större instanser. Det handlar om att förstå I/O-mönster och välja rätt lagringslager. FSx for Lustre är inte rätt för alla arbetsbelastningar – men för sekventiell läsning av stora dataset är det svårslaget.

Databasrespons vid plattformsbyte

Ett annat fall visar effekten av att migrera från Azure till AWS med IaC (Terraform och CloudFormation) som grund. Genom att automatisera hela infrastrukturen minskade byggkostnaderna med 30 procent och databassvarstiderna förbättrades markant.

Den dolda vinsten var dock en annan: SOC 2-efterlevnaden blev enklare att underhålla eftersom all infrastruktur var versionshanterad och granskningsbar. Varje förändring fanns dokumenterad i Git – inte i någons anteckningsblock.

Operationell lättnad: från manuellt arbete till automatiserade flöden

Provisionering på 30 minuter istället för en timme

När lokala system migrerades till AWS-tjänster (EC2, S3, VPC, Directory Service, Security Hub, CloudTrail, Config och Backup) skedde något som IT-avdelningen inte riktigt förväntade sig: den dagliga driftsbördan minskade dramatiskt.

Serverprovisionering gick från en timmes manuellt arbete till trettio minuter – och det var bara början. Med Security Hub och CloudTrail på plats fick teamet automatiserad insyn i säkerhetsläget istället för att manuellt granska loggar.

Opsios perspektiv: Vi ser detta mönster upprepas hos nästan varje kund som migrerar från lokala system. Den verkliga besparingen ligger inte i licensavgifter – den ligger i frigjord tid. Ett driftsteam som slipper brandkårsutryckningar kan istället fokusera på att förbättra plattformen.

SaaS-först: snabbaste vägen till mätbar nytta

Inte alla migreringar handlar om att flytta servrar. Ofta ger en SaaS-först-strategi snabbast avkastning, särskilt för organisationer som fortfarande kör egna e-postservrar, filservrar och samarbetsverktyg.

Finansiella tjänster: Microsoft 365 med Purview

En finansverksamhet migrerade e-post, SharePoint och Teams till Microsoft 365 och konfigurerade Microsoft Purview för regelefterlevnad. Resultatet: 30 procent lägre infrastrukturkostnader och renare revisionsspår.

Det intressanta här var inte själva flytten – den är relativt standardiserad. Det var Purview-konfigurationen som gjorde skillnaden. I en bransch där regulatoriska krav ständigt skärps (tänk NIS2-direktivet som nu påverkar finanssektorn) är det avgörande att compliance-kontroller är inbyggda i plattformen, inte påklistrade.

Biotech: Azure Storage med HIPAA-anpassning

Forskningsdata flyttades till Azure Storage med geo-redundans, Defender for Endpoint för enhetsskydd och Teams med OneDrive för säkert samarbete. Drifttiden förbättrades markant och kontrollerna anpassades till HIPAA-krav.

Utbildning: hybridinlärning och identitetshantering

OneDrive och SharePoint ersatte äldre filservrar, Teams möjliggjorde hybridinlärning och Azure AD med MFA stramade åt identitetshanteringen. Resultatet blev lägre IT-kostnader och bättre upplevelser för både studenter och lärare.

Gemensam nämnare: I samtliga dessa fall var identitetshantering med MFA den enskilt viktigaste säkerhetsåtgärden. Det kostar nästan ingenting att aktivera men stoppar den överväldigande majoriteten av kontokapningsattacker.

Säkerhet genom design – inte som eftertanke

Det här är en kulle vi är beredda att dö på: säkerhet som läggs till efter migrering är i praktiken ingen säkerhet alls.

I varje framgångsrikt migrationsprojekt vi sett har följande tre pelare funnits med från dag ett:

1. Identitet och åtkomstkontroll – Centraliserad identitetshantering (Azure AD, AWS IAM Identity Center) med MFA och principen om minsta privilegium

2. Kryptering – I vila (AES-256) och i transit (TLS 1.2+), utan undantag

3. Övervakning och loggning – CloudTrail, Security Hub, eller motsvarande – med larm som faktiskt går till någon som agerar på dem

Det sista punkten är kritisk. Vi ser regelbundet miljöer där loggning är aktiverad men ingen tittar på larmen. Det är som att installera ett inbrottslarm och sedan stänga av ljudet.

Från Opsios SOC/NOC-perspektiv: Molnsäkerhet börjar med arkitekturen, inte med ett verktyg.

Etappvis migrering: begränsa risk utan att tappa tempo

Flexeras State of the Cloud har konsekvent visat att kostnadshantering och styrning är de största utmaningarna vid molnadoption. En stor anledning är "big bang"-migreringar som försöker flytta allt på en gång.

Vår rekommendation – baserad på vad vi ser fungera i produktion – är en etappvis approach:

Etapp 1: Inventering och prioritering (2–4 veckor)

Kartlägg alla applikationer, beroenden och dataflöden. Identifiera shadow IT. Definiera migreringsstrategin per applikation (de klassiska 6 R:en: Rehost, Replatform, Refactor, Repurchase, Retire, Retain).

Etapp 2: Grundplattform (2–6 veckor)

Bygg landningszonen med IaC – nätverksdesign, identitetshantering, loggning, kostnadsaviseringar. Inga applikationer ännu – bara grunden.

Etapp 3: Pilotmigrering (2–4 veckor)

Flytta 2–3 applikationer med låg risk. Validera processer, verktyg och återställningsplaner.

Etapp 4: Vågor av migrering (löpande)

Gruppera applikationer i vågor baserat på beroenden och affärskritikalitet. Varje våg har sin egen återställningsplan.

Etapp 5: Optimering (löpande)

Rightsizing, Reserved Instances/Savings Plans, och kontinuerlig Cloud FinOps för att hålla kostnaderna i schack.

Den här strukturen gör att ledningsgruppen ser värde redan efter etapp 3 – inte efter nio månader.

När det inte fungerar: vanliga misslyckanden

Ärlighetens skull kräver att vi också pratar om vad som går fel. De tre vanligaste misslyckandena vi observerar:

1. Bristfällig applikationsinventering

Organisationer underskattar konsekvent antalet applikationer och integrationer de har. Shadow IT – system som ingen "äger" men alla använder – är den vanligaste orsaken till förseningar.

2. Underskattad förändringshantering

Tekniken är sällan det svåraste. Att få 500 användare att ändra sina arbetsflöden kräver kommunikation, utbildning och tålamod som inte går att automatisera med Terraform.

3. Inget definierat "klart"

Utan tydliga KPI:er och baseline-mätningar före migrering finns det inget sätt att bevisa att projektet lyckades. "Det känns snabbare" duger inte i en styrelseproposition.

Så kommer du igång

En molnmigrering behöver inte börja med ett mångmiljonprojekt. Den kan börja med en strukturerad bedömning av nuläget – vad har ni, var vill ni vara, och vilka hinder finns på vägen?

Molnmigrering med en partner som har 24/7 driftsövervakning innebär att ni inte står ensamma när den första produktionsincidenten inträffar klockan tre på natten. Och det kommer den att göra.

Managerade molntjänster handlar i grund och botten om att låta ert team fokusera på det som skapar affärsvärde – inte på att hantera infrastruktur.

Det viktigaste beslut ni fattar är inte vilken molnleverantör ni väljer. Det är hur disciplinerat ni genomför migreringen.

Vanliga frågor

Hur lång tid tar en typisk molnmigrering?

Det beror helt på omfattning och komplexitet. En enklare lift-and-shift av ett tjugotal servrar kan vara klar på 6–8 veckor, medan en komplex omstrukturering med databasbyten och nya säkerhetsramverk kan ta 4–9 månader. Nyckeln är att bryta ner projektet i etapper med mätbara milstolpar.

Vilka är de vanligaste misstagen vid molnmigrering?

De tre vi ser oftast i Opsios SOC/NOC: bristfällig inventering av befintliga applikationer (shadow IT missas), underskattad förändringshantering hos slutanvändare, och att säkerhetskontroller läggs till i efterhand istället för att byggas in. Alla tre kan undvikas med strukturerad planering.

Hur mäter vi framgång efter migrering?

Definiera KPI:er innan migreringen startar – typiskt kostnad per transaktion, svarstider (P95/P99), drifttid, tid till provisionering och efterlevnadsstatus. Jämför sedan mot baseline efter 30, 60 och 90 dagar i produktion. Utan baseline finns inget att mäta mot.

Är molnmigrering värt det för mindre organisationer?

Ja, men strategin skiljer sig. Mindre organisationer har ofta störst nytta av SaaS-först-migrering (exempelvis Microsoft 365) och managerade tjänster istället för att bygga egen infrastruktur. Kostnadsbesparingen kommer snabbare och driftsbördan minskar dramatiskt.

Hur hanteras datasäkerhet och GDPR vid molnmigrering?

Välj regioner inom EU/EES (exempelvis AWS eu-north-1 i Stockholm eller Azure Sweden Central). Säkerställ att kryptering i vila och transit är aktiverat, implementera identitetshantering med MFA, och verifiera att databehandlaravtal (DPA) finns på plats. NIS2-direktivets krav på incidentrapportering bör också beaktas redan i planeringsfasen.