Every IT estate has a herd of pets. Hand-configured servers nobody wants to touch. Applications that the business depends on but that nobody has rebuilt from scratch in years. Patching them is a project. Recovering them is a nervous Friday afternoon. Everyone knows which systems they are. Nobody is sure what to do about them.
The cloud-native conversation declared pets dead a decade ago. Cattle, not pets — disposable, reproducible, replaceable infrastructure that you treat as a class, not as named individuals. The teams building modern, product-led platforms internalised that and built accordingly. But the platform conversation mostly passed everything else by.
That's the gap worth closing. And it's a more urgent conversation than most organisations are having.
The Pet Problem Isn't a Technology Problem
"Pets vs cattle" sounds like it's about containers or Kubernetes. It isn't. It's about a set of operational capabilities that come from treating systems as reproducible rather than precious:
- You can rebuild the system from a known definition, on demand, without archaeology
- You can patch quickly when a critical vulnerability lands, because deployment is routine
- You know what's actually running, because the definition is the source of truth
- You can stand up an identical environment for testing, because the environment is code
- You can recover from failure by re-deploying rather than reviving
None of this depends on what technology the application uses. A traditional three-tier application can be cattle. A shiny Kubernetes workload can be a pet if the team operating it doesn't have these disciplines. Not every system can be literal cattle — some hold state that has to be preserved, some sit behind vendor architectures that constrain the options — but the underlying discipline applies whether or not the workload itself is disposable.
The cost of not having these capabilities only becomes visible at the worst possible moment.
Log4j Was the Wake-Up Call
When Log4j hit in December 2021, every IT organisation got the same uncomfortable lesson at the same time: knowing about a critical vulnerability is only the start. Doing something about it — quickly, safely, across the whole estate — is the actual work.
Some teams patched in hours. They had pipelines that could ship a dependency bump through dev, test, and production by the end of the afternoon. Their environments were defined as code. Their test suites caught the obvious breakage. Patching was a routine operation invoked under unusual urgency.
Others took weeks. Not because the fix was complicated — it wasn't — but because the path to production wasn't paved. Every affected application needed its own bespoke change process. Test environments had to be reconstructed by hand. Deployments depended on tribal knowledge. Every step that should have been routine was a small project.
The dividing line wasn't cloud versus data centre, or modern versus legacy. It was whether the team had internalised the disciplines that make change a routine operation — version-controlled infrastructure, automated testing, deployment as a practised habit — or whether each change was its own bespoke event.
Those disciplines weren't yet packaged as a platform in 2021. They were habits held by good teams, applied unevenly. The platform engineering movement that's emerged since is, in large part, the work of turning those habits into shared capabilities — productising the disciplines so that any team can adopt them without rebuilding from first principles. That work isn't finished. The original 2021 vulnerability is still found in production audits today, and fresh Log4j CVEs in 2026 have put the library back in scanners and CISO inboxes. Not because the fixes are hard, but because the same systems that couldn't move quickly then still can't move quickly now.
The gap isn't between teams that knew about Log4j and teams that didn't. It's between teams who'd built the disciplines to ship a fix as a routine operation and teams for whom every patch is a small project.
Velocity Isn't About Shipping Daily
A reasonable objection: not every system needs to release frequently. A line-of-business application supporting a monthly process doesn't benefit from being pushed to production every afternoon. Forcing high release cadence on systems that don't need it is a real anti-pattern.
That's true. And it misses what platform capabilities are actually for. The value isn't that you do release frequently — it's that you can, when you need to. Two very different things.
But there's a catch. Capability is a muscle, and muscles that aren't exercised atrophy. The team that hasn't shipped anything in six months doesn't have a deployment capability in reserve; they have a deployment process nobody has tested recently. When the critical patch lands, the pipeline is broken, the credentials have rotated, the test environment has drifted, and nobody remembers the exact sequence. The capability was theoretical. The reality is improvisation under pressure.
The Distinction That Resolves It
The way out is to separate pipeline activity from production release.
Pipeline activity is what happens every time a change is made — to application code, infrastructure definitions, configuration, integration logic, vendor patches, or anything else that affects how the system runs. The change is committed, the pipeline runs, the build is tested, the deployment is executed into lower environments, and the test suite confirms the system still works. This should happen often. Not because every change needs to reach production, but because this is what keeps the path paved.
Production release is a separate decision, gated on business need, change windows, and the natural cadence of the system. A monthly system can release monthly. The system can be ready to ship at any moment — fully built, tested, validated, sitting behind a release gate — while production releases happen on whatever cadence makes business sense. When a critical patch needs to bypass that cadence, it can, because everything except the final release decision has already been exercised dozens of times that month.
Production release cadence is a business decision. Pipeline cadence is an operational discipline. The first can be as slow as the system requires. The second has to be frequent enough that the path stays paved — which is what makes the first one safe to choose.
The Three Pillars That Carry the Rest
Three pillars do most of the work in moving a system from pet to cattle. None are technology-specific.
Infrastructure as Code
Most enterprises have adopted IaC in some form by now — Terraform, Ansible, Bicep, CloudFormation, the choice of tool isn't the question. The harder question is whether the IaC is actually the source of truth, or whether it's a useful artefact that the real environment has quietly diverged from.
Drift is where most organisations get stuck. A console change made under pressure during an incident. A security team applying a configuration directly. A network rule adjusted out of band. Each one a small, defensible decision. Together, they're how the gap opens between what the code says is deployed and what's actually running. The IaC repository becomes a description of what someone intended rather than a definition of what is.
The discipline isn't writing the IaC. It's keeping the IaC honest — detecting drift continuously, reconciling it deliberately, and treating any divergence as a defect to be closed rather than a normal part of operations. That's where the real unlock is. An IaC repository that genuinely reflects reality means rebuilding is a deliberate operation, audits are answerable from code, and the question "what's actually running?" has a trustworthy answer. An IaC repository that looks like the source of truth but isn't is arguably worse than not having one at all — because it creates false confidence.
Automated Testing
Without tests, every patch is a calculated risk and every change requires manual validation. The result is the pattern most organisations recognise: changes are batched up, deployed infrequently, treated as events. That isn't careful operations — it's the operational tax of not having tests. Even a basic suite covering critical paths changes the economics of every change that follows.
The Platform Underneath
These disciplines only scale if the underlying platform supports them. Pipelines, environments, deployment tooling, observability — provided as self-service capability that any application team can adopt without rebuilding from first principles. This is where the IDP earns its keep beyond the product engineering teams: the same capabilities that let a modern team ship safely should be available to the team supporting the application that finance depends on. Not a different platform, not a degraded version — the same operational foundation, applied across the estate.
What This Actually Looks Like Across Your Estate
"Everything needs platform discipline" is the easy part of the argument. The harder question is what that means for the things you actually run — because no enterprise estate is one thing. It's a mix of SaaS, COTS, and self-developed applications, and the platform plays a different role in each.
// 01
The vendor runs the application. You don't manage the infrastructure that hosts it. But you almost certainly manage a set of satellite components that sit alongside it — discovery probes, integration runtimes, monitoring collectors, identity bridges, file-transfer gateways. Some run in your cloud tenancy, some on-prem, some in hybrid setups reaching infrastructure behind a firewall. The vendor doesn't operate them — you do. They're often deployed manually, patched reluctantly, and forgotten until something breaks.
// platform's job Turn these into managed cattle. Containerised where possible, deployed via IaC, patched through pipelines, monitored as first-class citizens of the estate. Individually they look trivial. Collectively they're a non-trivial slice of unmanaged risk — and often the thing that breaks security audits.
// 02
You bought the software. You run the infrastructure. The vendor's installer is happiest with specific OS layouts and manual configuration steps, and the traditional pattern is one careful initial install followed by years of in-place patching. These are the pets that hurt most when something goes wrong.
// platform's job The platform owns everything around the vendor's installer. Infrastructure defined as code. Standardised OS images, patched and rebuilt regularly. Externalised configuration. Pipelined application-tier deployment that wraps the vendor installer in automation. Data and local state separated from compute where possible, so the compute tier can be destroyed and rebuilt without touching what matters. The vendor still owns the application's deployment model — the platform owns the substrate underneath.
// 03
Customer-facing applications, revenue-generating systems, the product. Usually the most engineering investment and the most modern practices. If platform engineering has reached anywhere, it's reached here.
// platform's job Full IDP treatment — golden paths, complete CI/CD, automated tests, progressive deployment, full observability. The real question isn't whether these teams have a platform; it's whether it's the same platform their other teams use, or one the modern teams built for themselves and nobody else can adopt.
// 04
Internal tools, reporting applications, workflow automations, integrations, departmental apps. Built by smaller teams, often with older stacks, usually outside the product engineering organisation. Where the pets multiply.
// platform's job The instinct is "they're not strategic, they don't need the full platform." That's wrong — but for a subtle reason. They don't need every feature, but they do need the same foundations. IaC, a pipeline, a reliable test environment, patched OS images. The platform provides the floor for everyone; advanced features stack on top for teams that need them. Degraded-by-choice, not degraded-by-neglect.
The shift from "developer platform" to "enterprise platform" is essentially this: the IDP as commonly described serves greenfield, cloud-native, team-owned-end-to-end workloads. The enterprise platform also serves the workloads where the team doesn't own the application itself but does own everything around it. That's most of the estate, in most organisations.
The value of a platform isn't how elegantly your best teams use it. It's how much of your application estate it actually reaches.
Where to Start
Two questions are worth answering honestly:
Which applications would you struggle to patch in 48 hours if a critical vulnerability landed tomorrow? That list is the priority list. Not the technically interesting applications. Not the ones with the most user complaints. The ones where the answer to a critical patch is "let me get back to you."
Which applications could you rebuild from scratch — definitions, infrastructure, deployment — without significant archaeology? The systems that fail this test are pets. The longer they stay that way, the higher the operational risk they carry, regardless of how stable they appear on a normal day.
Closing the gap doesn't require a big-bang modernisation programme. It requires picking the highest-risk pets and applying the same disciplines that work everywhere else — IaC for the infrastructure, automated tests for the critical paths, the platform for the deployment underneath. One system at a time. Compounding over time.
Start with a clear picture.
If you're trying to work out which parts of your estate are pets, which are cattle, and where the operational risk is genuinely concentrated, that's exactly the kind of question our assessments are designed to answer. A focused engagement, a clear findings report, and a prioritised roadmap.