DevOps and Platform Engineering: What's the difference?

We hear the terms DevOps and Platform Engineering thrown around as important practices related to modern software development and IT operations. DevOps has been around for a while, but where did Platform Engineering come from? And how do the two terms relate?

I’ll get to that—but first, a little history for context.

The DevOps origin story

DevOps grew out of Agile software development methodologies, which were formally laid out in a 2001 manifesto. However, their roots go back much further. For example, there are antecedents to Agile and DevOps in the lean manufacturing and continuous improvement methods widely adopted by the automobile industry. It’s not hard to find in DevOps echoes of principles found in the Toyota Way (which underlies the Toyota Production System) like "respect for people," "the right process will produce the right results," and "continuously solving root problems".

Appreciating this lineage also helps us understand that, while appropriate tools and platforms are important, DevOps is at least equally about culture and process.

The DevOps term was coined by Belgian consultant Patrick Debois, who had been frustrated about the walls of separation and lack of cohesion between application development practices (the dev part) and infrastructure operations practices (the ops part) while on an assignment for the Belgian government. A presentation by John Allspaw and Paul Hammond at the O’Reilly Velocity 09 conference entitled "10 Deploys a Day: Dev and Ops Cooperation at Flickr" inspired Debois to form his own conference. He called it Devopsdays (as he capitalized it at the time), and it took place in Ghent, Belgium in 2009 to discuss these types of issues. DevOpsDays expanded as a grassroots community effort, with dozens of events being held every year around the world.

Debois' specific frustrations led to a common shorthand describing a DevOps fundamental: Breaking down the walls between developer and operations teams. Today, we often see the term DevSecOps as well. While security was always implicit in the DevOps "breaking down walls" story, many felt that it needed to be given a more explicit nod given the rising profile of security as an IT priority.

DevOps extended Agile principles to encompass the entire application lifecycle, including production. Thus, operations and security skills needed to be added to the cross-functional teams that included designers, testers and developers. Improving collaboration, communication and the level of cross-functional skills is an important DevOps tenet.

Taken to an extreme, devs and ops people might no longer even exist, replaced by DevOps skill sets. More commonly, this view of DevOps focuses on "two pizza" cross-functional teams—small, multidisciplinary groups that own a service from its inception through its entire lifecycle. This works in part because such services are autonomous, have bounded context, and can be developed independent of other services and groups, so long as they honor their API contract. It also assumes that these "generalist" teams have the necessary skills to operate the underlying platform.

But DevOps couldn't be the whole story

However, as cloud computing and container platforms developed, it started to become clear that breaking down silos—and even implementing specific development best practices such as automation and pipelines—didn’t fully describe how large companies, in particular, really developed large software portfolios and managed sprawling infrastructure. The thinking shifted to more of a mindset of eliminating the need for a lot of communication rather than (solely) enabling it.

Many large organizations shifted to a mindset of providing developers with well-supported self-service experiences and then getting out of their way, rather than putting developers on pager duty.

Enter SREs

The idea is that a site reliability engineer (SRE), a term that first popped up at web-scale companies in the early 2000s, will spend about half their time on ops-related tasks like manual interventions and clearing issues. However, because the goal is to make the underlying system as automated and self-healing as possible, an SRE also spends significant time writing software that reduces the need for manual interventions or adds new features. Conceptually, this is somewhat like how a traditional system admin would write a script after they had to do the same task a few times. But the SRE concept puts that practice on steroids and shifts the ops role into one with a much larger software development component.

The SRE, as originally conceived, remains an important role. Their focus is on ensuring the reliability, scalability and performance of software systems. This involves tasks like monitoring systems, identifying and resolving problems, implementing automation and improving incident response processes. However, there's also the connection to developers that was central to the original DevOps concept.

But what about developers?

While they must also take the specific needs of different types of users into account, SREs are primarily concerned with the reliability and performance of underlying infrastructure.

But if you're looking to enable your own developers and just get out of the way, a broader but somewhat different set of concerns comes into play. Enter the Platform Engineer.

Although the distinction between SREs and Platform Engineers is somewhat loose, Platform Engineers prioritize creating a smooth and efficient development experience for developers. This involves designing, building and maintaining internal platforms and tooling that support various aspects of the software development process, such as development environments, continuous integration/continuous delivery (CI/CD) pipelines and testing frameworks. Thus, an open developer platform such as Red Hat Developer Hub might have not necessarily been associated with the original SRE concept, while it would clearly be in the Platform Engineering wheelhouse.

Platform Engineering is essentially a recognition that infrastructure for developer teams is not an end in itself. It’s not really about supporting a container platform, for example, it’s about supporting developers in a scaled-up organization. Some of this gets back to original DevOps philosophies. What do developers want from the platform? Communicating between Platform Engineering and application development teams is essential here.

It’s also a recognition that at scale, it’s often not efficient to have people devoting a lot of their time to tasks that are outside of their area of expertise. Application developers can handle infrastructure maintenance as a sideline, but if they do so, it’s going to slow down how quickly they can deliver software that directly delivers business value.

Platform Engineering team goals should include things like reducing the duplication of resources across development teams, providing tools that developers like to use, ensuring security and compliance, providing self-service and automation wherever possible and making it easier to onboard new developers.

Have we backed off on DevOps?

If we think of many of the cultural aspects of DevOps as they’ve been broadly spread in books and DevOpsDays around the world, along with widely adopted practices like continuous integration and testing, DevOps/DevSecOps is a familiar part of any smooth-running software integration.

At the same time, it’s important to acknowledge that—especially in large organizations—there are legitimate reasons for the separation of concerns. Low-friction collaboration between teams is good (and is a necessary component of Platform Engineering), but maybe removing the need for communication, where possible, is better. And providing developers with a platform that "just works" is probably one of those cases.

Learn more about Red Hat Developer Hub