From cloud tools to a repeatable platform foundation

An organisation running software in the cloud can have access to more tools than it can use well. Compute, storage, managed databases, container services and monitoring are a few clicks or an API call away. Yet when a new application has to go live, or an existing one needs another environment, the work often starts again from a blank page.

The reason is that infrastructure is only the foundation. Between that foundation and a working application sits a layer of decisions and routines that determines how software is actually delivered and operated. In many organisations, that layer is assembled per application, by whoever is available, and documented mainly in people’s heads.

The layer in between

That middle layer covers several areas that depend on one another:

→ Configuration: how environments are defined, which settings differ between development, test and production, and where those definitions are kept.

→ Deployment: how a change moves from a code repository into a running environment, including checks and the ability to roll back.

→ Identity and access: who and what may reach which environments and data, and how those rights are granted and withdrawn.

→ Policies: the rules environments must meet, for example on network access, resource limits or where data may be stored.

→ Monitoring: what is observed, which signals lead to alerts and who receives them.

→ Operational ownership: who is responsible for an environment once it runs, including updates, incidents and costs.

Each area can be handled well in isolation. The difficulty arises when every application handles them differently. The result is a collection of one-off set-ups that are hard to compare, maintain or hand over.

What can be repeated

Much of this work follows the same pattern across applications, which makes it a candidate for standardisation: a defined, documented way of doing something that teams reuse rather than reinvent. Standardised workflows describe, for example, how a new application is registered, which environments it receives by default and which checks every deployment passes.

GitOps is one widely used way to implement such workflows. The desired state of a system is described declaratively, in files kept under version control, and software agents continuously compare the running environment with that description and work to bring the two in line. Changes are made by changing the description, which leaves a reviewable history of who changed what, and when. OpenGitOps principles

Shared services complete the picture: common components such as logging, monitoring, secrets management or certificate handling, which applications use instead of each running their own.

What remains specific

Not everything can or should be standardised. Each organisation still has to decide which infrastructure it uses, which security and regulatory requirements apply, how access is organised, how environments are separated and who carries operational responsibility. Some applications will have needs no standard covers. A good platform foundation makes those decisions explicit and records them, rather than pretending they do not exist.

An illustrative onboarding

In a hypothetical case, a software company wants to bring a new customer-facing service onto its existing platform. Before anything is deployed, the platform team needs information: what the service does, which data it processes and how sensitive that data is, which other services it depends on and what availability is expected.

That information drives technical decisions. Which environments does the service need? Which network access is allowed? Which secrets does it require, and where are they stored? Which monitoring and alerting apply, and who responds outside office hours? With a standardised workflow, many of these questions have default answers that the team only needs to confirm or adjust.

Approvals remain part of the process. A security officer may need to approve the data classification and access rules, the owner of the production environment may need to approve the first release, and someone has to accept operational ownership. In a GitOps-based set-up, those approvals can be tied to reviewable changes in the configuration, so it is clear exactly what was approved. The work does not disappear. It becomes more predictable and easier to check.

Where N8tive fits

N8tive, a venture in development at Xablu Venture Studio, is building a platform approach for this middle layer based on Kubernetes, the open-source system for running and managing containerised applications. N8tive runs over infrastructure the organisation chooses, whether public cloud, hybrid or on-premises, with the aim of making onboarding, deployment and operations more consistent across environments. It is not a separate cloud provider. View N8tive

So far, an interactive platform prototype has been developed and a first customer migration has been carried out.

The trade-offs

Standardisation has a cost. It requires upfront decisions about defaults and exceptions, integration with existing systems such as identity providers and code repositories, and ongoing ownership: someone has to maintain the standard as tools, requirements and applications change.

It also has limits. A platform foundation does not remove the need for specialist engineering, particularly for unusual workloads or incidents. Nor does it automatically guarantee portability between infrastructures, security or regulatory compliance. It can make those properties easier to achieve and to verify, provided the underlying decisions are sound and the platform is operated with care.

Is there an application or environment in your organisation where onboarding or operations keep requiring bespoke work? Start there. We would be glad to examine it with you and identify which parts could be repeated.

Examine an environment →

← Back to all insights Discuss this perspective →