Senior molnkompetens för AWS, Azure och Google Cloud. Från migrering och arkitektur till FinOps och drift - byggt för att hålla över tid, inte bara till lanseringen.
En genomtänkt molnarkitektur är skillnaden mellan en plattform som skalar med verksamheten och en som blir en kostnadsbörda. Jag har sett samma mönster hos allt från SaaS-startups till etablerade industribolag: första resan till molnet görs i hast, med lift-and-shift som strategi och med en not-slutsumma som överraskar. Sex månader senare är molnet dyrare än on-prem, teamet är frustrerat och frågan 'var det här värt det?' hänger i luften.
Mitt angreppssätt är annorlunda. Molnet är inte en destination – det är en arkitektur som kräver eftertanke. För varje projekt börjar jag med en genomlysning som kartlägger var ni är, var ni vill vara, och – viktigast – vilken väg dit som faktiskt är ekonomiskt försvarbar. En molngenomlysning tar typiskt 1-2 veckor och ger er en tydlig prioriteringsordning.
De vanligaste felen jag ser: överetablerade resurser utan auto-scaling, saknade budgetlarm, utvecklingsmiljöer som aldrig stängs av, och framför allt – ingen som har helhetsbilden över molnkontot. FinOps handlar inte bara om att förhandla rabatter med leverantören, utan om att göra kostnader synliga per team, per applikation och per funktion.
Jag är leverantörsoberoende men rådgivande: single-cloud är rätt för de flesta organisationer. Multi-cloud låter bra i presentationer men innebär dubbelt så mycket kompetens att hålla, dubbelt så många säkerhetsmodeller att förstå, och en komplexitet som sällan är värd de teoretiska fördelarna. Azure är starkt för Microsoft-tunga organisationer med Entra ID och M365, AWS har bredast tjänsteutbud och mognast ekosystem, GCP är klassledande för data, AI och BigQuery.
Det finns dock undantag där multi-cloud är rätt: när ni behöver geo-redundans över regioner som bara en leverantör täcker, eller när en specifik PaaS-tjänst bara finns på en plattform. I dessa fall bygger jag platform-agnostisk infrastruktur med Terraform så att era team kan arbeta på samma sätt oavsett moln.
En lyckad molnmigrering handlar om att gå i rätt ordning. Jag rekommenderar en fyrastegsmodell: först kartläggning (vad har ni, vad körs, vad kostar det idag?), sedan prioritering (vilka workloads ger mest värde av att flytta först?), sedan migration i batchar med rollback-möjlighet, och slutligen optimering (är resurserna rätt dimensionerade efter flytten?).
Steg 1 – kartläggning – är det viktigaste. Utan att veta vad som körs kan ni inte fatta informerade beslut om vad som ska flyttas, i vilken ordning, och med vilken risk. Jag använder automatiserade verktyg för discovery och kompletterar med intervjuer av teamen som äger workloadsen för att fånga upp beroenden och begränsningar som verktygen missar.
De organisationer vi arbetar med brottas oftast med minst ett av dessa.
Notan växer varje månad men ingen kan riktigt förklara varför - eller var de onödiga kronorna ligger.
Lift-and-shift gav er legacy-problem i molnet. Resultatet blev dyrare och inte snabbare.
Konton, nätverk och resurser har lagts på varandra utan plan. Ingen vågar röra något.
Ni vet inte om er molnmiljö lever upp till NIS2, GDPR eller branschkrav.
Selektivt urval av uppdrag - där senior teknisk kompetens gör störst skillnad.
Kartläggning av nuläget - arkitektur, kostnader, säkerhet och risk. Skriftlig rekommendation med prioriterad åtgärdslista.
Genomtänkt flytt till AWS, Azure eller GCP - re-architect där det lönar sig, inte bara lift-and-shift.
Landing zones, kontostruktur, nätverk och säkerhet uppsatt så att miljön skalar utan att bli ohanterlig.
Terraform-baserad infrastruktur som är reproducerbar, granskningsbar och versionshanterad.
Synliggör och kapa molnkostnader - rightsizing, reserverad kapacitet, taggning och budgetlarm.
Hybridlösningar mellan on-prem och moln, samt driftsättning som ert team kan ta över.
Tydlig process från första samtalet till levererat resultat.
Förutsättningslöst samtal om mål, nuläge och vad molnet faktiskt ska lösa.
Genomlysning av miljö, kostnader och risk. Ni får en skriftlig rekommendation.
Hands-on arbete med veckovisa avstämningar. Inga överraskningar.
Dokumentation, IaC-kod och kunskapsöverföring. Ert team äger miljön.
Transparenta upplägg utan dolda kostnader. Alla priser exkl. moms.
Genomlysning av arkitektur, kostnader och säkerhet med prioriterad åtgärdslista.
Definierat projekt med tydlig scope, tidplan och milstolpar.
Löpande arkitektur- och kostnadsrådgivning med prioriterad tillgänglighet.
Läs mer om ämnet i våra artiklar.
Svar på det jag oftast får höra.
Det beror på er befintliga stack, kompetens och krav. Jag är leverantörsoberoende och rekommenderar det som faktiskt passar er - ofta Azure för Microsoft-tunga organisationer, AWS för bredd, GCP för data och AI.
Nästan alltid. De flesta miljöer har 20-40 % onödiga kostnader i form av överdimensionerade resurser, glömda miljöer och saknade reserveringar. Genomlysningen visar var.
Ja. En vanlig situation är att en lift-and-shift gav legacy-problem i molnet. Då handlar arbetet om att modernisera de delar där det lönar sig och städa upp arkitekturen.
Terraform som standard - det ger en reproducerbar, granskningsbar och leverantörsoberoende infrastruktur. Plattformsspecifika verktyg används där de tillför värde.
Ja, fullt ut. All Terraform-kod, dokumentation och konfiguration tillhör er.
En molngenomlysning tar typiskt 1-2 veckor. För större organisationer med flera konton och komplexa nätverk kan det ta 3-4 veckor. Resultatet är en skriftlig rapport med prioriterad åtgärdslista.
Nästa steg
Har ni en ambitiös idé eller ett tekniskt vägval där det är värt att tänka rätt från början? Hör av er - förutsättningslöst.
Ta kontakt