The evolution of platform engineering

SECTION 1

2018 in retrospect: when DevOps became an engineering discipline

To understand the scale of the shift from DevOps to platform engineering, it helps to look back at 2018, a time that, while not so distant, feels like it belongs to a different era of technology.

Outside software, 2018 was marked by major shifts: the launch of 5G, GDPR taking effect in Europe, leadership drama at Tesla, the rise and fall of star cryptocurrencies, and Microsoft's acquisition of GitHub. For many, 2018 was also the year metal 3D printing became a reality and virtual reality started entering the mainstream.

Within the software world, though, a quieter revolution was underway. DevOps, once more of a cultural idea than a discipline, was starting to crystallize into a codified engineering practice. Shaped by the publication of The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford, and by books like Continuous Delivery by Jez Humble and Dave Farley, DevOps moved from disruptive techniques to a foundational layer of modern software delivery.

What changed? The industry moved past theory. Organizations got serious about flattening silos, visualizing value streams, and identifying friction points in their delivery pipelines. These weren't just conference ideas, they made a massive difference for teams on the ground, often within months rather than years.

SECTION 2

Automation as a rite of passage: the case of an aerospace program

### The weight of a manual, paper-driven process

In 2018, I worked for a major U.S. defense contractor, responsible for the software platform supporting several types of drones, each with its own quirks and complexity. The deployment process was extremely manual and paper-driven: teams flipped through binders full of installation manuals, SSH'd into terminals, installed packages by hand, and hoped the network connections to update servers wouldn't fail along the way.

The contractual goal was to return a grounded drone to service within 14 days or less. In reality, it often took 30, 50, even 60 days before everything was finished and the aircraft could fly again. That was the exact opposite of agility, and every day of downtime carried a direct operational cost.

### The shift to CI/CD automation

As DevOps thinking began to take hold, we asked a simple question: what if we automated code builds, tests, and deployment with CI/CD pipelines and configuration tools like Ansible and Puppet?

It wasn't a smooth ride. We had to work with unusual languages, open-source tools chosen to save on licensing costs, and sometimes plain organizational inertia. But the results spoke for themselves: over a year and a half, turnaround time dropped from several weeks to under 24 hours, a major shift in the organization's operational capability.

### Pipeline sprawl: the new problem

That wave of automation, however, brought its own set of problems: uncontrolled pipeline sprawl. We ended up with more than 900 self-hosted Jenkins runners, each one a unique snowflake, configured and maintained by hand. The next challenge was no longer automating, it was consolidating: giving developers power and autonomy without losing control or drowning in operational complexity.

SECTION 3

The birth of platform engineering: four founding principles

That's when the seeds of platform engineering were sown, at Adservio and across the industry. Inspired by conversations with figures like Martin Fowler and by our own thinking on the ground, we started exploring what sets a good platform apart from a simple stack of internal tools.

### An internal product, not a pile of tools

The first principle is the most counterintuitive one for infrastructure teams used to thinking in projects: the platform itself must be genuinely useful and appealing to its internal users, the same way a product is to external customers. That means a roadmap, user research, and a measure of satisfaction, not just a catalog of technical services.

### Autonomous delivery teams and reduced coordination

Developers must be able to build and deploy with minimal handoffs, a move away from the "ticket ops" culture toward genuine self-service. The direct corollary: the platform should reduce friction and cross-team coordination overhead, never increase it. A platform that multiplies approval committees isn't one, it's a bottleneck in disguise.

### Driving by outcomes, not outputs

The fourth principle shifts the focus from what the platform delivers to how it accelerates business outcomes. In other words, platform engineering isn't about setting up shiny internal portals or collecting tools for the sake of it. It's about giving delivery teams real leverage, so they can move faster, safer, and with more autonomy.

@cite:platform-engineering-devops-cloud-hybride

SECTION 4

Four shifts that reshaped the discipline since 2018

### Self-service finally became instant

Remember when the front door to IT was a ticket queue? Need a GitHub repo, some infrastructure, or a test environment? File a Jira or ServiceNow ticket and wait. Today, the norm is genuine self-service, developers discover, request, and provision the resources they need instantly, through well-designed APIs and interfaces. An important nuance: this self-service model covers onboarding, infrastructure provisioning, and basic service requests; incidents are still better handled through ITSM tools.

### Product thinking took center stage, backed by SLOs and SLAs

For too long, platform initiatives were run project by project: build a new Java starter, add pipeline templates, create a Terraform library, and hope developers would piece it all together themselves. The most mature organizations now organize their platforms around "jobs to be done," delivering capabilities that come together as a coherent product offering: "here's everything you need to deploy a Java application to production, tested, observed, and compliant." These capabilities come with explicit Service Level Objectives (SLOs) and Service Level Agreements (SLAs), developers know exactly what they're getting and when, just like with any customer-facing product.

@cite:ameliorez-votre-experience-developpeur

### Operating models became business-driven, not dogma-driven

Initially, many organizations let platform teams run operating models in isolation, often over-standardizing and dictating approaches top-down. More mature organizations have flipped that model: business goals now drive platform design, not the other way around. Is the business a conglomerate of units that need coordination, like a retailer with supply chain, point-of-sale, and customer experience teams? Or a simple, focused operation, like an airline? How much standardization, autonomy, and integration the platform provides should flow from that business context, not from abstract architectural ideals. Harmonization doesn't mean lock-in: it means providing the foundation and guardrails so product teams can move fast, with confidence.

### The rise of "developer success" teams

As platforms increasingly look like internal SaaS products, many organizations are standing up "developer success" teams. Like a vendor's customer success organization, these teams actively engage with internal developers: they smooth onboarding, gather feedback, and make sure platform capabilities continue to meet evolving needs. A SaaS vendor wants the loyalty of its enterprise customers; a successful platform team wants the loyalty of its engineers, a shift that's as much cultural as technical.

SECTION 5

Mergers, legacy, and sprawl: the challenge of consolidating at scale

### Why rip-and-replace almost always fails

No discussion of platform engineering is complete without confronting the reality of legacy systems, mergers, and acquisitions. Most companies, even fast-growing startups, face the same challenge: after a merger or acquisition, two platforms, or more, each cherished by their own teams, need to coexist. A "rip and replace" approach is rarely wise, and often simply unfeasible within the available timeline. It's fine to run several platforms in parallel while carefully migrating teams and capabilities, as long as the process stays intentional and progresses steadily. Platform consolidation journeys often take years: the key is not to rush, to measure twice before cutting once, and to keep the focus on delivering value throughout.

### Case study: sandboxes as a gateway to platform maturity

Here's a concrete example from clients in the airline sector: product teams often complain that platform teams are slow to adopt new tools or frameworks. Sometimes, impatient teams stand up their own "shadow IT," building mini-platforms outside the collective standard. Rather than resist head-on, the most mature platform organizations create safe sandboxes for experimentation. If a team wants to adopt Gradle instead of Ant for its builds, for example, the platform team offers support, evaluates the results, and, if it works, extracts and hardens the new capability for broader use. This collaborative model lets innovation bubble up from the ground, shortens implementation timelines, sometimes by months, and keeps everyone moving in the same direction.

SECTION 6

A technology landscape that exploded: and the next AI frontier

### The CNCF, from 40 to over 250 projects

The available technology arsenal has exploded. In 2018, the Cloud Native Computing Foundation (CNCF) hosted around 40 projects. Today, that number is well past 250, creating opportunities and headaches in equal measure. Savvy platform teams carefully curate their stack based on real needs, not hype, and resist the urge to adopt every new technology just because it's new.

### AI-infused platforms

In 2026, the big theme shaping platform teams' roadmaps is embedding AI into the platform experience itself. How developers interact with Internal Developer Platforms (IDPs) is changing: from CLI commands and tickets to conversational interfaces, visual workflow designers, and agents that provision, diagnose, and remediate under guarded autonomy, with human oversight on higher-risk actions. The challenge, and the opportunity, is to make the platform's experience layer radically more accessible and adaptive, so that capability is within reach of everyone, not just the most technical profiles.

@cite:platform-engineering-idp-agents-ia

SECTION 7

Conclusion: lessons from seven years of evolution

Platform engineering has gone from a grassroots pushback against ticket-driven ops to a sophisticated discipline centered on product management, developer experience, and business alignment.

A few key lessons stand out from this journey. Automation is only the starting point: real transformation happens when you treat the platform as an internal product, obsess over developer outcomes, and build trust across teams. Self-service, standardization, and experimentation aren't opposing forces: they're all critical to scaling delivery across the enterprise. The operating model must be driven by what the business is trying to accomplish, not by architectural dogma. Continuous feedback loops, through structures like developer success teams and experimentation sandboxes, keep the platform relevant and drive adoption.

Finally, the ground keeps shifting. From ticket queues to AI-guided interfaces, the goal remains the same: help teams build and deliver value faster, more safely, and with confidence. The fundamental lesson is simple: platform engineering is never "finished." It's a living, ever-evolving ecosystem. The more we embrace change, listen closely to our users, and stay relentlessly focused on outcomes, the more durable our platforms, and our organizations, become.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect Adservio's positions.

FAQ

Frequently asked questions