Hoppa till huvudinnehållet
FromNine
Meny

Programvara och moln

En molngrund där en release är rutin, inte en händelse.

Molngrunder och interna utvecklarplattformar där varje miljö beskrivs i kod, varje release är signerad och kan göras om på samma sätt och varje euro på molnfakturan går att knyta till en ansvarig.

För organisationer i Finland som omfattas av cybersäkerhetslagen eller DORA och ofta driver samma molngrund för bolag i flera länder.

Berätta om ditt projektSe referensarkitekturen
Moln- och plattforms­utveckling: skikten i tjänstenFyra skikt ovanpå varandra. Uppifrån och ned: produktteamens tjänster, den interna utvecklarplattformen, de signerade leveransflödena och längst ned landing zone med identitet, nätverk och regler.01Produktteamens tjänster02Intern utvecklar­plattform03Signerade leveransflöden04Landing zone och regler
  1. 01Landing zones med reglerna i kod, där varje tjänst har ett bestämt lagringsområde
  2. 02Golden paths som för en ny tjänst till produktion på samma sätt varje gång
  3. 03Servicenivåmål, prövad återställning och kostnad per produkt som beslutsfattarna ser

01 Utmaningar

När molngrunden blir en broms

  1. 01

    Varje miljö är unik

    Testmiljön och produktionen skiljer sig på punkter som ingen har skrivit ned, och det som rättades för hand i konsolen är borta nästa gång miljön byggs upp.

  2. 02

    Utan möte ingen release

    Driftsättningar görs sällan, för hand och sent på kvällen. Därför samlas ändringarna i stora paket, och varje release blir mer riskfylld.

  3. 03

    Ingen kan förutse molnfakturan

    Kostnaderna syns per prenumeration men inte per produkt, och GPU-kapaciteten för AI går till den som hann boka först.

  4. 04

    Återställningen är oprövad

    Säkerhetskopior tas, men ingen har försökt läsa tillbaka dem. Hur länge ett avbrott får vara och hur mycket data som får gå förlorad har verksamheten aldrig fått besluta om.

02 Leveranser

Det här levererar vi

  1. 01 Landing zones och suveräna alternativ

    Konto- och prenumerationsstruktur, identitet, nätverk och skyddsräcken hos de stora molnleverantörerna och i suveräna molntjänster inom EU. Reglerna skrivs som kod, och för varje tjänst bestäms var uppgifterna får lagras.

    Det här gör vi

    • Utformning av organisation, hanteringsgrupper och konton
    • Hubbnätverk, kontroll av utgående trafik och privata förbindelser
    • Regler som kod för lagringsplats, kryptering och märkning
    • Koppling till de intyg och kriterier som dina köpare efterfrågar i sina upphandlingar

    Det här får du

    • Landing zone som helt och hållet är definierad i kod
    • Regelbibliotek med en process för undantag
    • Utredning om suveräna alternativ per typ av tjänst

  2. 02 Infrastruktur som kod och interna utvecklar­plattformar

    Infrastrukturen beskrivs i Terraform eller OpenTofu och Bicep, driftsättningen sköts med GitOps och Kubernetes eller förvaltade körmiljöer används där de passar. Med golden paths kan ett team starta en tjänst som följer reglerna utan att vänta på någon annan.

    Det här gör vi

    • Modulbibliotek för infrastruktur som kod
    • GitOps med befordran mellan miljöer
    • Kubernetesplattform eller förvaltade alternativ
    • Mallar för tjänster och en utvecklarportal

    Det här får du

    • Intern utvecklarplattform med golden paths
    • Miljöer som teamen skapar själva
    • Färdplan för plattformen som ägs av ett plattformsteam

  3. 03 Leveransflöden och säkerhet i leveranskedjan

    Leveransflöden som bygger varje artefakt en gång, signerar den, sparar dess ursprung enligt SLSA, sköter hemligheterna rätt och för exakt samma artefakt från test till produktion.

    Det här gör vi

    • Mallar för leveransflöden med kvalitets- och säkerhetsspärrar
    • Signering av artefakter och intyg om ursprung
    • Hantering av hemligheter och byte av nycklar
    • Regler för befordran och ändringsposter

    Det här får du

    • Återanvändbara mallar för leveransflöden
    • Signerade artefakter med verifierbart ursprung
    • Underlag för ändringshanteringen vid varje release

  4. 04 Observerbarhet och SRE

    Servicenivåmål som verksamheten har godkänt, felbudgetar som avgör releasetakten, OpenTelemetry i alla skikt och en incidentprocess som också klarar rapporteringen enligt cybersäkerhetslagen (124/2025) och DORA när de gäller för din organisation.

    Det här gör vi

    • Servicenivåmål som bestäms med tjänsteägarna
    • Instrumentering med OpenTelemetry och översiktsvyer
    • Larm på symtom, inte på orsaker
    • Incidenthantering och genomgångar efter incidenter

    Det här får du

    • Katalog över servicenivåmålen
    • Stack för observerbarhet med översiktsvyer
    • Driftinstruktioner för incidenter och rapportering

  5. 05 FinOps och kapacitet för AI

    Varje produkt och team ser sina kostnader, enhetskostnader som kostnad per transaktion följs upp och GPU-kapaciteten för AI planeras och hålls inom budget.

    Det här gör vi

    • Regler för märkning och en fördelningsmodell
    • Mått på enhetskostnad per produkt
    • Planering av åtaganden och reservationer
    • Schemaläggning, kvoter och rätt dimensionering av GPU:er

    Det här får du

    • Kostnadsvyer för varje produktägare
    • Lista över besparingar med ägare
    • Kapacitetsplan för AI

  6. 06 Återställning och exit

    Säkerhetskopiering och katastrofåterställning med bestämda mål för hur länge ett avbrott får vara och hur mycket data som får gå förlorad, prövade enligt schema, och en exitstrategi som bygger på rätten att byta molnleverantör i dataförordningen.

    Det här gör vi

    • RTO och RPO bestämda för varje tjänst
    • Tester av återställning och omkoppling
    • Kartläggning av beroenden för kritiska tjänster
    • Exitplan och kontroll av dataportabiliteten

    Det här får du

    • Testade rutiner för återställning
    • Rapporter från återställningstesterna
    • Dokumenterad exitstrategi

03 Arkitektur

En illustrativ referens­arkitektur

Till vänster kommer koden in och till höger kommer färdiga tjänster ut. Mellan dem signerar leveransflödet varje bygge, registret tar bara emot signerade artefakter och en GitOps-kontroller flyttar dem genom miljöerna så som reglerna tillåter.

Grunden är landing zone, där organisationsstruktur, identitet, nätverk, nycklar, återställning och kostnadskontroll beskrivs en enda gång i kod och delas av alla produktteam.

Skikten i bilden

Leverans
Förråd, leveransflöden, signerade artefakter och befordran med GitOps.
Plattform
Utvecklarplattformen, regler som kod och körmiljön som produktteamen driftsätter i.
Landing zone
Organisation, identitet, nätverk, nycklar, återställning och FinOps-kontroller.
Drift
Telemetri, servicenivåmål, felbudgetar och incidenthantering för allt detta.
Illustrativt exempel

  1. Leverans

    • Kod- och IaC-förråd
    • Bygga, signera, intyga
    • Register för signerade artefakter
    • Befordran med GitOps

  2. Plattform

    • Utvecklar­plattform och golden paths
    • Regler som kod
    • Kubernetes och förvaltade tjänster
    • Produktteamens tjänster

  3. Landing zone

    • Hanterings­struktur
    • Identitet och åtkomst
    • Nätverkshubb och utgående trafik
    • Nycklar och hemligheter
    • Säkerhets­kopiering och återställning
    • Kostnads­fördelning

  4. Drift

    • OpenTelemetry, servicenivåmål och felbudgetar, incident­hantering
Signerad leverans till en regelstyrd landing zone

Illustrativ arkitektur, inte ett kundsystem.

Läs diagrammet som text

Bilden visar hur kod och infrastrukturbeskrivningar går genom leveransflöden som bygger, signerar och intygar, vidare till ett artefaktregister och en GitOps-kontroller och till sist ut till produktteamens tjänster.

Utvecklarplattformen ger teamen golden paths in i leveransflödena. Regler i kod sätter ramarna för GitOps-kontrollern, och tjänsterna körs på en plattform med Kubernetes och förvaltade tjänster. Kundhanterade nycklar används av regelskiktet.

Under detta ligger landing zone med hanteringsstruktur, identitet och åtkomst, nätverkshubb, nycklar, säkerhetskopiering och återställning samt kostnadskontroll. Observerbarheten med servicenivåmål och incidenthantering täcker hela plattformen.

04 Överväganden och gränser

Tekniska avvägningar och gränser

  • Suveränitet finns i flera grader

    Så hanterar vi det

    Tjänsterna delas in efter hur känsliga uppgifterna är, och varje grupp får ett alternativ: en EU-region hos en stor molnleverantör, en suverän molntjänst eller egen infrastruktur. Vad valet betyder för funktioner, kostnad och drift dokumenteras.

    Gränser och beroenden

    I suveräna moln finns ofta färre färdiga tjänster, också för AI. En del tjänster blir då dyrare eller får färre funktioner, och det avvägandet gör verksamheten.

  • Plattformen behöver en ägare

    Så hanterar vi det

    Den interna plattformen sköts som en produkt med användare, färdplan och återkoppling, och vi hjälper till att bygga upp teamet som ansvarar för den.

    Gränser och beroenden

    Utan ett team blir plattformen en flaskhals. Går det inte att bemanna rekommenderar vi förvaltade tjänster och en enklare plattform.

  • Lagarna påverkar driften

    Så hanterar vi det

    Gäller cybersäkerhetslagen (124/2025) eller DORA för din organisation byggs klassning av incidenter, rapporteringens tidsfrister och insamling av belägg in i incidentprocessen.

    Gränser och beroenden

    Om organisationen omfattas och hur lagen ska tillämpas avgör de egna juristerna och de som ansvarar för regelefterlevnaden.

  • Kostnaderna är allas ansvar

    Så hanterar vi det

    Kostnaden visas per produkt, och skyddsräcken som budgetar, kvoter och automatisk avstängning av oanvända miljöer läggs till.

    Gränser och beroenden

    De stora besparingarna kommer i regel av hur produktägarna väljer att bygga och använda tjänsterna, inte av plattformen ensam.

05 Arbetssätt

Så arbetar vi

Grunden först, sedan ett första team på en golden path och därefter resten av organisationen.

  1. 01

    Kartlägg och klassa

    Tjänsterna, hur känsliga uppgifterna är, vad allt kostar i dag och vilka kontroller revisorerna och tillsynsmyndigheten väntar sig.

    ResultatKlassade tjänster och alternativ för målläget

  2. 02

    Bygg landing zone

    Allt i kod, granskat tillsammans med informationssäkerheten och med en rutin för undantag.

    ResultatLanding zone i drift

  3. 03

    Börja med ett pilotteam

    Ett produktteam börjar använda en golden path, och det som skaver för dem formar plattformen.

    ResultatDen första tjänsten på plattformen

  4. 04

    Bredda och lämna över

    Fler team ansluts, plattformsteamet tar över ägarskapet och återställningen prövas enligt schema.

    ResultatPlattformens färdplan och rapporter från återställningsprov

06 Mänsklig kontroll

Där människor behåller kontrollen

Plattformen sköts av automatik. De beslut som innebär risk eller kostnad har en människa som ägare.

  • Varje ändring i produktion är spårbar

    Ändringar når produktionen bara via en granskad commit, så det framgår alltid vem som ändrade vad och vem som godkände ändringen.

  • Nödåtkomst används sällan och loggas

    Nödåtkomsten gäller en begränsad tid, kräver en motivering och gås igenom i efterhand.

  • Varje undantag har en ägare och ett slutdatum

    Behöver en tjänst avvika från ett skyddsräcke krävs ett godkännande från en namngiven riskägare, och undantaget upphör vid ett bestämt datum.

  • Tjänsteägaren bestämmer målen

    Målen för servicenivå och återställning bestäms tillsammans med den som äger tjänsten i verksamheten, inte av plattformsteamet ensamt.

07 Teknik

Tekniker vi arbetar med

Moln
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Suveräna molntjänster i EU
Infrastruktur och leverans
  • Terraform och OpenTofu
  • Bicep
  • Argo CD och Flux
  • GitHub Actions, GitLab CI och Azure DevOps
Körmiljö
  • Kubernetes och förvaltade varianter
  • Serverlösa plattformar och containerplattformar
  • Service mesh där det lönar sig
  • GPU-nodpooler för AI
Drift
  • OpenTelemetry
  • Prometheus och Grafana
  • Molnleverantörernas egen övervakning
  • Regelmotorer som OPA

Teknikerna nämns för att visa vilken erfarenhet vi har. Det betyder inte att vi är partner till tillverkarna eller att de har gått i god för oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

En gemensam landing zone för en livsmedels­koncern med bolag i tre länder

01Utgångsläge
En livsmedelsproducent har bolag i Finland, Sverige och Estland, och varje bolag har en egen molnmiljö med olika kontroller. Det finländska moderbolaget omfattas av cybersäkerhetslagen (124/2025), myndigheterna i de andra länderna förväntar sig rapporter enligt sina egna regler och ingen kan visa koncernens säkerhetsläge i en enda vy.
02System
En landing zone i kod med regeluppsättningar per bolag, gemensam loggning och en incidentprocess som klassar varje incident och styr rapporten till rätt myndighet i rätt land.
03Mänsklig kontroll
Varje bolags säkerhetsansvariga godkänner undantag för sina egna tjänster; koncernens informationssäkerhetschef äger den gemensamma grundnivån.
04Det här skulle vi mäta
Tiden från upptäckt till klassning av en incident, andelen tjänster som omfattas av reglerna och antalet godkända återställningstester per kvartal.

09 Branscher

I din bransch

  • Offentlig sektor

    Suveräna alternativ per uppgiftsklass, de säkerhetskrav som myndigheten ställer och exitplaner som håller också vid nästa upphandling enligt upphandlingslagen.

  • Finansiella tjänster

    Digital operativ motståndskraft enligt DORA, vars efterlevnad Finansinspektionen övervakar: testad återställning, uppföljning av IKT-leverantörer och incidentrapportering inbyggd i driften.

Finland

Underlag som håller för den finländska tillsynen

Cybersäkerhetslagen (124/2025) genomför NIS2-direktivet i Finland och har gällt sedan 8 april 2025; aktörernas anmälningsfrist gick ut 8 maj 2025. Tillsynen sköts av sektorsmyndigheter som Traficom, Energimyndigheten, Säkerhets- och kemikalieverket och Tillstånds- och tillsynsverket, medan Cybersäkerhetscentret vid Traficom är gemensam kontaktpunkt. För banker, försäkringsbolag och andra finansiella aktörer gäller dessutom DORA sedan 17 januari 2025, och Finansinspektionen övervakar efterlevnaden.

Finländska koncerner har ofta bolag också i Sverige och Baltikum, där NIS2 har genomförts med andra detaljer. Vi bygger landing zones där lagringsplats, loggning och klassning av incidenter är regler och inte projekt, så att ett nytt bolag eller land kan anslutas genom konfiguration. Exitplanerna bygger på rätten att byta leverantör enligt dataförordningen och testas i stället för att bara skrivas.

Frågor om moln- och plattforms­utveckling

Vilken molnleverantör rekommenderar ni?

Den som passar dina tjänster, de avtal du redan har och dina krav på suveränitet. Vi arbetar med de stora molnleverantörerna och med suveräna molntjänster i EU och skriver ned vad som talar för och emot, så att valet kan motiveras i en upphandling enligt upphandlingslagen och prövas på nytt senare.

Behöver vi Kubernetes?

Inte nödvändigtvis. Kubernetes lönar sig när många tjänster körs och det finns ett team som kan sköta plattformen. Med bara några få tjänster är förvaltade container- eller serverlösa plattformar oftast enklare och billigare.

Hur ser ni på säkerheten?

Säkerheten byggs in i landing zone och leveransflödena: identiteter med minsta möjliga behörighet, regler som kod, signerade artefakter och hemligheter som aldrig ligger i koden. FromNine har själv ett ledningssystem för informationssäkerhet som är certifierat enligt ISO/IEC 27001. Om din organisation omfattas av cybersäkerhetslagen (124/2025) bygger vi in riskhanteringen, loggarna och incidentprocessen med dess tidsfrister i landing zone. Tillsynen sköts av sektorsmyndigheterna, och Cybersäkerhetscentret vid Traficom är gemensam kontaktpunkt. Om lagen gäller just din organisation bedömer dina jurister.

Kan ni sänka våra molnkostnader?

Ofta, men någon procentsats lovar vi inte innan vi har sett siffrorna. Först synliggörs kostnaden per produkt, och sedan arbetar vi igenom besparingarna tillsammans med de ägare som kan genomföra dem.

Hur undviker vi inlåsning?

Genom att välja medvetet var du ska vara beroende av en enskild leverantörs tjänster, beskriva infrastrukturen i kod och ha en exitplan som är skriven och prövad. Dataförordningen ger dig rätt att byta molnleverantör, och exitplanen gör att rätten går att använda.

Visa oss dina tre kommande releaser

Vi visar vad som skulle göra dem till rutin och vad en sådan grund kostar att bygga och driva.

Berätta om ditt projektLäs om arkitektur