Why Platform Engineering Is Not at Odds With DevOps
Platform engineering and DevOps are not at odds with each other, as some marketing strategies may argue.
Join the DZone community and get the full member experience.Join For Free
Platform engineering is the latest buzzword to gain traction in modern development practices. However, some advocates argue platform engineering spells the end of DevOps as we know it.
The chatter on social media seems like a gaudy marketing strategy attempting to throw elbows and garner attention. But unfortunately, some practitioners are pushing this narrative, too.
This conversation fundamentally misses the mark on what DevOps is and distracts from the DevOps movement. The argument is entirely misconstrued, mostly because those trying to call the time of death on DevOps … don’t actually understand DevOps.
To cut through the confusion, let’s define DevOps, and dig deeper into platform engineering and why everyone is talking about it so you can determine if platform engineering is a good approach for your organization.
What Is DevOps?
The term DevOps was originally coined as organizations looked to remove the silos between their development and operations organizations to drive increased collaboration. Today, DevOps is a movement, an inclusive culture, and a set of practices with tools that drive increased collaboration, trust, shared responsibility, transparency, autonomy, agility, and automation across the key stakeholders responsible for delivering software.
Most organizations understand that DevOps is a journey, and while each journey is different, all are guided by the principles above. Any successful DevOps transformation requires a set of objectives a business wants to achieve and identifying capabilities in people, processes, and tooling that are needed to achieve those goals.
From a human standpoint, this involves creating an inclusive culture that breaks down silos across teams and empowered individuals. The culture drives collaboration, autonomy, and shared responsibility. From a process standpoint, this involves building agile development practices that meet these objectives, including all stakeholders, enable fast and frequent changes and create fast feedback loops for continuous improvement. Organizations build out continuous integration (CI) and continuous delivery (CD) processes that increase agility by automating all of the activities to build, test, package, and deploy changes to the application. From a tooling standpoint, DevOps embraces automation to create those fast feedback loops and drives quality, agility, and velocity.
Puppet’s State of DevOps Report shows that cultural blockers make organizations (in my experience, especially large enterprises) struggle to move from mid-evolution to high-evolution in their DevOps maturity. Scaling and organizational dynamics are other challenges holding them back.
Issues with scaling come up when your DevOps practices need to support many development and product teams, each making their own decisions on tech stacks, tooling, processes, cloud service providers, and their features and capabilities. In such instances, these development teams will have to solve many of the same problems leading to inefficiencies and inhibiting institutional learning. Management and governance of these practices also become costly. Another scaling challenge comes from the complexity of modern cloud-native architectures. Not only are these architectures complex and continuously evolving, but they also rely on features and capabilities that are constantly changing. This complexity puts an increased cognitive load on the developer, a high burden to keep up, and creates increased ramp-up times for any new feature development efforts.
Organizational structure and dynamics play a big role in large enterprises in inhibiting maturity. Different teams, reporting structures, misaligned incentives, and accountability structures all become inhibitors of maturity. Cultural challenges are almost always part of the root cause for any inhibitors, but from the State of DevOps Report, high-evolution respondents did not cite cultural challenges. Instead, high-evolution respondents were correlated with the use of platform teams.
What Is Platform Engineering?
Platform engineering is a nod to the need for some standardization at scale to address these challenges. It is fair to say that this conflicts with the ideals of developer freedom, but it is not contradictory to DevOps. It may feel like the pendulum is swinging back, but we are far from the way infrastructure teams operated a decade ago.
The State of DevOps Report cites Evan Bottcher’s definition of a platform which I like:
“A digital platform is a foundation of self-service APIs, tools, services, knowledge, and support which is arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.”
When people refer to platform engineering, they are talking about building cross-functional platform teams that build and support developer platforms that simplify cloud-native development and increase development velocity. One of the fundamental differences from the infrastructure teams of old is that platform engineering teams put the developer first by focusing on the developer experience. They are composed of cross-functional members that, depending on the platform, span operations, security, development, and other stakeholders.
Gartner forecasts that by 2026, 80% of application development organizations will establish platform engineering teams. Juxtaposing this with DevOps is an apples-to-oranges comparison.
What Does the Conversation Mean for You?
Your organization may have a cloud center of excellence, DevOps teams, cloud engineering teams, or product teams that have ops (“You build it, you run it”) responsibilities. Platform engineering introduces a variation of these organizational models. The model you choose for your organization should be driven by the goals you want to achieve. Organizational models do not inherently conflict with DevOps, but some models may be more conducive to your goals than others.
If you are seeing the challenges above as inhibiting your DevOps maturity journey, platform engineering may be the right fit for you. There is data to show a combination of platform teams and value-stream-oriented product teams are common in high-performing organizations.
A highly effective platform team is cross-functional (matrixed or otherwise) and represents all of the disciplines required to deliver a self-service “product” to developers. The product mindset is important to consider the developer experience and self-service capabilities. This platform considers developer experience, productivity, security, quality, stability, and other considerations like cost management. It enables development teams to focus on customer features but provides easy-to-use building blocks to leverage the platform.
So let’s ignore the noise around DevOps being dead, and instead, let’s focus on adopting practices and structures that help our organizations mature faster in their DevOps journey.
Opinions expressed by DZone contributors are their own.