Skip to main content
FromNine
Menu

Engineering

A cloud base where shipping a release is ordinary work.

We set up cloud foundations and developer platforms in which every environment is written as code, each release is signed and can be repeated, and someone owns each line of the bill.

For Irish organisations getting ready for the National Cyber Security Bill, and for Irish operations of international groups that answer to supervisors in several countries.

Talk to us about your projectWalk through the reference design
Cloud & Platform Engineering: the four layersA stack of four layers. At the top sit the applications your product teams run; beneath them the internal developer platform; then the pipelines that sign each release; and at the bottom the landing zone, which holds identity, networking and policy.01Applications of product teams02Developer platform03Pipelines that sign releases04Landing zone with guardrails
  1. 01Guardrails written as code, with the hosting region chosen for each workload
  2. 02Paved routes that bring a new service live the same way every time
  3. 03Service targets, proven restores and spend per product, shown to whoever signs off

01 Problems

When your cloud base starts to slow you down

  1. 01

    No two environments match

    Test drifts away from production in ways no one recorded, and console tweaks made under pressure vanish the next time the environment is rebuilt.

  2. 02

    Every deployment is an event

    Releases happen rarely, by hand, often late in the evening. So changes pile up, and every release carries more risk than it should.

  3. 03

    Nobody can explain the invoice

    Spend shows up per subscription rather than per product, and GPU capacity for AI projects goes to the team that booked it first.

  4. 04

    Restores are an act of faith

    There are backups, but no one has tried a restore, and the business never agreed how long an outage or how much data loss it can accept.

02 Delivery ledger

What you get from us

  1. 01 Landing zones and sovereign hosting choices

    The tenancy and account layout, identity, networking and guardrails on the big hyperscalers or on EU sovereign clouds, with policies in code and a hosting region fixed for each workload.

    What we do

    • Design of tenants, management groups and accounts
    • Central network hub, outbound control and private links
    • Guardrails in code for location, encryption and tags
    • Mapping to attestations your buyers or group functions request, for instance BSI C5 or SecNumCloud

    What you receive

    • A landing zone built fully from code
    • Policy set with a route for exceptions
    • Hosting options note for each class of workload

  2. 02 Infrastructure as code and developer platforms

    Terraform, OpenTofu or Bicep for the infrastructure, GitOps to deploy, Kubernetes or a managed runtime when it suits, and paved routes so a team can launch a compliant service without raising a ticket.

    What we do

    • Reusable infrastructure modules
    • GitOps that promotes between environments
    • Kubernetes platform or a managed alternative
    • Service templates and a portal for developers

    What you receive

    • Developer platform with paved routes
    • Environments teams create themselves
    • Platform roadmap held by a platform team

  3. 03 Pipelines and software supply-chain security

    Each artefact is built a single time, signed, given SLSA-style provenance and promoted unchanged from test into production, with secrets kept out of code and rotated.

    What we do

    • Pipeline templates with quality and security checks
    • Signing of artefacts and provenance records
    • Secret storage and key rotation
    • Promotion rules and a trail of changes

    What you receive

    • Pipeline templates teams can reuse
    • Signed artefacts whose origin can be verified
    • Evidence of each release for change control

  4. 04 Monitoring and site reliability

    Service targets agreed with the business, error budgets that set how fast you release, OpenTelemetry end to end, and incident handling that also covers NIS2 or DORA reporting if those rules reach you.

    What we do

    • Agreeing service targets with each owner
    • OpenTelemetry tracing, metrics and dashboards
    • Alerts on what users notice, not on every cause
    • Incident handling and reviews after each incident

    What you receive

    • Catalogue of service targets
    • Monitoring stack with dashboards
    • Runbooks for incidents and reporting

  5. 05 Cloud cost management and AI capacity

    Spend split by product and by team, unit measures like cost per transaction, plus planning and control of GPU capacity for AI work.

    What we do

    • Tagging rules and a cost allocation model
    • Unit costs tracked for each product
    • Planning of commitments and reservations
    • GPU queues, quotas and sizing

    What you receive

    • Spend dashboards for each product owner
    • List of savings, each with an owner
    • Capacity plan for AI workloads

  6. 06 Restore and exit

    Backup and disaster recovery with recovery time and recovery point targets written down and tested on a calendar, plus an exit plan that puts the EU Data Act’s switching rights to work.

    What we do

    • RTO and RPO set for each service
    • Restore and failover drills
    • Mapping what critical services depend on
    • Exit plan and checks on data portability

    What you receive

    • Recovery procedures that have been tried
    • Reports from each recovery drill
    • Written exit plan

03 Architecture

Reference architecture, for illustration

Source code enters at the left and live services leave at the right. Along the way, the pipeline signs each build, the registry accepts nothing unsigned, and a GitOps controller moves releases from one environment to the next within policy.

Below all of that is the landing zone: tenancy layout, identity, networking, keys, recovery and spend controls, set up a single time in code and used by all your product teams.

Layers in the drawing

Delivery
Repos, pipelines, signed builds and promotion through GitOps.
Platform
Developer platform, guardrails in code and the runtime teams deploy onto.
Landing zone
Tenancy, identity, networking, keys, restore and spend controls.
Operate
Telemetry, service targets, error budgets and incident handling over every layer.
Illustrative example

  1. Delivery

    • Code and infrastructure repos
    • Build, sign and attest
    • Registry of signed builds
    • Promotion through GitOps

  2. Platform

    • Developer platform and paved routes
    • Guardrails in code
    • Kubernetes and managed runtimes
    • Applications of product teams

  3. Landing zone

    • Tenancy and management
    • Identity and access
    • Network hub and outbound traffic
    • Keys and secrets
    • Backup and restore
    • Spend allocation

  4. Operate

    • OpenTelemetry, service targets, error budgets and incident handling
Signed releases onto a landing zone run by policy

An illustration, not a client’s system.

Read the diagram as text

The main path starts at code and infrastructure repositories, passes through pipelines that build, sign and attest, lands in an artefact registry, moves to a GitOps controller and ends in the workload spokes of the product teams.

A developer platform offers paved routes into the pipelines. Policies in code limit what the GitOps controller may do. A runtime of Kubernetes and managed services hosts the applications. Keys held by the customer feed into the policy layer.

Beneath it, the landing zone holds the management structure, identity and access, the network hub, keys, backup and recovery, and cost controls. Monitoring with service targets and incident handling covers the full platform.

04 Considerations and limits

What to weigh up, and where the limits are

  • Sovereign hosting comes in degrees

    How we handle it

    We sort workloads by how sensitive they are and give each group a hosting option: a hyperscaler’s EU regions, a sovereign cloud service or your own infrastructure. For a State agency this is also where the cloud-first principle of Connecting Government 2030 meets its data classes. We write the differences in features, cost and running effort into the decision.

    Limits and dependencies

    Sovereign services tend to trail behind on managed features, AI services among them. Some workloads will be dearer or less capable there, and the business has to accept that.

  • Someone has to own the platform

    How we handle it

    We run your internal platform like a product, with users, a roadmap and regular feedback, and we help you form the team that looks after it.

    Limits and dependencies

    Without a team behind it, a platform turns into a queue. If you cannot staff one, we will advise managed services and fewer layers of abstraction.

  • Regulation changes how you operate

    How we handle it

    Where NIS2 or DORA reach you, we build incident classification, reporting deadlines and evidence gathering into incident handling. In Ireland, NIS2 is still on its way through the National Cyber Security Bill as of autumn 2026, so we design to the directive and the NCSC’s draft guidance, while S.I. No. 360 of 2018 continues to apply.

    Limits and dependencies

    Whether you fall within scope, and how the final Irish Act will treat you, is for your compliance team and legal advisers to decide.

  • Spend is everyone’s job

    How we handle it

    We show spend for each product and add guardrails like budgets, quotas and automatic shutdown of environments nobody is using.

    Limits and dependencies

    The biggest reductions tend to follow from design and usage choices made by product owners. The platform cannot deliver them by itself.

05 How we work

How we work

Base first, then a single team on the paved route, then the rest of the organisation.

  1. 01

    Review and classify

    Workloads, how sensitive the data is, what you spend today and the controls your auditors will look for.

    OutputClassified workloads with target options

  2. 02

    Stand up the landing zone

    All of it in code, reviewed with your security people, with a route for exceptions.

    OutputLanding zone live

  3. 03

    Start with one pilot team

    A single product team adopts the paved route, and what slows them down shapes the platform.

    OutputFirst service live on the platform

  4. 04

    Widen and transfer

    Further teams join, your platform team takes over, and restores are drilled to a calendar.

    OutputPlatform roadmap and drill reports

06 Human control

Where your people keep control

The platform runs on automation. Anything that carries risk or cost is decided by a person.

  • Every production change has a trail

    Changes reach production only from a reviewed commit, so you can always see who made a change and who approved it.

  • Emergency access is the exception

    Break-glass access expires quickly, needs a stated reason and gets reviewed after the fact.

  • Exceptions carry a name and a date

    If a workload has to step outside a guardrail, a named risk owner signs off on it, and the exception lapses on a set date.

  • Owners decide the targets

    Recovery and service targets are agreed with the business owner of each service. The platform team does not set them on its own.

07 Technologies

Technology we use

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Sovereign cloud services in the EU
Infrastructure and delivery
  • Terraform and OpenTofu
  • Bicep
  • Argo CD and Flux
  • GitHub Actions, GitLab CI and Azure DevOps
Runtime
  • Kubernetes, self-run or managed
  • Serverless and container services
  • A service mesh when it earns its keep
  • GPU node pools for AI
Operate
  • OpenTelemetry
  • Prometheus and Grafana
  • Native cloud monitoring
  • Policy engines like OPA

A technology on this list reflects hands-on engineering work. It does not mean the vendor partners with us or endorses us.

08 Example

An example, for illustration

Illustrative example

A landing zone built to the NCSC’s draft guidance for a port company

01The situation
A port company expects to fall under the coming Irish NIS2 Act. Its terminal, logistics and billing systems sit in three cloud tenants set up at different times with different controls, and management cannot see its security posture in one place.
02What we would put in place
A single landing zone in code, with policy sets mapped to the NCSC’s draft risk-management measures, central logging, and an incident process that classifies events and prepares the report for the authority.
03Where staff decide
The head of information security approves every guardrail exception, with an end date; the board signs off the baseline once a year.
04How we would judge it
Time from detection to classification, the share of workloads covered by policy, and restore drills passed each quarter.

09 Sector lens

By sector

  • Public Service & Government

    Cloud-first hosting under Connecting Government 2030, a hosting option per data class, and exit plans that still hold when the contract goes back out on eTenders.

  • Financial Services

    Banks, insurers and fund administrators under DORA: restores that are tested, oversight of ICT providers, and incident reporting wired into daily operations.

Ireland

Ready for NIS2 before the Irish Act lands

As of autumn 2026, Ireland has not yet transposed NIS2. The General Scheme of the National Cyber Security Bill was published in August 2024 and drafting continues, while the NIS1 rules in S.I. No. 360 of 2018 remain in force. The NCSC, the planned lead authority, has already published draft guidance on risk-management measures.

Banks, insurers, fund administrators and payment firms also work under DORA, with its own incident reporting and oversight of ICT providers. If your Irish operation is part of a group, your cloud has to produce evidence for each supervisor without a separate project every time.

So we treat hosting region, logging and incident classification as policies in the landing zone, and a new entity joins by configuration. Exit plans draw on the switching rights in the EU Data Act and get drilled, not just filed.

Cloud and platform engineering: your questions

Which cloud should we pick?

Whichever suits your workloads, the contracts you already hold and the level of sovereignty you need. We work on all the major hyperscalers and on EU sovereign services, and we write down the trade-offs so you can defend the choice in a tender competition and revisit it later.

Is Kubernetes a must?

No. It earns its place once you run a large number of services and have people to operate it. With only a few services, a managed container or serverless option is usually simpler and costs less to run.

What does security look like in your builds?

It sits inside the landing zone and the pipelines from day one: minimal access rights, guardrails in code, signed builds and no secrets in source code. For operators waiting on the Irish NIS2 Act, we align controls with the NCSC’s draft guidance. FromNine holds ISO/IEC 27001 certification for its information security management.

Will you bring our cloud bill down?

In most cases, yes, though we will not quote a percentage until we have looked at the figures. First we make spend visible for each product, then we work through a savings list with the owners who can actually act on it.

How do we stay free to switch provider?

Decide on purpose where you lean on a provider’s own services, keep all infrastructure in code, and keep an exit plan that is written and tested. The EU Data Act gives you stronger rights to switch; the exit plan is what lets you use them.

Tell us about your next three releases

We will show what it takes to make them routine, and what that base would cost to build and to keep running.

Talk to us about your projectSee Architecture & Consulting