Gå til hovedindholdet
FromNine
Menu

Software & cloud

Et cloudfundament der gør releases til rutine.

Vi bygger cloudfundamenter og interne udviklerplatforme hvor miljøer er kode, releases er signerede og kan gentages, og hver krone brugt har en ejer.

For virksomheder, forsyningsselskaber og finansielle virksomheder der skal kunne dokumentere deres it-drift over for en tilsynsmyndighed.

Tal med os om dit projektSe referencearkitekturen
Cloud- og platformsudvikling: lagene i løsningenFire lag oven på hinanden. Fra øverst til nederst: produktteamenes workloads, den interne udviklerplatform, de signerede leverancepipelines og landing zonen med identitet, netværk og politikker i bunden.01Produktteamenes workloads02Intern udviklerplatform03Signerede pipelines04Landing zone og politikker
  1. 01Landing zones med politikker som kode og dataplacering fastsat pr. workload
  2. 02Golden paths der bringer en ny service i drift på en måde der kan gentages
  3. 03SLO’er, testet genetablering og omkostning pr. produkt, synligt for dem der beslutter

01 Problemer

Tegn på at fundamentet holder dig tilbage

  1. 01

    Ingen miljøer er ens

    Test og produktion adskiller sig på måder som ingen har skrevet ned, og rettelser lavet i hånden i konsollen forsvinder ved næste genopbygning.

  2. 02

    En release kræver et møde

    Udrulninger er sjældne, manuelle og lagt om aftenen. Teams samler ændringer, og det gør hver release mere risikabel.

  3. 03

    Cloudregningen overrasker alle

    Omkostningerne kan ses pr. abonnement, ikke pr. produkt. GPU-kapacitet til AI-arbejde bliver reserveret af den der spurgte først.

  4. 04

    Ingen ved om genetablering virker

    Der er backup. Gendannelse er ikke testet, og mål for genetableringstid og datatab er aldrig aftalt med forretningen.

02 Leverancer

Det leverer vi

  1. 01 Landing zones og muligheder for suverænitet

    Struktur for konti og abonnementer, identitet, netværk og sikkerhedsrammer hos de store cloududbydere og i europæiske suveræne cloudtilbud, med politikker som kode og dataplacering pr. workload.

    Det gør vi

    • Design af organisation, managementgrupper og konti
    • Hubnetværk, kontrol af udgående trafik og privat forbindelse
    • Politikker som kode for dataplacering, kryptering og mærkning
    • Kobling til de attesteringer og krav som jeres kunder og revisorer spørger efter

    Det får du

    • Landing zone defineret helt i kode
    • Politikbibliotek med proces for undtagelser
    • Notat om suverænitetsmuligheder pr. klasse af workloads

  2. 02 Infrastruktur som kode og interne udviklerplatforme

    Terraform eller OpenTofu og Bicep til infrastruktur, GitOps til udrulning, Kubernetes eller administrerede kørselsmiljøer hvor de passer, og golden paths så et team kan starte en service der overholder reglerne, uden at oprette sager.

    Det gør vi

    • Modulbibliotek til infrastruktur som kode
    • GitOps med forfremmelse mellem miljøer
    • Kubernetes-platform eller administrerede alternativer
    • Serviceskabeloner og en udviklerportal

    Det får du

    • Intern udviklerplatform med golden paths
    • Miljøer med selvbetjening
    • Platformsroadmap ejet af et platformsteam

  3. 03 Leverancepipelines og sikkerhed i forsyningskæden

    Pipelines der bygger én gang, signerer artefakter, registrerer oprindelse i tråd med SLSA, håndterer hemmeligheder korrekt og flytter det samme artefakt fra test til produktion.

    Det gør vi

    • Pipelineskabeloner med krav til kvalitet og sikkerhed
    • Signering af artefakter og attestering af oprindelse
    • Håndtering af hemmeligheder og rotation af nøgler
    • Regler for forfremmelse og registrering af ændringer

    Det får du

    • Genbrugelige pipelineskabeloner
    • Signerede artefakter med oprindelse der kan verificeres
    • Dokumentation af releases til ændringsstyring

  4. 04 Observability og SRE

    Serviceniveaumål aftalt med forretningen, fejlbudgetter der styrer releasetempoet, OpenTelemetry i hele stakken og en hændelsesproces der også dækker indberetningspligterne efter NIS 2-loven og DORA, hvor de gælder.

    Det gør vi

    • Definition af SLO’er med serviceejerne
    • Instrumentering med OpenTelemetry og dashboards
    • Alarmer på symptomer, ikke på årsager
    • Hændelseshåndtering og evaluering efter hændelser

    Det får du

    • Katalog over SLO’er
    • Observability-stak og dashboards
    • Driftsvejledninger for hændelser og indberetning

  5. 05 FinOps og kapacitet til AI

    Fordeling af omkostninger pr. produkt og team, enhedsøkonomi som omkostning pr. transaktion, og planlægning og styring af GPU-kapacitet til AI-workloads.

    Det gør vi

    • Mærkningspolitik og fordelingsmodel
    • Enhedsomkostninger pr. produkt
    • Planlægning af forpligtelser og reservationer
    • Planlægning af GPU’er, kvoter og tilpasning af størrelse

    Det får du

    • Omkostningsdashboards pr. produktejer
    • Backlog af besparelser med ejere
    • Kapacitetsplan for AI

  6. 06 Genetablering og exit

    Backup og katastrofeberedskab med udtrykkelige mål for genetableringstid og datatab, testet efter en fast plan, og en exitstrategi der bruger retten til at skifte udbyder efter dataforordningen.

    Det gør vi

    • RTO og RPO aftalt pr. service
    • Test af gendannelse og failover
    • Kortlægning af afhængigheder for kritiske services
    • Exitplan og kontrol af dataportabilitet

    Det får du

    • Testede procedurer for genetablering
    • Rapporter fra genetableringstests
    • Dokumenteret exitstrategi

03 Arkitektur

En illustrativ referencearkitektur

Koden går ind til venstre, og kørende workloads kommer ud til højre. Undervejs signerer pipelinen det den bygger, registret gemmer kun signerede artefakter, og en GitOps-controller flytter dem gennem miljøerne under politikker.

Nedenunder ligger landing zonen: organisationsstruktur, identitet, netværk, nøgler, genetablering og omkostningsstyring, defineret én gang i kode og delt af alle produktteams.

Lagene i tegningen

Leverance
Repositories, pipelines, signerede artefakter og forfremmelse med GitOps.
Platform
Udviklerplatformen, politikker som kode og det kørselsmiljø produktteams udruller til.
Landing zone
Organisation, identitet, netværk, nøgler, genetablering og FinOps-kontroller.
Drift
Telemetri, SLO’er, fejlbudgetter og hændelseshåndtering på tværs af det hele.
Eksempel

  1. Leverance

    • Repositories med kode og IaC
    • Byg, signér, attestér
    • Register med signerede artefakter
    • Forfremmelse med GitOps

  2. Platform

    • Udviklerplatform og golden paths
    • Politikker som kode
    • Kubernetes og administrerede tjenester
    • Produktteamenes workloads

  3. Landing zone

    • Managementstruktur
    • Identitet og adgang
    • Netværkshub og udgående trafik
    • Nøgler og hemmeligheder
    • Backup og genetablering
    • Fordeling af omkostninger

  4. Drift

    • OpenTelemetry, SLO’er og fejlbudgetter, hændelseshåndtering
Signeret leverance til en landing zone styret af politikker

Illustrativ arkitektur, ikke en kundes system.

Læs diagrammet som tekst

Hovedruten går fra repositories med kode og infrastruktur gennem pipelines der bygger, signerer og attesterer, ind i et artefaktregister, derefter en GitOps-controller og til sidst til produktteamenes workloads.

En intern udviklerplatform giver golden paths til pipelinerne. Politikker som kode afgrænser GitOps-controlleren. En kørselsplatform med Kubernetes og administrerede tjenester afvikler workloads. Kundestyrede nøgler leverer til politiklaget.

Landing zonen nedenunder rummer managementstruktur, identitet og adgang, et netværkshub, nøgler, backup og genetablering samt FinOps-kontroller. Observability med SLO’er og hændelseshåndtering spænder over hele platformen.

04 Hensyn og begrænsninger

Tekniske hensyn og begrænsninger

  • Suverænitet er en skala

    Sådan håndterer vi det

    Vi klassificerer workloads efter følsomhed og matcher hver klasse med en mulighed: EU-regioner hos en stor cloududbyder, et suverænt cloudtilbud eller privat infrastruktur. Afvejningerne mellem funktioner, omkostninger og drift bliver skrevet ned.

    Begrænsninger og afhængigheder

    Suveræne tilbud halter ofte bagefter med administrerede tjenester, også AI-tjenester. Nogle workloads vil koste mere eller kunne mindre dér, og det er et forretningsvalg.

  • En platform har brug for en produktejer

    Sådan håndterer vi det

    Vi behandler den interne platform som et produkt med brugere, roadmap og feedback og hjælper dig med at sætte det team op der driver den.

    Begrænsninger og afhængigheder

    En platform uden et team bliver en flaskehals. Hvis du ikke kan bemande den, anbefaler vi administrerede tjenester og færre abstraktioner.

  • Regulering former driften

    Sådan håndterer vi det

    Klassificering af hændelser, frister for indberetning og indsamling af dokumentation bygges ind i hændelsesprocessen, hvor NIS 2-loven eller DORA gælder for dig.

    Begrænsninger og afhængigheder

    Om du er omfattet, og hvordan reglerne gælder for netop din organisation, afgør dine compliance- og juridiske teams.

  • Omkostningsstyring er et fælles ansvar

    Sådan håndterer vi det

    Vi gør omkostningerne synlige pr. produkt og tilføjer rammer som budgetter, kvoter og planlagt nedlukning af miljøer der ikke bruges.

    Begrænsninger og afhængigheder

    De største besparelser kommer som regel fra arkitektur- og brugsbeslutninger som produktejerne træffer, ikke fra platformen alene.

05 Sådan arbejder vi

Sådan arbejder vi

Fundamentet først, så ét team på golden path, så alle andre.

  1. 01

    Vurdér og klassificér

    Workloads, datafølsomhed, nuværende omkostninger og de kontroller jeres revisorer forventer.

    ResultatKlassificering af workloads og mulige løsninger

  2. 02

    Byg landing zonen

    Alt som kode, gennemgået med it-sikkerhed, med en proces for undtagelser.

    ResultatLanding zone i drift

  3. 03

    Start med et pilotteam

    Ét produktteam flytter over på golden path, og teamets erfaringer former platformen.

    ResultatDen første service på platformen

  4. 04

    Skalér og overdrag

    Flere teams kommer med, platformsteamet overtager ejerskabet, og genetablering testes efter en fast plan.

    ResultatPlatformsroadmap og rapporter fra genetableringstests

06 Menneskelig kontrol

Hvor mennesker har kontrollen

Automatisering driver platformen. Mennesker ejer de beslutninger der indebærer risiko eller omkostning.

  • Ændringer i produktion kan spores

    Hver ændring i produktion kommer fra et gennemgået commit, så det altid fremgår hvem der ændrede hvad, og hvem der godkendte det.

  • Nødadgang er sjælden og logges

    Nødadgang er tidsbegrænset, kræver en begrundelse og gennemgås bagefter.

  • Undtagelser fra politikker har en ejer

    Når en workload har brug for en undtagelse fra en sikkerhedsramme, godkender en navngivet risikoejer den, med en udløbsdato.

  • Serviceejerne sætter målene

    Mål for genetablering og serviceniveau aftales med forretningsejeren af hver service, ikke af platformsteamet alene.

07 Teknologier

Teknologier vi arbejder med

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Europæiske suveræne cloudtilbud
Infrastruktur og leverance
  • Terraform og OpenTofu
  • Bicep
  • Argo CD og Flux
  • GitHub Actions, GitLab CI og Azure DevOps
Kørselsmiljø
  • Kubernetes og administrerede varianter
  • Serverless- og containerplatforme
  • Service mesh hvor det betaler sig
  • GPU-nodepuljer til AI-workloads
Drift
  • OpenTelemetry
  • Prometheus og Grafana
  • Cloudnativ overvågning
  • Politikmotorer som OPA

At vi nævner en teknologi, beskriver vores tekniske erfaring. Det betyder ikke et partnerskab med leverandøren eller at leverandøren anbefaler os.

08 Eksempel

Et illustrativt eksempel

Eksempel

En landing zone for et vandselskab omfattet af NIS 2-loven

01Udgangspunkt
Et vandselskab har cloudmiljøer der er sat op af forskellige leverandører med forskellige kontroller. Selskabet er omfattet af NIS 2-loven og skal kunne indberette hændelser til tiden og dokumentere sit sikkerhedsniveau, men ingen kan vise det samlede billede.
02Det ville vi bygge
Én landing zone i kode med politiksæt pr. klasse af workloads, fælles logning og en hændelsesproces der klassificerer hændelser og forbereder indberetningen.
03Her beslutter mennesker
Den sikkerhedsansvarlige godkender undtagelser fra politikkerne. Direktionen godkender det fælles sikkerhedsgrundlag og ser status hvert kvartal.
04Det ville vi måle
Tiden fra en hændelse opdages til den er klassificeret, andelen af workloads under politikker og antallet af beståede genetableringstests pr. kvartal.

09 Brancher

I din branche

  • Offentlig sektor

    Suverænitetsmuligheder pr. dataklasse, dokumentation til it-sikkerhedskravene og exitplaner der holder til næste udbud.

  • Finansiel sektor

    Digital operationel modstandsdygtighed efter DORA: testet genetablering, styring af tredjepartsudbydere af IKT-tjenester og indberetning af hændelser bygget ind i driften.

Danmark

NIS 2-loven og DORA i driften

NIS 2-loven har gældt i Danmark siden 1. juli 2025. Styrelsen for Samfundssikkerhed (SAMSIK) er kompetent myndighed, sektormyndighederne fører tilsyn i deres sektorer, og fristen for registrering var 1. oktober 2025. Hændelser indberettes via Virk.dk, som sender dem videre til sektormyndigheden og den nationale CSIRT. Finansielle virksomheder skal desuden følge DORA, og Finanstilsynet fører tilsyn med, at DORA overholdes.

Vi designer landing zones hvor dataplacering, logning og klassificering af hændelser er politikker, ikke projekter, så en ny enhed kommer med gennem konfiguration. Exitplaner bygger på retten til at skifte udbyder efter dataforordningen og bliver testet, ikke kun skrevet.

Spørgsmål om cloud- og platformsudvikling

Hvilken cloududbyder anbefaler I?

Den der passer til dine workloads, dine eksisterende kontrakter og dine krav til suverænitet. Vi arbejder med de store cloududbydere og europæiske suveræne tilbud og dokumenterer afvejningerne, så valget kan forsvares i et udbud og tages op igen senere.

Har vi brug for Kubernetes?

Ikke altid. Kubernetes betaler sig, når du kører mange services og har et team til at drive platformen. Til en håndfuld services er administrerede container- eller serverless-platforme ofte enklere og billigere at drive.

Hvordan griber I sikkerhed an?

Sikkerhed er bygget ind i landing zonen og pipelinerne: identiteter med mindst mulige rettigheder, politikker som kode, signerede artefakter og hemmeligheder der aldrig ligger i koden. FromNine er selv certificeret efter ISO/IEC 27001 for styring af informationssikkerhed.

Kan I sænke vores cloudomkostninger?

Som regel ja, men vi lover ingen procentsats, før vi har set dataene. Vi starter med at gøre omkostningerne synlige pr. produkt og arbejder os derefter gennem en backlog af besparelser med de ejere der kan handle på dem.

Hvordan undgår vi lock-in?

Ved bevidst at vælge hvor du afhænger af udbyderspecifikke tjenester, holde infrastrukturen i kode og vedligeholde en dokumenteret og testet exitplan. Dataforordningen styrker din ret til at skifte udbyder, og en exitplan gør retten brugbar.

Vis os dine næste tre releases

Vi fortæller dig hvad der vil gøre dem til rutine, og hvad det fundament vil koste at bygge og drive.

Tal med os om dit projektSe Arkitektur & rådgivning