Skip to main content
FromNine
Menu

Engineering

Cloud foundations that make releases routine.

We build cloud foundations and internal developer platforms where environments are code, releases are signed and repeatable, and every euro of spend has an owner.

For organisations that run one cloud foundation for entities in several Member States, each with its own regulator.

Discuss your projectSee the reference architecture
Cloud & Platform Engineering: capability stackFour layers stacked in depth. From top to bottom: the workloads of product teams, the internal developer platform, the signed delivery pipelines, and the landing zone with identity, network and policy at the base.01Product team workloads02Internal developer platform03Signed delivery pipelines04Landing zone and policy
  1. 01Landing zones with policy as code and data residency set per workload
  2. 02Golden paths that take a new service to production in a repeatable way
  3. 03SLOs, tested recovery and cost per product, visible to the people who decide

01 Problems

Signs the foundation is holding you back

  1. 01

    Environments are snowflakes

    Test and production differ in ways nobody has written down, and fixes made by hand in the console are lost at the next rebuild.

  2. 02

    A release needs a meeting

    Deployments are rare, manual and scheduled for evenings. Teams batch changes, which makes each release riskier.

  3. 03

    The cloud bill surprises everyone

    Costs are visible per subscription, not per product. GPU capacity for AI work is reserved by whoever asked first.

  4. 04

    Nobody knows if recovery works

    Backups exist. Restores have not been tested, and recovery time and data-loss targets were never agreed with the business.

02 Delivery ledger

What we deliver

  1. 01 Landing zones and sovereignty options

    Account and subscription structure, identity, network and guardrails on the major hyperscalers and on EU sovereign cloud offerings, with policy as code and data residency per workload.

    What we do

    • Organisation, management group and account design
    • Hub network, egress control and private connectivity
    • Policy as code for residency, encryption and tagging
    • Mapping to the attestations your buyers ask for, such as BSI C5 or SecNumCloud

    What you receive

    • Landing zone defined entirely in code
    • Policy library with exceptions process
    • Sovereignty options paper per workload class

  2. 02 Infrastructure as code and internal developer platforms

    Terraform or OpenTofu and Bicep for infrastructure, GitOps for deployments, Kubernetes or managed runtimes where they fit, and golden paths so a team can start a compliant service without filing tickets.

    What we do

    • Module library for infrastructure as code
    • GitOps with environment promotion
    • Kubernetes platform or managed alternatives
    • Service templates and a developer portal

    What you receive

    • Internal developer platform with golden paths
    • Self-service environments
    • Platform roadmap owned by a platform team

  3. 03 Delivery pipelines and supply-chain security

    Pipelines that build once, sign artefacts, record provenance in line with SLSA, manage secrets properly and promote the same artefact from test to production.

    What we do

    • Pipeline templates with quality and security gates
    • Artefact signing and provenance attestation
    • Secrets management and key rotation
    • Promotion rules and change records

    What you receive

    • Reusable pipeline templates
    • Signed artefacts with verifiable provenance
    • Release evidence for change management

  4. 04 Observability and SRE

    Service level objectives agreed with the business, error budgets that guide release pace, OpenTelemetry across the stack and an incident process that also serves NIS2 and DORA reporting duties where they apply.

    What we do

    • SLO definition with service owners
    • OpenTelemetry instrumentation and dashboards
    • Alerting on symptoms, not causes
    • Incident management and post-incident reviews

    What you receive

    • SLO catalogue
    • Observability stack and dashboards
    • Incident and reporting runbooks

  5. 05 FinOps and AI capacity

    Cost allocation by product and team, unit economics such as cost per transaction, and GPU capacity planning and cost control for AI workloads.

    What we do

    • Tagging policy and allocation model
    • Unit cost metrics per product
    • Commitment and reservation planning
    • GPU scheduling, quotas and right-sizing

    What you receive

    • Cost dashboards per product owner
    • Savings backlog with owners
    • AI capacity plan

  6. 06 Recovery and exit

    Backup and disaster recovery with explicit recovery time and recovery point objectives, tested on a schedule, and an exit strategy that uses the switching rights in the EU Data Act.

    What we do

    • RTO and RPO agreed per service
    • Restore and failover tests
    • Dependency mapping for critical services
    • Exit plan and data portability checks

    What you receive

    • Tested recovery procedures
    • Recovery test reports
    • Documented exit strategy

03 Architecture

An illustrative reference architecture

Code goes in on the left and running workloads come out on the right. In between, the pipeline signs what it builds, the registry stores only signed artefacts, and a GitOps controller promotes them through environments under policy.

Underneath sits the landing zone: organisation structure, identity, network, keys, recovery and cost controls, defined once in code and shared by every product team.

Layers in the drawing

Delivery
Repositories, pipelines, signed artefacts and GitOps promotion.
Platform
The developer platform, policy as code and the runtime product teams deploy to.
Landing zone
Organisation, identity, network, keys, recovery and FinOps controls.
Operate
Telemetry, SLOs, error budgets and incident response across all of it.
Illustrative example

  1. Delivery

    • Code and IaC repositories
    • Build, sign, attest
    • Signed artefact registry
    • GitOps promotion

  2. Platform

    • Developer platform and golden paths
    • Policy as code
    • Kubernetes and managed services
    • Product team workloads

  3. Landing zone

    • Management structure
    • Identity and access
    • Network hub and egress
    • Keys and secrets
    • Backup and recovery
    • Cost allocation

  4. Operate

    • OpenTelemetry, SLOs and error budgets, incident response
Signed delivery onto a policy-governed landing zone

Illustrative architecture, not a client system.

Read the diagram as text

The main route runs from code and infrastructure repositories through pipelines that build, sign and attest, into an artefact registry, then a GitOps controller, and finally to workload spokes for product teams.

An internal developer platform provides golden paths to the pipelines. Policy as code constrains the GitOps controller. A runtime platform with Kubernetes and managed services hosts the workloads. Customer-managed keys feed the policy layer.

The landing zone below contains management structure, identity and access, a network hub, keys, backup and recovery, and FinOps controls. Observability with SLOs and incident response spans the whole platform.

04 Considerations and limits

Engineering considerations and limits

  • Sovereignty is a spectrum

    How we handle it

    We classify workloads by sensitivity and match each class to an option: EU regions of a hyperscaler, a sovereign cloud offering, or private infrastructure. The trade-offs in features, cost and operations are written down.

    Limits and dependencies

    Sovereign offerings often lag in managed services, including AI services. Some workloads will cost more or do less there, and that is a business choice.

  • A platform needs a product owner

    How we handle it

    We treat the internal platform as a product with users, a roadmap and feedback loops, and help you set up the team that runs it.

    Limits and dependencies

    A platform without a team becomes a bottleneck. If you cannot staff it, we will recommend managed services and fewer abstractions.

  • Regulation shapes operations

    How we handle it

    Incident classification, reporting timelines and evidence collection are built into the incident process where NIS2 or DORA apply to you.

    Limits and dependencies

    Determining whether you are in scope, and how your national transposition applies, stays with your compliance and legal teams.

  • Cost control is shared

    How we handle it

    We make cost visible per product and add guardrails such as budgets, quotas and scheduled shutdown of idle environments.

    Limits and dependencies

    The largest savings usually come from architecture and usage decisions that product owners make, not from the platform alone.

05 How we work

How we work

Foundations first, then one team on the golden path, then everyone else.

  1. 01

    Assess and classify

    Workloads, data sensitivity, current costs and the controls your auditors expect.

    OutputWorkload classification and target options

  2. 02

    Build the landing zone

    Everything as code, reviewed with security, with a process for exceptions.

    OutputLanding zone in production

  3. 03

    Onboard a lighthouse team

    One product team moves onto the golden path; their friction shapes the platform.

    OutputFirst service on the platform

  4. 04

    Scale and hand over

    More teams onboard, the platform team takes ownership, and recovery is tested on a schedule.

    OutputPlatform roadmap and recovery test reports

06 Human control

Where people stay in control

Automation runs the platform. People own the decisions that carry risk or cost.

  • Production changes are traceable

    Every change to production comes from a reviewed commit, so who changed what and who approved it is always on record.

  • Break-glass access is rare and logged

    Emergency access is time-limited, needs justification and is reviewed afterwards.

  • Policy exceptions have an owner

    When a workload needs an exception to a guardrail, a named risk owner approves it, with an expiry date.

  • Service owners set the targets

    Recovery objectives and service levels are agreed with the business owner of each service, not set by the platform team alone.

07 Technologies

Technologies we work with

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • EU sovereign cloud offerings
Infrastructure and delivery
  • Terraform and OpenTofu
  • Bicep
  • Argo CD and Flux
  • GitHub Actions, GitLab CI and Azure DevOps
Runtime
  • Kubernetes and managed variants
  • Serverless and container platforms
  • Service mesh where it pays off
  • GPU node pools for AI workloads
Operate
  • OpenTelemetry
  • Prometheus and Grafana
  • Cloud-native monitoring
  • Policy engines such as OPA

Listing a technology describes our engineering experience. It does not imply a partnership with or endorsement by its vendor.

08 Example

An illustrative example

Illustrative example

A shared landing zone for a group with entities in three countries

01Situation
Three subsidiaries run separate cloud tenants with different controls. Each national authority expects NIS2 incident reporting on its own timeline, and nobody can show the group’s security posture in one view.
02What we would build
One landing zone in code with per-entity policy sets, shared logging and an incident process that classifies and routes reports per country.
03Where people decide
Each entity’s security officer approves policy exceptions for their workloads; the group CISO owns the shared baseline.
04What we would measure
Time from incident detection to classification, share of workloads under policy, and recovery tests passed per quarter.

09 Sector lens

In your sector

  • Public Sector & Government

    Sovereignty options per data class, national security attestations, and exit plans that survive the next tender.

  • Financial Services

    Operational resilience under DORA: tested recovery, ICT third-party oversight and incident reporting built into operations.

International

Evidence once, for every supervisor

NIS2 is one directive with national transpositions that differ in scope, registration and reporting detail. Financial entities add DORA on top, with its own incident reporting and third-party oversight. A group that operates in several countries needs one platform that can produce the evidence each authority asks for.

We design landing zones where residency, logging and incident classification are policies, not projects, so a new entity or country is onboarded by configuration. Exit plans rely on the switching rights in the EU Data Act and are tested, not just written.

Questions about cloud and platform engineering

Which cloud provider do you recommend?

The one that fits your workloads, your existing contracts and your sovereignty requirements. We work across the major hyperscalers and EU sovereign offerings, and we document the trade-offs so the choice can be defended in procurement and revisited later.

Do we need Kubernetes?

Not always. Kubernetes pays off when you run many services and have a team to operate the platform. For a handful of services, managed container or serverless platforms are often simpler and cheaper to run.

How do you approach security?

Security is built into the landing zone and the pipelines: least-privilege identity, policy as code, signed artefacts and secrets that never sit in code. FromNine itself is ISO/IEC 27001 certified for information security management.

Can you reduce our cloud costs?

Usually, yes, but we will not promise a percentage before we have seen the data. We start by making cost visible per product, then work through a backlog of savings with the owners who can act on them.

How do we avoid lock-in?

By choosing deliberately where to depend on provider-specific services, keeping infrastructure in code, and maintaining a documented, tested exit plan. The EU Data Act strengthens your switching rights; an exit plan makes them usable.

Show us your next three releases

We will tell you what would make them routine, and what that foundation would cost to build and run.

Discuss your projectExplore Architecture & Consulting