Skip to main content
FromNine
Menu

Engineering

A cloud base that turns releases into routine work.

We build cloud landing zones and internal developer platforms in which every environment is defined as code, every release is signed and repeatable, logs meet CERT-In requirements, and each rupee of cloud spend is assigned to an owner.

For Indian banks, NBFCs, market intermediaries and IT providers whose cloud must satisfy Indian regulators and European customers at once.

Share your requirementsView the reference architecture
Cloud & Platform Engineering: the four layersFour layers drawn one behind the other. Top: the applications of product teams. Second: the internal developer platform. Third: the signed release pipelines. Bottom: the landing zone holding identity, network and policy.01Product team applications02Internal developer platform03Signed release pipelines04Landing zone and policies
  1. 01Landing zones with policies in code and the permitted region fixed for each workload
  2. 02Paved paths that bring a new service into production the same way every time
  3. 03Service levels, rehearsed recovery and cost per product, visible to the people who approve budgets

01 Challenges

Signs that the cloud base is slowing you down

  1. 01

    Each environment is a one-off

    UAT and production differ in ways nobody has documented, and manual fixes made in the console disappear at the next rebuild.

  2. 02

    Every release requires a call

    Deployments are infrequent, manual and booked for late evenings. Teams bundle changes together, so each release carries more risk.

  3. 03

    The monthly cloud invoice is a surprise

    Spending is visible per subscription rather than per product. GPU capacity for AI work goes to whichever team asked first.

  4. 04

    Logs are missing when an incident occurs

    Listed incidents must reach CERT-In within six hours, yet logs sit in separate accounts with unsynchronised clocks, and no restore has ever been rehearsed.

02 Scope of work

Scope of the practice

  1. 01 Landing zones and data location choices

    Account and subscription layout, identity, network and guardrails on the main hyperscalers, with policies in code that fix the region each workload may use as your contracts and sectoral rules require.

    Scope of work

    • Design of the organisation, management groups and accounts
    • Hub network, outbound traffic control and private links
    • Policies in code for region, encryption, tagging and log retention
    • Mapping to the evidence your regulator or EU customers request, such as SEBI CSCRF controls or DORA contract terms

    Deliverables

    • Landing zone defined fully as code
    • Policy library with a process for exceptions
    • Paper setting out data location options for each class of workload

  2. 02 Infrastructure as code and developer platforms

    Terraform or OpenTofu and Bicep for infrastructure, GitOps for releases, Kubernetes or managed runtimes where suitable, and paved paths that let a team launch a compliant service without raising tickets.

    Scope of work

    • Library of infrastructure modules
    • GitOps with promotion between environments
    • Kubernetes platform or managed alternatives
    • Service templates and a developer portal

    Deliverables

    • Developer platform with paved paths
    • Environments teams create for themselves
    • Roadmap owned by an internal platform team

  3. 03 Release pipelines and software supply chain security

    Pipelines that build an artefact once, sign it, record its provenance as SLSA describes, keep secrets out of code and promote the identical artefact from UAT to production.

    Scope of work

    • Pipeline templates with quality and security gates
    • Signing of artefacts and provenance attestations
    • Secrets management and key rotation
    • Promotion rules and change records

    Deliverables

    • Pipeline templates reused across teams
    • Signed artefacts with provenance that can be verified
    • Release evidence for your change advisory board

  4. 04 Monitoring, logging and SRE

    Service level objectives agreed with the business, error budgets that set the pace of releases, OpenTelemetry throughout, logs retained and time-synchronised as the CERT-In Directions require, and an incident process that supports six-hour reporting in India and NIS2 or DORA timelines for EU customers.

    Scope of work

    • Defining SLOs with each service owner
    • OpenTelemetry instrumentation, central log store and clock synchronisation
    • Alerts based on symptoms rather than causes
    • Incident handling and post-incident reviews

    Deliverables

    • Catalogue of SLOs
    • Monitoring stack, log retention and dashboards
    • Runbooks for incidents and for regulatory reporting

  5. 05 FinOps and GPU capacity

    Cloud cost assigned to products and teams, unit economics such as cost per transaction or per policy issued, and planning and cost control for GPU capacity used by AI workloads.

    Scope of work

    • Tagging policy and allocation model
    • Unit cost measures for each product
    • Planning of commitments and reservations
    • GPU scheduling, quotas and right-sizing

    Deliverables

    • Cost dashboards for each product owner
    • Backlog of savings with owners
    • Capacity plan for AI workloads

  6. 06 Recovery and exit planning

    Backup and disaster recovery with stated recovery time and recovery point objectives, rehearsed on a calendar, and an exit plan that an EU bank you serve can rely on under DORA and that your own outsourcing policy can accept.

    Scope of work

    • RTO and RPO agreed for each service
    • Restore and failover drills
    • Map of dependencies for critical services
    • Exit plan and checks on data portability

    Deliverables

    • Recovery procedures that have been tested
    • Reports from each recovery drill
    • Written and rehearsed exit plan

03 Architecture

Reference architecture (illustrative)

Source code enters at one end and running applications emerge at the other. Between them, the pipeline signs each build, the registry accepts only signed artefacts, and a GitOps controller moves them through environments within the policies that apply.

Below lies the landing zone: organisation layout, identity, network, keys, central logs, recovery and cost controls, all written once in code and shared by every product team.

Layers shown

Release
Repositories, pipelines, signed artefacts and promotion through GitOps.
Platform
Developer platform, policies in code and the runtime that product teams deploy onto.
Landing zone
Organisation, identity, network, keys, recovery and cost controls.
Operations
Telemetry, synchronised logs, SLOs, error budgets and incident response across every layer.
Illustrative example

  1. Release

    • Application and IaC repositories
    • Build, sign and attest
    • Registry of signed artefacts
    • GitOps promotion

  2. Platform

    • Developer platform and paved paths
    • Policies in code
    • Kubernetes and managed services
    • Product team applications

  3. Landing zone

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

  4. Operations

    • OpenTelemetry, central logs, SLOs and incident response
Signed releases on a policy-controlled landing zone

An illustration only; not drawn from any client system.

Read the diagram as text

The primary path leads from application and infrastructure repositories through pipelines that build, sign and attest, into an artefact registry, on to a GitOps controller and finally into the workload accounts of the product teams.

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

The landing zone underneath holds the management structure, identity and access, a network hub, keys, backup and recovery, and cost controls. Monitoring with SLOs, central logs and incident response covers the entire platform.

04 Trade-offs and limits

Design trade-offs and limits

  • Data location is a set of choices

    How we address it

    We group workloads by sensitivity and assign each group a location: a public cloud region, a dedicated or private cloud, or your own data centre. The differences in services, cost and operations are recorded for each choice.

    Limits and prerequisites

    Private and dedicated set-ups often lack managed services, AI services among them. Some workloads will cost more or offer less there, and that is a decision for the business.

  • The platform needs its own product owner

    How we address it

    We run the internal platform as a product with users, a roadmap and feedback, and help you form the team that will operate it.

    Limits and prerequisites

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

  • Regulators shape day-to-day operations

    How we address it

    Incident classification, reporting deadlines and evidence collection are designed into the incident process: CERT-In reporting in India, and NIS2 or DORA timelines where your EU customers pass them on to you.

    Limits and prerequisites

    Whether a particular rule applies to you, and how, is for your compliance and legal teams to decide.

  • Cloud cost is a shared responsibility

    How we address it

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

    Limits and prerequisites

    The biggest savings normally come from design and usage choices made by product owners, not from the platform by itself.

05 Delivery steps

Delivery steps

The foundation comes first, then a single team on the paved path, then the remaining teams.

  1. 01

    Review and classify

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

    OutcomeClassification of workloads and target options

  2. 02

    Build the landing zone

    Everything as code, reviewed with information security, with a defined route for exceptions.

    OutcomeLanding zone live in production

  3. 03

    Start with one pilot team

    A single product team adopts the paved path, and the friction it meets shapes the platform.

    OutcomeFirst service live on the platform

  4. 04

    Extend and hand over

    Further teams join, your platform team takes ownership, and recovery is rehearsed on a fixed calendar.

    OutcomePlatform roadmap and recovery drill reports

06 Approvals

Who approves what

Automation operates the platform. People remain answerable for decisions that carry risk or cost.

  • Every production change can be traced

    Each change in production originates in a reviewed commit, so the record always shows who changed what and who approved it.

  • Emergency access is exceptional and logged

    Break-glass access expires automatically, requires a stated reason and is reviewed after use.

  • Exceptions to policy have an owner

    If a workload needs to depart from a guardrail, a named risk owner approves the exception and sets its expiry date.

  • Service owners set the targets

    Recovery objectives and service levels are agreed with the business owner of each service rather than fixed by the platform team.

07 Technology

Technology we use

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Private and dedicated cloud set-ups
Infrastructure and releases
  • Terraform and OpenTofu
  • Bicep
  • Argo CD and Flux
  • GitHub Actions, GitLab CI or Azure DevOps
Runtime
  • Kubernetes, self-managed or managed
  • Serverless and container platforms
  • A service mesh where it justifies itself
  • GPU node pools for AI
Operations
  • OpenTelemetry
  • Prometheus and Grafana
  • Monitoring native to your cloud
  • Policy engines such as OPA

A product listed here reflects our engineering experience with it, not a partnership with or endorsement by its vendor.

08 Scenario

Illustrative scenario

Illustrative example

A landing zone for an asset management company

01Starting point
An asset management company runs its investor portal, fund accounting interfaces and analytics in three cloud accounts with different controls. Logs are kept in each account with its own clock, and the team cannot show how it would meet the six-hour CERT-In deadline or produce evidence for SEBI’s CSCRF.
02What we would set up
One landing zone in code with policy sets per environment, a central log store with retention and synchronised clocks, and an incident process that classifies an event and prepares the CERT-In report.
03Where an officer decides
The chief information security officer approves every policy exception and owns the shared baseline; the incident manager decides whether an event is reportable.
04How success would be measured
Time from detection to a classified incident, share of workloads under policy, and recovery drills passed each quarter.

09 By industry

By industry

  • Government & Public Sector

    Data location fixed per class of data, logs and incident handling designed to the CERT-In Directions, and exit plans that hold when the next bid is awarded.

  • Banking & Financial Services

    For banks, NBFCs and AMCs, controls mapped to RBI’s outsourcing directions and SEBI’s CSCRF; for Indian providers to EU banks, DORA contract terms, rehearsed recovery and exit plans.

India

Evidence for Indian regulators and EU customers

The CERT-In Directions of 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000, require listed cyber incidents to be reported within six hours of being noticed, ICT logs to be retained and system clocks to be synchronised. SEBI-regulated entities also work to the Cybersecurity and Cyber Resilience Framework (CSCRF), and RBI-regulated entities to RBI’s directions on IT governance and on outsourcing risks.

If you provide ICT services to banks or insurers in the EU, DORA requires them to write specific terms into your contract, wherever you are based (Article 30), and NIS2 reaches you through your EU customers’ supply chain measures. We design landing zones where logging, data location and incident classification are policies rather than projects, so each regulator or customer gets its evidence from the same platform.

FAQs on cloud and platform engineering

Which cloud provider should we use?

Whichever suits your workloads, your current agreements and any rules on where data may be processed. We work on all the main hyperscalers and on private set-ups, and we record the trade-offs so the decision stands up to procurement and audit scrutiny and can be reopened later.

Is Kubernetes necessary for us?

Not in every case. It is worthwhile when you operate many services and have a team to run the platform. For a small number of services, managed container or serverless options are usually simpler and less costly to operate.

How is security built in?

Through the landing zone and the pipelines: least-privilege identities, policies 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 spending down?

In most cases, yes, though we will not quote a percentage before seeing your billing data. First we show cost per product; then we work through a list of savings with the owners who can act on each item.

How do we limit dependence on one provider?

By deciding consciously where to use provider-specific services, keeping all infrastructure in code, and maintaining an exit plan that is written down and rehearsed. EU banks and insurers you serve must have exit strategies under DORA for ICT services that support critical or important functions, and a tested plan is what they will ask to see.

Show us your next three releases

We will explain what would make them routine and what that foundation would cost to build and to operate.

Share your requirementsArchitecture & Consulting