The operational skills a cloud-native application assumes

What does this architecture hand back to you?

Work that used to happen once, at build time, now happens continuously, at run time. A traditional deployment concentrated effort into a release event and then left the system alone for months. A cloud-native one distributes that effort into a permanent, lower-intensity stream: image updates, cluster upgrades, certificate renewals, dependency patches, cost review, and the ordinary work of a system that changes underneath you whether or not you touch it.

The exchange is favourable when there is someone to receive that stream. Deployments become routine rather than eventful, failures become smaller and more contained, and capacity stops being a procurement question. The exchange is bad when nobody owns the stream, because the work does not stop existing when it stops being done. It accumulates as an increasingly out-of-date platform that becomes progressively riskier to upgrade.

This is why the honest question before adopting the architecture is not whether the team can build it. Most competent teams can. It is whether the organisation has, or intends to fund, the capability to run it in eighteen months when the people who built it are working on something else.

Which capabilities does the architecture assume?

Six, and the pattern to notice is that none of them are exotic skills. They are ordinary responsibilities that need a named owner and a recurring slot in someone's week. The failure mode is never that nobody could do the work; it is that it belonged to everyone and therefore to nobody.

Read the third column as a diagnostic. Each of these failures is common enough to be recognisable, and each maps to exactly one missing capability rather than to a general shortage of effort.

How many people does this actually take?

For a genuine round-the-clock rota, more than most organisations expect, because a sustainable rotation needs enough people that being on call arrives infrequently enough to be tolerable. Below that threshold the rota is two people, one of whom eventually leaves, and the arrangement is a retention risk rather than an operational capability.

For business-hours operation with best-effort cover outside them, the requirement is far smaller and often amounts to part of two people's time plus a genuine willingness to protect it. The trap is claiming the first while staffing the second, which is common and only becomes visible during a major incident, when it turns out the arrangement depended on one person's personal sense of obligation.

If the numbers do not work, the answer is to reduce what has to be operated rather than to hope. Managed databases, managed queues, managed platform services and fewer distinct components all reduce the surface that requires attention at night. Buying operational simplicity is a legitimate use of budget and usually cheaper than the headcount it replaces.

Is this a platform team or is it DevOps?

The useful distinction is that a platform team builds and runs something other engineers use, while DevOps as a job title usually means one person doing the operations work for teams who are not doing any of it themselves. The second arrangement recreates exactly the separation the original idea was meant to remove, with the added disadvantage that the separation now sits in a single person.

A platform capability, however small, works when it has a product mindset: it provides paved paths, sensible defaults and self-service, and its users can ship without asking it for anything routine. That is achievable at a very small scale, because for most organisations the platform is mostly assembly of existing components rather than construction.

The signal to watch for is queueing. If application teams regularly wait on the platform person to deploy, add an environment, rotate a credential or read a log, the arrangement has become a bottleneck and will get worse as the number of services grows. The fix is automation and access, not more requests handled faster.

What should you outsource and what must stay in-house?

Outsource the platform layer with confidence: cluster management, pipeline construction, base image maintenance, upgrade cycles. These are generic, deep, and someone doing them across several organisations will do them better than someone doing them occasionally for one.

Keep two things internal regardless of arrangement. Knowledge of what the application is supposed to do, because interpreting whether the system is behaving correctly requires understanding the business, and an external party cannot acquire that from a dashboard. And the ability to deploy, because an organisation that cannot ship a change without a supplier has outsourced its own speed and will feel it during the first urgent fix.

The failure mode to guard against is the invisible handover. A supplier builds the platform, documents it in a repository nobody reads, and rotates staff away. Eighteen months later something breaks in a component nobody internal has ever touched. The protection is unglamorous and reliable: joint operation during the build, an internal person on the incident calls from day one, and a documented runbook that somebody internal has actually executed at least once.

How do you tell whether your organisation is ready?

Six questions, all answerable today. Who gets paged at three in the morning, and have they agreed to it? How long does a rollback take, measured rather than estimated? When were the base images last rebuilt? Who read last month's cloud bill? Can a new engineer deploy a trivial change on their second day? And when did the last incident produce a specific change rather than a discussion?

Any question without a name attached to it is a gap, and gaps here are additive: an organisation that cannot answer four of the six is not going to be rescued by a better architecture. It will experience the same problems with more components involved.

This is a reason to phase adoption rather than to abandon it. Move one workload, build the capability around that one, and let the second workload arrive into an environment where the answers already exist. That sequence is slower on paper and considerably faster in practice, because the alternative is discovering all six gaps simultaneously with the estate already migrated.