Skip to main content
FromNine
Menu

Engineering

A cloud foundation on which releasing is ordinary work.

We set up cloud foundations and internal developer platforms where each environment is defined in code, each release is signed and can be repeated, and each euro spent can be traced to an owner.

For MFSA licence holders, operators in scope of the NIS2 Order and public entities that need one cloud foundation they can account for.

Start a conversationView the reference architecture
Cloud & Platform Engineering: the layers we buildFour layers shown one behind the other. Top to bottom: what product teams run, the internal developer platform, the pipelines that sign each release, and at the base the landing zone with identity, network and policy.01What product teams run02Developer platform03Pipelines that sign releases04Landing zone with policy
  1. 01Landing zones with policy in code and data location chosen for each workload
  2. 02Paved paths that bring a new service into production the same way every time
  3. 03SLOs, recovery that has been tested and cost per product, shown to those who decide

01 Common problems

Signs that your cloud base is slowing you down

  1. 01

    No two environments are alike

    Test and production differ in undocumented ways, and fixes made by hand in the console disappear with the next rebuild.

  2. 02

    Every release requires a meeting

    Deployments happen seldom, by hand and in the evening. Teams bundle their changes, and that makes every release riskier.

  3. 03

    Nobody expected that cloud invoice

    Spending shows per subscription, not per product. GPU capacity for AI work goes to whoever booked it first.

  4. 04

    No one is sure recovery would work

    There are backups, but no one has tested a restore, and the business never agreed targets for recovery time or data loss.

02 Delivery scope

Our delivery scope

  1. 01 Landing zones and options for sovereignty

    The structure of accounts and subscriptions, identity, network and guardrails, on the main hyperscalers and on sovereign EU cloud offerings, with policy written as code and the data location set for each workload.

    Our work

    • Design of the organisation, management groups and accounts
    • A hub network, outbound traffic control and private links
    • Policy in code for data location, encryption and tags
    • Mapping to the provider attestations that your clients or supervisor ask about

    What you get

    • A landing zone defined wholly in code
    • A policy library with a process for exceptions
    • A paper on sovereignty options for each class of workload

  2. 02 Infrastructure as code and developer platforms

    Terraform or OpenTofu and Bicep for the infrastructure, GitOps for deployments, Kubernetes or managed runtimes where they suit, and paved paths so that a team can launch a compliant service without raising tickets.

    Our work

    • A library of infrastructure-as-code modules
    • GitOps with promotion between environments
    • A Kubernetes platform or a managed alternative
    • Service templates and a portal for developers

    What you get

    • An internal developer platform with paved paths
    • Environments that teams create themselves
    • A platform roadmap held by a platform team

  3. 03 Pipelines and a secure software supply chain

    Pipelines that build an artefact once, sign it, record its provenance following SLSA, handle secrets correctly and promote that same artefact from test through to production.

    Our work

    • Pipeline templates with security and quality gates
    • Signing of artefacts and attestation of provenance
    • Management of secrets and rotation of keys
    • Promotion rules and records of every change

    What you get

    • Pipeline templates you can reuse
    • Signed artefacts whose provenance can be verified
    • Release evidence for your change management

  4. 04 SRE and observability

    Service level objectives agreed with the business, error budgets that set the pace of releases, OpenTelemetry through the whole stack, and an incident process that also supports reporting under the NIS2 Order or DORA where these apply to you.

    Our work

    • Defining SLOs together with service owners
    • OpenTelemetry instrumentation with dashboards
    • Alerts on what users notice, not on causes
    • Incident handling and reviews after each incident

    What you get

    • A catalogue of SLOs
    • An observability stack with dashboards
    • Runbooks for incidents and regulatory reporting

  5. 05 FinOps and capacity for AI

    Costs allocated to products and teams, unit figures such as the cost of one transaction, and planning and cost control of GPU capacity for AI workloads.

    Our work

    • A tagging policy and an allocation model
    • Unit cost figures for every product
    • Planning of commitments and reservations
    • GPU scheduling, quotas and right-sizing

    What you get

    • A cost dashboard for every product owner
    • A savings backlog with named owners
    • A capacity plan for AI work

  6. 06 Recovery and exit

    Backup and disaster recovery with stated recovery time and recovery point objectives, tested to a schedule, and an exit strategy that makes use of the switching rights granted by the EU Data Act.

    Our work

    • RTO and RPO agreed for each service
    • Tests of restores and failover
    • Mapping the dependencies of critical services
    • An exit plan and checks on data portability

    What you get

    • Recovery procedures that have been tested
    • Reports on recovery tests
    • A written exit strategy

03 Architecture

A reference architecture, shown for illustration

Code enters on the left and running workloads leave on the right. Between them, the pipeline signs whatever it builds, the registry accepts signed artefacts only, and a GitOps controller moves them from one environment to the next under policy.

Beneath lies the landing zone: the organisation structure, identity, network, keys, recovery and cost controls, written once in code and used by every product team.

Layers shown in the diagram

Delivery
Repositories, pipelines, signed artefacts and promotion through GitOps.
Platform
The developer platform, policy in code and the runtime where product teams deploy.
Landing zone
Organisation, identity, network, keys, recovery and controls on cost.
Operations
Telemetry, SLOs, error budgets and incident response over every layer.
Illustrative example

  1. Delivery

    • Repositories for code and IaC
    • Build, sign and attest
    • Registry of signed artefacts
    • Promotion through GitOps

  2. Platform

    • Developer platform and paved paths
    • Policy written as code
    • Managed services and Kubernetes
    • Workloads of product teams

  3. Landing zone

    • Management structure
    • Identity and access rights
    • Hub network and outbound traffic
    • Secrets and keys
    • Recovery and backups
    • Allocation of costs

  4. Operations

    • Incident response, OpenTelemetry, SLOs and error budgets
Signed releases onto a landing zone governed by policy

Shown for illustration only; this is not a client system.

Read the diagram as text

The main route leads from the repositories for code and infrastructure through pipelines that build, sign and attest, into a registry of artefacts, on to a GitOps controller and lastly to the workload spokes of the product teams.

An internal developer platform offers paved paths into the pipelines. Policy written as code restricts the GitOps controller. A runtime platform of Kubernetes and managed services hosts the workloads. Keys managed by the customer feed into the policy layer.

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

04 Choices and limits

Engineering choices and their limits

  • Sovereignty comes in degrees

    Our approach

    We sort workloads by how sensitive they are and give each class a suitable option: the EU regions of a hyperscaler, a sovereign cloud offering or private infrastructure. We record the trade-offs in features, cost and operations.

    Limits and what we rely on

    Sovereign offerings tend to trail in managed services, AI services among them. Some workloads will cost more or do less there, and accepting that is a business decision.

  • Every platform needs a product owner

    Our approach

    We run the internal platform as a product with its own users, roadmap and feedback, and we help you form the team that operates it.

    Limits and what we rely on

    A platform that nobody staffs turns into a bottleneck. If you cannot put a team on it, we will advise managed services and fewer layers of abstraction.

  • Maltese rules shape daily operations

    Our approach

    Where the NIS2 Order or DORA applies to you, the incident process already classifies incidents, follows the reporting timelines and collects the evidence that the CIP Department or the MFSA would expect.

    Limits and what we rely on

    Deciding whether you fall in scope, and how S.L. 460.41 or the DORA framework applies to you, remains with your compliance and legal advisers.

  • Controlling cost is a joint effort

    Our approach

    We show cost per product and add guardrails, such as budgets, quotas and automatic shutdown of environments nobody is using.

    Limits and what we rely on

    Most savings come from decisions on architecture and usage that product owners take; the platform cannot deliver them on its own.

05 Our method

Our method

The foundation first, then a single team on the paved path, and only then the other teams.

  1. 01

    Assess and classify

    Workloads, how sensitive the data is, what it costs today and which controls your auditors look for.

    ResultA classification of workloads with target options

  2. 02

    Set up the landing zone

    All of it in code, reviewed with your security staff, and with a process for exceptions.

    ResultA landing zone live in production

  3. 03

    Start with one pilot team

    A single product team moves to the paved path, and the friction they meet shapes the platform.

    ResultThe first service running on the platform

  4. 04

    Extend and hand over

    Further teams join, your platform team takes charge, and recovery is tested on a fixed schedule.

    ResultA platform roadmap with recovery test reports

06 People in control

Where people keep the decision

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

  • Every production change can be traced

    Changes reach production only from a reviewed commit, so the record always shows who made a change and who approved it.

  • Emergency access is rare and recorded

    Break-glass access expires after a set time, needs a stated reason and is reviewed after use.

  • Each policy exception has an owner

    If a workload needs an exception to a guardrail, a named risk owner approves it and sets an expiry date.

  • Service owners decide the targets

    Service levels and recovery objectives are agreed with the business owner of every service, not decided by the platform team alone.

07 Technologies

Technologies in our toolset

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Sovereign cloud offerings in the EU
Infrastructure and delivery
  • OpenTofu and Terraform
  • Bicep
  • Flux and Argo CD
  • Azure DevOps, GitLab CI and GitHub Actions
Runtime
  • Kubernetes, including managed versions
  • Container and serverless platforms
  • A service mesh where it earns its keep
  • GPU node pools for AI work
Operations
  • OpenTelemetry
  • Grafana and Prometheus
  • The cloud provider’s own monitoring
  • Policy engines, for example OPA

We list a technology because our engineers have worked with it. The list does not mean that its vendor partners with or endorses FromNine.

08 Illustrative case

An illustrative case

Illustrative example

An exit plan and a governed landing zone for a credit institution

01Starting point
A credit institution supervised by the MFSA runs its main workloads with one cloud provider. Its register of information under DORA is kept in spreadsheets, the exit plan has never been tested, and incident data is spread across three tools.
02The system we would put in place
A landing zone in code with policies for data location and logging, one incident process that classifies events and prepares the data for a report through the Licence Holder Portal, and an exit plan rehearsed against a second environment.
03Where staff decide
The institution’s ICT risk function approves policy exceptions and the exit plan; the management body signs off the overall arrangement.
04How we would judge success
Time from detecting an incident to classifying it, share of workloads under policy, and exit and recovery tests passed each quarter.

09 By sector

Sector by sector

  • Government & Public Entities

    For ministries and public entities: an option per class of data, evidence for operators in scope of the NIS2 Order, and exit plans that still hold when the next call for tenders is published.

  • Financial Services

    For MFSA licence holders: operational resilience under DORA, with recovery that has been tested, oversight of ICT third parties and incident reporting through the Licence Holder Portal built into daily operations.

Malta

One platform, evidence for the CIP Department and the MFSA

Malta brought the NIS2 Directive into force through the NIS2 Order (Legal Notice 71 of 2025, S.L. 460.41) on 23 January 2026, with the Critical Infrastructure Protection Department (CIP Department) as competent authority and a national self-registration for operators in scope. Credit institutions, insurers and investment services firms also apply DORA, in force since 17 January 2025, with the Malta Financial Services Authority (MFSA) as competent authority and major incidents reported through its Licence Holder Portal.

We build landing zones in which data location, logging and incident classification are policies rather than projects, so another entity or business line joins by configuration. Exit plans draw on the switching rights in the EU Data Act and on the DORA exit requirements, and they are tested as well as written.

Common questions on cloud and platform engineering

Which cloud provider would you advise?

Whichever suits your workloads, the contracts you already hold and the degree of sovereignty you need. We deliver on the main hyperscalers and on sovereign EU offerings, and we document the trade-offs so that you can defend the choice in a procurement procedure and review it later.

Is Kubernetes necessary for us?

Not in every case. Kubernetes is worth it when you run a large number of services and have staff to operate the platform. For a few services, a managed container or serverless platform is usually easier and cheaper to run.

What is your approach to security?

We build security into the landing zone and the pipelines: identities with the least privilege, policy in code, signed artefacts, and secrets that are never stored in code. FromNine holds ISO/IEC 27001 certification for its own information security management.

Will you bring our cloud costs down?

In most cases we can, though we will not name a percentage until we have seen your figures. First we make cost visible per product, then we work through a savings backlog with the owners who are able to act on it.

How can we stay free of lock-in?

By deciding consciously where you rely on services specific to one provider, by keeping infrastructure in code, and by keeping an exit plan that is written down and tested. The EU Data Act gives you stronger rights to switch provider, and a credit institution supervised by the MFSA will also need an exit strategy under DORA; a tested plan is what makes these usable.

Walk us through your next three releases

We will explain what would make them uneventful, and what that foundation would cost to build and to run.

Start a conversationRead about Architecture & Consulting