Hybrid Platforms Trends: Platform Engineering and the Rise of Autonomous IT

One thing has been on my mind for a while now: how our current technology estates have become too complex for humans to operate efficiently.

For 20 years, enterprises have optimised infrastructure, yet we still have very similar conversations today: how do we deliver at pace while retaining control? The technology may differ from place to place, but the overall challenges remain the same. I believe that over the next decade, we need to focus on optimising developer productivity and operational simplicity. This will mean pulling down the silos and making a fundamental change in the operating model for application and platform teams.

Platform engineering represents the shift from building infrastructure to delivering platforms that enable faster, safer and more autonomous digital delivery. When we think about the foundational imperatives and strategic priorities I have been talking about for 2026, this conversation aligns with all six of them.

Three Foundational Imperatives

• Building a Platform for Modernisation
• Digital Resilience Is Now Business Resilience
• The Network as a Strategic Enabler

Three Foundational Imperatives

• Operational Simplicity
• Security Everywhere
• Economic Discipline

Let’s explore how operational complexity has become the new technical debt and where platform engineering takes us next.

Infrastructure Silos to Internal Platforms

No one sets out to build complexity; it builds over time, a merger one year, three cloud strategies driven by the constant churn at C-Level, or another tool to solve a pressing tactical problem. Before long, you are operating dozens of platforms, hundreds of tools and thousands of services. I have made the point before that raw infrastructure capacity is rarely what holds organisations back; the bigger barrier is the operational complexity we have built up while solving everything else. I am sure that every decision along the journey was valid, but the overall outcome is hidden behind the built complexity.

Hybrid cloud, multi-cloud, Kubernetes, AI and DevSecOps have all become standard conversations, but I still see siloed operating models and teams being built to solve the next wave of innovation. Each of these tools or technologies provides operations teams with a new capability, and each adds another layer to learn, run, and secure. That is the trade-off we have been accepting over the past decade or so: more capability, more to operate, more gaps to worry about. The reality is that this cannot continue as we move forward.

The hidden cost of complexity

Most infrastructure teams and tech stacks were built for stability and are reliant on a depth of specialist knowledge that is in short supply. Separate teams for servers, storage, networking, security, virtualisation and public cloud made good sense when systems were predictable, and agility was not the core driver. Also, each of these technology siloes used to operate as such; today, most are linked, security and networking have converged, servers, storage and virtualisation have done the same. Cloud and On-Premises have aligned into a hybrid and are in desperate need of an unfired operating model; the Internal Developer Platform can form a core part of this operating model.

That world of siloed delivery needs to be left behind, as applications now stretch across edge, private cloud, public cloud, containers, and AI infrastructure. The boundaries between those old teams have blurred, but the silos have not, and the gaps between them are the junction where operational challenges arise.

The symptoms are easy to recognise in most enterprise IT operational teams and architectures:

• Tool sprawl is impacting cost and operational simplicity: Jenkins, GitHub, Terraform, Ansible, ServiceNow, Kubernetes, an observability stack, security platforms, On-Premise, Cloud and Edge. Each one is likely strategic on its own, but together they form a stack that no single person fully understands, further compounding the operational challenge.
• Skills fragmentation is a challenge: People become experts in tools rather than outcomes, and that expertise ends up trapped in silos. Human nature is to hoard knowledge, make oneself the oracle under the assumption that it makes one indispensable and the hero of the next crisis.
• Slow Pace of Delivery and Innovation: Developers raise tickets, wait for environments and pick up infrastructure work that has little to do with the product they are trying to ship. This impacts developer velocity and is at the core of many platform engineering conversations we are seeing today.
• Inconsistent operations leave gaps: Teams build, deploy, and secure in their own ways, making results hard to predict and gaps a significant challenge.

This is now technical debt by another name, while not a direct cost line, it does impact as lost time, slower delivery, security gaps and ’busy’ teams, and when I say ‘busy’ I don’t mean the good kind. Like any debt, it compounds with every new initiative.

The reality of all of this is a simple view for the future:

Organisations should no longer consume infrastructure; they should consume platforms. A platform gives people a single, consistent way to get what they need without having to understand everything beneath it. That is as much an organisational change as a technical one, and it is the harder element to get right”

Enter platform engineering

Platform engineering takes the product thinking we apply to customer-facing software and points it inward, at infrastructure. The aim is a set of self-service capabilities that let development teams consume secure, standardised services without needing to know how the engine works beneath the surface. In practice, that means:

• Developer Self-service: An environment is available in minutes rather than a ticket and a wait.
• Golden paths: Approved patterns that make the right way the easy way.
• Security built in by default: Being honest, developers want to write code and seldom care about security. We need to change this if we are going to deliver more secure applications.
• Governance and policy enforced automatically: Cost, compliance, security all need to be policy-based, measurable and part of the framework to ensure consistency at scale.
• Observability from day one: You cannot manage what you cannot see. Observability is a critical cornerstone of modern business operations, from technical teams to leadership.
• FinOps inside the platform: This should not be about reactive cost recovery, but proactive avoidance built into the build and run phases, avoiding the peaks of spend creep.

The point is to let developers spend their time on the business outcome, not on infrastructure plumbing. It is less about any single tool and more about an operating model, one that lines technology up behind what the business is trying to do. Done well, the infrastructure becomes something people stop thinking about, which is precisely the goal.

An Internal Developer Platform (IDP) is the construct that makes these outcomes real for developers and infrastructure teams. Typically, it brings together application templates, a service catalogue, CI/CD pipelines, a sensible abstraction over Kubernetes, policy automation, secrets management, monitoring and, increasingly, AI-assisted operations.

The experience should feel familiar to developers as they consume from the platform, much as they would consume a service from AWS: on demand, with very little friction. The difference is that an internal platform can be shaped around how your organisation actually works, rather than the lowest common denominator.

The other major benefit of an IDP is avoiding platform lock-in. Modern architectures can bridge the gap between major cloud providers and on-premises infrastructure, allowing flex to consume at the right commercial terms.

Looking towards 2027, AI is going to take on a good deal of the manual work today, generating infrastructure code, recommending architectures, diagnosing incidents, keeping an eye on costs, standing up environments on demand, and running the routine runbooks we would all rather not. As it does, people must move up the stack; the roles that matter become platform owner, service designer and governance authority. A key element of this AI evolution is that it won't make all this complexity disappear; it will help us manage it, but we need to combine it with a platform approach and a new look at what the future holds.

Platform teams need to replace infrastructure teams without leaving people behind, moving from a siloed team model to one that combines platform engineers, SREs, cloud platform architects, and platform operations to drive self-service enablement. New roles come with the change, offering opportunities for people to grow and further their skills, such as SREs, platform product managers, FinOps and AI operations. The titles are less important than the changes they drive; they build products that empower developers and automate governance that used to be manual.

We have to remember that Platform engineering is an operating model, not a piece of software, and there are a few familiar ways to get it wrong:

• Adding another layer of complexity instead of removing.
• Over-engineering Kubernetes until it becomes its own maintenance problem.
• Standing up a platform with no clear product owner.
• Treating developer experience as an afterthought
• Measuring infrastructure when you should be measuring outcomes.

The Internal Developer Platform Blueprint

Building this new future is not just a concept; it's being delivered and consumed by software developers today. That real-world experience allows the creation of a blueprint that can flex with existing tooling choices. Behind the scenes, we have a curated version of the below that includes our proven toolset. But the key concept is adaptability and how our teams help integrate this across cloud platforms.

By combining a technical blueprint with operational and cultural change, we aim to help organisations achieve four key objectives.

• Reduce cognitive load for developers.
• Eliminate process loss (waiting, rework, context switching, operational toil)
• Reduce developer interruptions
• Increase velocity.

A final core benefit we are uncovering with the change in mindset is cloud lock-in. The ability to deploy this IDP across multiple public and private cloud instances provides a consistent developer experience across platforms. For most, there is currently no desire or demand to change clouds, but with macroeconomic changes and sovereign questions, having the option to change will be critical.

Conclusion: What does the 2027 enterprise look like?

Consider your enterprise landscape a couple of years out, when it's possible that a developer asks for a service; an AI agent provisions the environment, monitors it, suggests optimisations, and resolves common incidents before anyone raises a ticket. Infrastructure fades into the background, and databases, GPUs, AI services, storage and networks are all consumed as products. The work left for people is higher up the value chain, strategy, design and governance; this is the core goal. Or it's rooted in the deep technical skills required to fix the underlying platform services, not the boring BAU ticket pushing.

A project with a global organisation that adopted the concepts of Internap Developer Platforms, DevX and Platform engineering delivered significant speed and quality advantages across its software lifecycle:

• New product onboarding has been reduced from 1 week to 1 hour.
• Tooling requests reduced from 3 months to 72 hours.
• The feature velocity significantly improved.

Fundamentally, this is all about developer velocity, allowing your organisations to innovate faster than the competition and deliver better-quality, more secure products.