Guest post originally published on the Ozone blog by Abhilash
“Gartner expects that by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components, and tools for application delivery.”1
Gartner Insights.
Platform Engineering” has seen a rapid increase in interest since October last year, with some claiming that it has taken over DevOps. The majority, however, are still unsure of what it means since Gartner continues to say, “Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.”1 But wasn’t that the sole purpose of DevOps when it made its debut almost a decade back? Heck, teams still need to work on implementing and realizing the full potential of DevOps!
Through this blog, we hope to highlight the similarities and differences between DevOps and platform engineering and shed some light on what the hype is all about. Because ultimately, the real-world requirements are more or less the same: improved Developer experience, delivering with minimal overheads, staying in control with governance and security, with an improved developer and business efficiency as the goal. Whether you subscribe to “Modern DevOps Platforms,” “Value Stream Delivery Platforms (VSDPs),” “CI/CD Automation Solutions,” or simply look in-house to build an internal developer platform, the terminology doesn’t matter. Almost every solution that has been mentioned here delivers what Platform Engineering is predicted to deliver. What, then, is Platform Engineering and its relation with DevOps?
Let’s take a step back and look at DevOps. A few teams have been extremely successful in implementing it, and many are continuously experimenting with toolchains and workflows to see what best fits their needs. However, there have been growing issues as well. The “You build it, you run it” approach sounded appealing initially, but, in reality, the most experienced members of a development team often find themselves dealing with operations that dilute their contributions towards actual development. Efforts have been made to address challenges like these and many more through the abstraction of complexities and automation. Since the last couple of years, the open source communities and tools have grown in numbers and capabilities, leading DevOps to become mature and easy to adopt.
Many approaches help make DevOps accessible to all: through standardization of workflows and pipelines, introducing ML-driven automation, using GUI-based platforms for cutting short the learning curve, and the latest of them all: using the platform engineering approach to build an Internal Developer Platform. “Is Platform Engineering really going to kill DevOps? Or is it just one of the many ways for teams to streamline their DevOps? We feel it’s, without a doubt, the latter! DevOps is an overarching concept. Platform Engineering is one of the many efficient means to adopt and realize the concept of DevOps efficiently. But it definitely is not the only means!”
Case in point: The core focus of our Ozone: The Nex-Gen Software Delivery Platform has always been on improving operational efficiency through standardization and elevating developer experience with a low-code UI. It abstracts away manual tool orchestrations and workflow complexities, something that even Platform Engineering aims at achieving through internal developer platforms (IDPs). But before diverging to a comparison, let’s first have a look at what exactly is platform engineering and internal developer platforms.
What is Platform Engineering?
Platform Engineering is a solution to make software delivery lightning-fast and keep businesses competitive. It is the practice of building and operating internal developer platforms for software delivery and life cycle management, focusing on making them self-service for developers. These IDPs act as a centrally managed technology platform that automates infrastructure management and lifts the burden of managing complicated toolchains through abstraction and reusability, reducing developers’ cognitive load and improving their experience.
The following are three aspects that platform engineering aims to tackle:
- Empower developers with self-service
- Automating manual tasks to improve productivity
- Improve developer experience
How can this be done? With these four main approaches, platform engineers will have to follow:
- Building/Managing Internal Developer Platforms
- Introducing reusability across key delivery processes
- Customizing/modifying workflows based on developer feedback
- Defining and monitoring KPIs across teams
As you can see, the internal developer platform is a major means through which platform engineers can onboard their developers leverage it as a major support system for streamlining development and automating operations. This creates a favorable environment for developers to follow the “You build it, you run it” philosophy without getting sucked into manual operational tasks.
The next question is, what exactly are these internal developer platforms? Do your requirements demand you to build them internally from scratch by dedicating half of your DevOps resources? Or is it best to subscribe to something that is much more capable? Well, you would be better placed to answer that question once you know what exactly an IDP is.
What is an Internal Developer Platform?
An internal developer platform is a self-service solution that managers and leads can use to track and organize the stuff that DevOps teams build and operate, along with the toolchains that are used during the process.
The primary aim of an IDP is to unify and improve visibility across teams, infrastructures, and tools, which would help in information discovery and generating insights from one place.
Having an internal developer platform gives a competitive edge to businesses as it helps to:
- Get an overall understanding of projects, documentation, cost, performance, infrastructure stats, and much more, all from a single pane of glass.
- Identify and tackle security vulnerabilities.
- Automate and streamline working with cloud integrations and infrastructure operations.
- Improve collaboration across teams and projects within an enterprise facilitating faster outputs and implementation of feedback.
- Deploy confidently as the team is much better informed of dependencies and armed with resources to tackle failed deployments and rollbacks.
- Measure an organization’s direction of progress and take corrective action.
The advantages of having an IDP are far more than what can be documented, as it actually depends on the nature, culture, and dynamics of the market where an enterprise is operating. But one question that can be asked, which is common to all industries having a DevOps team, is this: Now that you know what an IDP is, how do you plan on having one? As highlighted in the previous section, there are two ways to go about it:
- Build your own Internal Developer Platform: This approach gives you the ultimate flexibility and lets you develop a platform as per your specific needs. However, it would have to be developed with a product mindset keeping the user needs in mind; in this case, users = your developers. The best way ahead would be to identify key SREs and Ops resources to build your platform engineering team. This platform team will then have to proceed with a product development mindset and have a clear view of the objective of the platform: to allow developers to configure, deploy, and roll back with confidence through automation.
However, it would be counterproductive to do this if your budget runs too thin or you cannot afford to shift your resources into building the platform, which looks like an overkill.
- Subscribe to existing solutions: As iterated before in this blog, there are multiple solutions available in the market today that are aimed at streamlining DevOps. You may call them “Modern DevOps Platforms,” “Value Stream Delivery Platforms (VSDPs),” “CI/CD Automation Solutions,” and whatnot. Terminologies aside, most of these platforms offer the same features and even more when compared to what you would get if you built an IDP on your own. And that’s because these platforms are built ground-up by teams who know their stuff. Almost every solution available out there offers a user-friendly UI, a capable integration stack, custom workflows, dashboards, RBAC, and more. So why reinvent the wheel when you already have solutions to cater to your requirements? Chances are high that they offer so much more than having your own internal developer platform.
If the solutions were always there, why then is Platform Engineering in focus? How different is it from DevOps?
Is Platform Engineering at odds with DevOps?
The idea of having an internal developer platform has always been on the radar of many DevOps teams with the objective of streamlining CI/CD and creating scope for end-to-end security and governance. It’s no longer a good to have but an absolute necessity, given the increase in complexity of microservices and hybrid deployments.
Companies have been either innovating in-house or exploring DevOps platforms that can make developers’ lives easier, unify disparate tools and processes, and help set up governance frameworks that can help accelerate an enterprise’s DevOps maturity.
The concept of Platform Engineering is to build and manage an internal developer platform with the help of a team of platform engineers, primarily made up of SREs and Ops professionals. Again, the aim here is to provide developers with a feeling of inclusion while working with infrastructures and deployments without taking away time from their core responsibilities.
As can be plainly seen, this is just one of the ways a team can streamline their DevOps. But DevOps is an overarching concept. Something that keeps evolving over time and will have many methodologies similar to platform engineering to streamline it. Thus, Platform Engineering is merely one of those methodologies that aim to streamline DevOps but will never completely replace it.
References:
- ^What Is Platform Engineering? by Gartner