Some variation of the question, “Is DevOps dead?” continues to be asked in the cloud native development space. And the answer is a definitive “no.” With the rise of platform engineering, the true question, and the clear answer, is: DevOps is changing but isn’t going anywhere anytime soon. The shifting role of DevOps will be the fuel that powers the developer experience to help everyone do more with less, which is becoming a guiding principle as companies across industries face uncertain economic headwinds.
Developer platforms have emerged as a way to pave clear paths for developers, who aim to achieve greater productivity and reduce cognitive load while safely shipping software at speed. Platform engineering as a discipline, as undefined and nebulous as it remains — although this, too, is starting to change as more packaged, commercial options crop up — has become a vehicle for easing the cloud native development journey.
While the definition of “platform engineering” is still up for interpretation, its direction is full speed ahead, focused on shaping and improving the developer experience. One of the most efficient ways to get there will be to refocus the work of existing DevOps teams to do more with less, becoming something akin to “PlatformOps” in support of the developer experience.
The Rise of Platform Engineering = The Evolution of DevOps
Two things inform the emergence, coming dominance and commercialization of the platform engineering and the developer platform.
First, developer frustration is real. The Kubernetes developer has had reason to be frustrated by some of the new challenges created by the introduction of microservices and cloud native development. A complete change of development paradigm coupled with the sudden expectation that developers should be able to “shift left” and assume end-to-end code-ship-run responsibility for their code created additional, and unwelcome, cognitive load.
Add to the mix a host of routine, repetitive tasks that suddenly fell to developers — who were, in many cases, left without any kind of roadmap or set of abstractions to figure out what tools to use. Or how to gain visibility into services to get and speed up the feedback loops they needed, all of which amounted to slowing down the shipping of products and features. One developer productivity survey from Garden found that developers spent an average of 15 hours a week on non-development tasks.
Not only was this a recipe for a bad developer experience, but it was also a drag on productivity, which affects the bottom line.
Second, while some developers relish the freedom to experiment and try new tools (the 1%), the vast majority of developers (the 99%) want, and possibly need, clear guardrails and “golden paths” for shipping and running their code. Most developers want to focus their time writing code — not running infrastructure and trying to figure out things that, for productivity’s sake, should just work, such as maintaining tooling, setting up dev environments, automating testing and so on.
By extension, most businesses need the security and stability of standardization, replicability and consistency. Being able to meet customer needs, control costs and ensure security are the priorities, and while not inherently anti-innovation, business-critical requirements discourage too much creativity and rely on processes, automation and everyone working with the same standards and tools.
This is where DevOps continues to save the day. DevOps, much like the developer’s work, is also evolving but isn’t disappearing. Instead, DevOps is moving to a platform engineering (aka PlatformOps) model of support that clears the pathway, reduces the complexity of the developer experience and removes friction from the developer’s everyday work through the creation of developer platforms.
Platform engineering builds on the best of traditional DevOps practices and uses that knowledge and experience to identify and enable new efficiencies and do more with less. Or, as a recent New Stack article articulated, “You could say platform engineering takes the spirit of agile and DevOps and extends it within the context of a cloud native world.”
Developer Platforms Enable More with Less
The drive to encourage developers to take on full life cycle management of their software started from a good place, giving them more control and insight with the power to increase velocity and build efficiency. But infrastructure has not been, and probably will never be, the primary focus for developers — or the most productive place for developers to channel their energy.
Nevertheless, in the cloud native space, there is a need for developers to understand more about the infrastructure and what happens after they ship their code. If something goes wrong, the developer still needs to be responsible for that code and know its dependencies to help troubleshoot and identify (and fix) downstream problems.
But organizing and making decisions about services, environments, clouds themselves? That’s asking a specialist in one discipline to try to specialize on the fly in some entirely different discipline, which negates both the original idea of increasing velocity and developer experience and the idea of doing more with less. Sometimes the idea of saddling a non-specialist with specialist responsibilities, thinking this shrinks the resource footprint — more with less — creates more problems.
The middle ground and the path to achieving more with less is the sweet spot for the developer platform. Essentially, developer platforms can:
- Provide developer self-service for the tools and visibility required, paving the path, but is flexible enough to accommodate different kinds of developers. It can work for new developers completing onboarding as well as for experienced developers who want to achieve reliable, efficient production.
- Enable DevOps/PlatformOps to support and enhance the self-service motion, increase their time and focus spent on strategic improvements and projects and decrease time spent fighting fires.
- Allow for better measurement of performance, compliance and security because operational and resource data is centralized within the platform.
- Ease the budgetary squeeze that is hitting many companies across multiple industries. As I shared with The New Stack, developer platforms are one way to “make sure your local development environment is set up well, and that no one is sitting around waiting for builds to happen. All this relies on rapid feedback and transparency that the platform engineering team can facilitate.”
It’s All about the Developer Experience
If developer platforms are about enabling efficiency and productivity, real-world usability is key. The stakeholders (developers) have to want to use the platform for there to be any value. Developer platforms must be created to remove barriers and sweep away typical challenges that stand between developers and shipping software safely and rapidly. The platform must address what developers need to know, see and routinely do as a part of their job, and define the abstractions required to make that happen seamlessly.
The repeated talk about “the developer experience” may sound a bit overblown, but it wouldn’t be a constant theme if it weren’t more than a passing trend.
A sentiment echoed by multiple developers, platform engineers, DevOps and site reliability engineers, but best stated by Arm’s Cheryl Hung, highlights why a developer platform is essential: “Infrastructure can be unreliable; it fails; it is unpredictable. Compared to software that runs pretty much the same way every time, infrastructure is really, really hard.”
If the developer experience — and enabling the developer’s work — is crucial to achieving business goals and using resources wisely, the DevOps/PlatformOps role and platforming engineering are equally instrumental in continuously improving and safeguarding the developer experience.
Group Created with Sketch.