Skip to main content
FromNine
Menu

Engineering

Cloud groundwork that turns each release into a non-event.

We set up cloud foundations and internal developer platforms where every environment is defined in code, every release is signed and reproducible, and every ringgit of cloud spending can be traced to an owner.

For Malaysian organisations whose cloud must satisfy a regulator at home and, often, customers or group companies in the EU.

Arrange a discussionReference architecture
Cloud & Platform Engineering: the four layersFour layers, read downwards: applications run by product teams, the internal developer platform they build on, release pipelines that sign each artefact, and at the base a landing zone holding identity, network and policy.01Applications of product teams02Developer platform03Pipelines that sign releases04Landing zone with policies
  1. 01Policies written as code, with the hosting location of each workload agreed and recorded
  2. 02Paved routes: a new service reaches production by one repeatable path
  3. 03Recovery rehearsed, SLOs agreed and spend shown per product to whoever holds the budget

01 Common problems

When the foundation slows everyone down

  1. 01

    No two environments are alike

    Production and test have quietly diverged, nobody wrote down how, and console tweaks made by hand vanish whenever the environment is rebuilt.

  2. 02

    Every release needs a meeting

    Deployments happen rarely, by hand and late in the evening. Teams save changes up, so each release carries more risk.

  3. 03

    The monthly cloud invoice shocks finance

    Spending is reported per subscription, not per product. GPU capacity for AI goes to whichever team asked first.

  4. 04

    Nobody has tried a restore

    Backups exist, yet no restore has ever been attempted. The business has also never said how much downtime or lost data it could tolerate.

02 Scope of the service

What the service covers

  1. 01 Landing zones with an agreed hosting location

    Account and subscription structure, identity, network and guardrails on the major hyperscalers, in the cloud region you choose or on private infrastructure. Policies are code, and the hosting location of each workload is agreed with you and recorded in the contract.

    Activities

    • Tenant, management group and account hierarchy
    • Central network hub, controlled egress and private endpoints
    • Policies as code for location, encryption and tagging
    • Mapping controls to the evidence your regulator and EU customers request

    What you would receive

    • A landing zone described entirely in code
    • A library of policies with a process for exceptions
    • A hosting options paper for each class of workload

  2. 02 Infrastructure as code and developer platforms

    Infrastructure written in Terraform, OpenTofu or Bicep, deployments driven by GitOps, Kubernetes or a managed runtime where either fits, and paved routes that let a team stand up a compliant service with no ticket queue.

    Activities

    • A library of reusable infrastructure modules
    • GitOps with promotion between environments
    • Kubernetes, or a managed runtime where that is simpler
    • Starter templates and a self-service developer portal

    What you would receive

    • A developer platform with paved routes
    • Environments that teams create themselves
    • Roadmap held by a dedicated platform team

  3. 03 Release pipelines and supply-chain security

    Each artefact is built a single time, signed, given SLSA-style provenance, and then promoted unchanged from test into production, with secrets held in a vault rather than in code.

    Activities

    • Reusable pipeline templates gated on quality and security
    • Artefact signatures and provenance attestations
    • Secrets management and rotation of keys
    • Promotion policies backed by change records

    What you would receive

    • Pipeline templates teams can reuse
    • Artefacts signed, their origin checkable by anyone
    • Release evidence for your change management

  4. 04 Monitoring, SRE and incident handling

    Service level objectives agreed with the business, error budgets that set the pace of releases, OpenTelemetry across every layer, and an incident process built to meet reporting duties. For an NCII entity under the Cyber Security Act 2024 (Act 854), that means notifying within six hours and giving full details within 14 days; for EU-facing services, NIS2 or DORA timelines where they apply.

    Activities

    • Service level objectives set with each service owner
    • OpenTelemetry wired through each layer, with dashboards
    • Alerts on what users experience, not on internal causes
    • Incident command and blameless reviews afterwards

    What you would receive

    • A catalogue of service level objectives
    • A monitoring stack with dashboards
    • Runbooks for incidents and regulatory notifications

  5. 05 Cost control and AI capacity

    Spending is split by product and team, unit economics such as cost per transaction are tracked, and GPU capacity for AI is planned and kept in check.

    Activities

    • Tags that drive allocation of every cost line
    • Unit cost figures for each product
    • Planning of commitments and reservations
    • GPU queues, quotas and sizing reviews

    What you would receive

    • Cost dashboards for each product owner
    • A savings backlog with owners
    • A capacity plan for AI work

  6. 06 Recovery and exit planning

    Backup and disaster recovery with recovery time and recovery point objectives that are written down and tested on a schedule, plus an exit plan for each critical service. For companies in your group that sit in the EU, the plan can use the switching rights of the EU Data Act.

    Activities

    • Recovery time and data-loss targets set per service
    • Restores and failovers rehearsed
    • Mapping of dependencies for critical services
    • An exit plan with checks on data portability

    What you would receive

    • Recovery procedures that have been tested
    • Reports from each recovery test
    • A documented exit strategy

03 Architecture

A reference architecture, for illustration

Read the drawing from left to right: commits in, live applications out. In between, every build is signed, only signed artefacts enter the registry, and a GitOps controller advances them environment by environment, subject to policy.

Under all of this lies the landing zone, coded once and reused by every product team: hierarchy, identity, network, keys, recovery and cost guardrails.

Layers shown

Release
Commits, pipelines, signed artefacts and GitOps-driven promotion.
Platform
Developer platform, coded policies and the runtime every product team targets.
Landing zone
Hierarchy, identities, network, keys, restore capability and cost guardrails.
Operations
Telemetry, service level objectives, error budgets and incident response across the platform.
Illustrative example

  1. Release

    • Code and infrastructure repositories
    • Build, sign and attest
    • Registry of signed artefacts
    • Promotion through GitOps

  2. Platform

    • Developer platform and paved routes
    • Policies as code
    • Kubernetes and managed runtimes
    • Applications of product teams

  3. Landing zone

    • Management hierarchy
    • Identities and access rights
    • Network hub and outbound control
    • Keys and the secrets vault
    • Backups and restore
    • Cost guardrails

  4. Operations

    • Telemetry, SLOs, error budgets, incident response
Policy-governed landing zone receiving signed releases

For illustration only; this is not a system built for a client.

Read the diagram as text

Code and infrastructure repositories feed pipelines that build, sign and attest. Their output goes into an artefact registry, from there to a GitOps controller, and finally to the workload spokes of the product teams.

A developer platform offers paved routes into the pipelines. Policy as code governs the GitOps controller. A runtime of Kubernetes and managed services hosts the applications. Keys managed by the customer feed the policy layer.

The landing zone forms the base: management hierarchy, identity and access, a network hub, keys, backup and recovery, and cost guardrails. Monitoring with SLOs and incident response stretches across everything above it.

04 Trade-offs and limits

Trade-offs we plan for

  • Hosting location is a choice per workload

    What we do about it

    We group workloads by sensitivity and give each group a hosting option: a public cloud region, a dedicated or sovereign offering, or private infrastructure. Differences in features, cost and operations are documented for each choice.

    Limits and prerequisites

    Dedicated and private options often offer fewer managed services, AI services included. Some workloads will cost more or do less there, and that trade-off is yours to decide.

  • A platform needs an owner

    What we do about it

    Your internal platform gets treated like any product: it has users, a roadmap and a feedback channel. We also help you staff the team that keeps it running.

    Limits and prerequisites

    Without a team behind it, a platform becomes the place where requests wait. If staffing is not possible, our advice will be managed services and thinner abstractions.

  • Regulation shapes daily operations

    What we do about it

    Incident classification, notification timelines and evidence collection are part of the incident process wherever the Risk Management in Technology (RMiT) policy document of Bank Negara Malaysia (BNM), the technology risk guidelines of the Securities Commission Malaysia (SC), the Cyber Security Act 2024 (Act 854), NIS2 or DORA apply to you.

    Limits and prerequisites

    Whether you are an NCII entity or otherwise in scope is for your compliance and legal teams to determine, not for us.

  • Cost control is a shared task

    What we do about it

    Spending becomes visible product by product, with guardrails such as budgets, quotas and idle environments that switch off on a schedule.

    Limits and prerequisites

    The biggest savings normally come from architecture and usage choices made by product owners, more than from the platform itself.

05 Working method

Our working method

The foundation first, then one team on the paved route, then everyone else.

  1. 01

    Classify what you run

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

    ResultWorkload classification and hosting options

  2. 02

    Code the landing zone

    All of it in code, reviewed together with information security, including how exceptions are requested.

    ResultLanding zone live

  3. 03

    Start with one pilot team

    A single product team adopts the paved route first; wherever they stumble, the platform improves.

    ResultFirst service running on the platform

  4. 04

    Widen use and hand over

    Further teams follow, ownership passes to your platform team, and restores are rehearsed on a calendar.

    ResultRoadmap for the platform, plus restore test reports

06 Human oversight

Where decisions stay with people

Routine runs automatically. Choices that carry risk or cost remain with named people.

  • Every production change can be traced

    Production only changes through a reviewed commit, which leaves a permanent record of the author and the approver.

  • Emergency access is rare and recorded

    Break-glass access is time-limited, must be justified and is reviewed after use.

  • Exceptions to policy have an owner

    A workload that needs to step outside a guardrail gets a named risk owner’s approval, and that approval expires on a set date.

  • Business owners set service targets

    Recovery and availability targets come from each service’s business owner; the platform team never fixes them unilaterally.

07 Technology

Technology we use

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Dedicated, sovereign and private cloud options
Infrastructure and release
  • Terraform and OpenTofu
  • Bicep
  • Argo CD and Flux
  • Pipelines on GitHub Actions, GitLab CI or Azure DevOps
Runtime
  • Kubernetes and its managed variants
  • Serverless and container platforms
  • A service mesh where it is worth it
  • GPU node pools for AI work
Operations
  • OpenTelemetry
  • Prometheus and Grafana
  • Monitoring native to your cloud
  • Policy engines such as OPA

These names reflect hands-on engineering work. Their inclusion does not mean that a vendor partners with or endorses FromNine.

08 Scenario

An illustrative scenario

Illustrative example

Incident runbooks for an organisation designated as an NCII entity

01Starting point
An organisation has been designated as an NCII entity under Act 854. Its cloud workloads sit in two tenants with different logging, and the security team cannot confirm within six hours what an incident affects.
02What we would deliver
One landing zone in code with shared logging, an incident process that classifies events against the Act 854 timelines, and runbooks that prepare the six-hour notification and the 14-day follow-up from the same records.
03Decisions that stay with people
The chief information security officer approves the classification rules and each notification before it is sent; workload owners approve exceptions to the baseline.
04How results would be tracked
Time from detection to classification, share of workloads covered by shared logging, and recovery tests passed each quarter.

09 By industry

By industry

  • Public Sector & Government

    Hosting options per class of data, incident processes ready for the Cyber Security Act 2024 (Act 854) where an agency is designated as an NCII entity, and exit plans that outlast the next tender.

  • Financial Services

    Technology risk management in line with the RMiT policy document of Bank Negara Malaysia (BNM) and the SC Guidelines on Technology Risk Management, and DORA where you serve EU financial entities: rehearsed recovery, oversight of third-party providers and incident reporting.

Malaysia

Evidence for Malaysian regulators and EU customers

Financial institutions follow the policy document Risk Management in Technology (RMiT) of Bank Negara Malaysia (BNM), whose revised version has been in effect since 28 November 2025. Capital market intermediaries follow the Guidelines on Technology Risk Management of the Securities Commission Malaysia (SC), in effect in their revised form since 19 August 2024. Organisations designated as NCII entities under the Cyber Security Act 2024 (Act 854), in operation since 26 August 2024, notify incidents within six hours of becoming aware of them, with full details within 14 days.

Malaysian IT providers that serve EU banks or insurers meet DORA through the contract terms those clients must impose, and EU group companies may fall under national NIS2 laws. We design one landing zone in which the hosting location, logging and incident classification are policies, so each regulator’s evidence comes from the same platform and a new entity is added by configuration.

Questions on cloud and platform engineering

Which cloud provider would you advise?

The one that suits your workloads, your current contracts and your requirements on hosting location. We work on the main hyperscalers and on dedicated and private options, and we record the trade-offs so the choice holds up in procurement and can be reviewed later.

Is Kubernetes necessary for us?

Not in every case. Kubernetes repays the effort when you run many services and have a team to operate the platform. For a small number of services, a managed container or serverless platform is often simpler and cheaper to run.

How is security handled?

Security is part of the landing zone and the pipelines: identities with the least privilege, policies as code, signed artefacts and secrets that never live in code. FromNine is ISO/IEC 27001 certified for information security management.

Will our cloud bill go down?

Usually it does, but we will not name a percentage before we have seen your data. First we make spending visible per product, then we work through a savings backlog with the owners who can act on each item.

How do we keep the option to switch providers?

By choosing on purpose where to rely on provider-specific services, keeping infrastructure in code, and maintaining an exit plan that is written down and tested. For EU financial entities, DORA expects exit strategies for ICT providers, and for EU companies the Data Act strengthens the right to switch providers.

Walk us through your next three releases

You will hear what it takes to make them routine, and what that foundation would cost to build and to operate.

Arrange a discussionArchitecture & Consulting