This article highlights a unique perspective on one of the latest trends in the world of IT—platform engineering. Explore what value it could bring to enterprises, and its potential impact on DevOps teams.
We are shifting, so it would seem, to platform engineering, and you, as an individual and as an enterprise, need to take this move seriously!
I don’t know when DevOps failed, exactly. I’m not certain anyone actually noticed it faltering, but enterprises have certainly found it difficult to implement because it touches on the most important of nerves (those with sensitive teeth will know what I mean) in any IT practice: culture! It requires a change not only in technology, but also in processes and skills (People, Process, Technology—PPT) and that’s proving to be quite a challenge for organizations. At the very least, it’s bewildering, especially if a company was not “born in the cloud”.
Platform engineering is a shift left of many of the DevOps practices (building tools, platforms, flows, security, and so on), but no one will admit that—you will not hear anyone call it that, but my conviction is that platform engineering is attempting to address those very things that DevOps has not been successful in delivering, through the creation of what is now being termed as the ‘platform team’, at an earlier stage of the entire cycle.
You will hear things like “platform engineering is DevOps done right”, or you may read about “the evolution of DevOps (into platform engineering)”, “the modernization of DevOps”, or even “we need to introduce standardization and consistency into development workflows”; but essentially, these and other similar thoughts and headlines are all admitting that something is wrong with the way enterprises are attempting to implement DevOps practices. So the cloud-native community needed to come up with something new/different, to rescue this whole endeavor, from the ash heap of defunct tech!
If you try to get the view of some of the “Godfathers of DevOps”, you will see that they’re not even interested in the term (DevOps) and prefer titles such as ‘Continuous Delivery’. I would settle for a set of broadly agreed terms and definitions that everyone can adopt and, more-or-less, adhere to so that enterprises can get on with the business of implementing and using these technologies. So more “continuous doing” than “continuous talking”.
Sarah Polan (Field CTO at HashiCorp) thinks not. In her blog, titled “Platform Engineering – What We’ve Got Wrong”, she states: “As usual, we’ve discovered technology is the easy part in large organizations. While FAANG [Facebook, Apple, Amazon, Netflix, and Google] may be able to purchase these mythical DevOps unicorns, the rest of the industry is left scrambling to patch crumbling architectures.” She believes—and I can attest to her view—that due to the skills gap and attrition in the IT industry, which peaked at 30% last year, some organizations struggle to scale DevOps consistently.1
What other reasons might point to DevOps failures? Scott Finnie, the former editor of Computerworld.com, was on to something when he cited “Don’t ignore the culture” in his blog, “The Top 5 Ways DevOps Fails”.2
I want to expand on Finnie’s point: Dev and Ops people possess different qualities. The former are artistic, original thinkers and problem solvers. The latter are pragmatic, strategic thinkers and risk averse. Admittedly, I’m generalizing, but I occasionally wonder if the vision of collaboration between such disparate groups is more for the idealists. Moreover, was DevOps a ‘plot’ to give developers complete control of cloud infrastructure and wrestle power from the traditional infrastructure owners? In certain quarters, developers today are expected to know all aspects of their cloud environment, even site reliability and observability!
The inconsistencies in how our industry defines platform engineering are worth mentioning. It depends on who you follow and what you read. Let’s start with the premise. The principal goals of platform engineering are to streamline and standardize the development process and reduce developers’ cognitive load.
It achieves this nirvana by curating and offering a unified ecosystem of common reusable tools and self-service capabilities. In short, it is a platform for developers to use without worrying about the underlying infrastructure.
Platform engineering is evidence that many enterprises have found it hard to make DevOps work for them. Still, I worry that it is claiming to be good for developers when it may instead force them down a route they do not want to follow. Namely, it dictates the tools of their trade to them. As for Site Reliability Engineering (SRE), I’ll leave that for a future blog post!
I’ve read much debate about how platform engineering will influence job roles. How and if we pigeonhole people depends on each organization’s size and goals. A well-rounded software development lifecycle demands a well-rounded team, with each member clear on what is expected of them and able to contribute in a way that makes them feel heard and plays to their skills. Doubtless, there will be crossovers and some blurring of the lines, but clearly, the emergence of so-called ‘platform teams’ is making its way into our dev vocabularies.
As an emerging (or perhaps, it should be ‘emergency’) technology approach, platform engineering attempts to accelerate the delivery of applications and business value.
Here are the top five aims of platform engineering (but there are others):
The chief aim of platform engineering is to establish an Internal Developer Platform or Portal (IDP), as some seem to be passionately determined to call it. IDP is a curated collection of tools, solutions, capabilities, and processes that enable developer self-service. It’s focused on standardizing a company’s internal development practices to create a “golden path” to pave the way for supported developments to production.
I stated previously that I’m not confident that developers will accept being ‘herded’ or, to be more diplomatic, ‘shepherded’ towards a corporate standard and not be allowed to experiment with their own development tools and platforms.
From my understanding, overall, platform engineering is a branch of DevOps, not a replacement (so DevOps is not dead?). Think of DevOps as the overarching framework and platform engineering delivers on certain aspects of the development process, while others, such as SRE, complete the overlap that now seems to exist to define the entire development process.
While platform engineering can certainly enhance the Software Development Lifecycle (SDLC), it’s not a panacea for all Agile development problems. The success of the SDLC workflow still largely depends on factors such as team collaboration, clear communication, and effective management.
Whatever we label platform engineering as, my concern is how it will impact enterprises already heavily invested in DevOps models and team structures.
While the sums enterprises have invested in DevOps will vary considerably, it is a multi-billion-dollar industry. So, we can safely assume that we’re talking large sums of money in many cases.
Platform engineering certainly represents another cultural shift, with ‘traditional’ DevOps teams morphing into the new approach. Developers will be required to get to grips with new platforms, tools, interfaces, and possibly even languages – all in the name of standardization. Let’s pause to take that in: we expect seasoned pros who have taken years to hone their craft to pivot to this seismic shift in their development practices.
The impact on roles and responsibilities will also be visible. Can we confidently assume that everyone is willing to accept this new form of dictation? It doesn’t demand a leap of imagination to conclude that some may not agree. Perhaps the potential friction and loss of talent is acceptable in some enterprises.
While I have outlined the perceived benefits of platform engineering above, it’s incumbent on all of us – especially the IT vendors and service providers – to support our customers during such shifts. I think we have a great deal of ‘engineering’ ahead of us!
Well, we do need to first recognize the transient nature of this entire space, the need for an overarching consensus of what all these terms mean, and a cohesive approach for enterprises to adopt. Yes, despite all the mayhem caused by the turmoil, we still need to get to grips with it all – perhaps carve our own path to what we want to achieve for our enterprise with the aid of our technology and service partners.
Platform engineering does demand more conversations. For example, will it truly reduce the cognitive overload on developers, given that many will face a steep learning curve initially? In the longer term, could it unwittingly transfer that overload to the Ops and SRE teams as they try to integrate platform engineering’s output into their workflows?
While enterprises should be able to transfer the value of DevOps into platform engineering, they will need to write off other investments that were developed for the ‘classic’ DevOps approach, such as tools, processes, and team dynamics. It will be interesting to see how their finance teams quantify all of this. So far, no one seems willing or able to answer these questions. Those who have not even embarked on DevOps yet may be glad to wait and watch from the sidelines and see where all the pieces land.
As enterprises consider their options, perhaps another shift left will spend the entire landscape. I have a more pragmatic and realistic opinion: we have enough toys to play with – we just need to stop the self-indulgence, agree on some industry standard terms, and get on with the job of helping customers adopt and migrate to a more cloud-native future.
1 Platform Engineering Article, Sarah Polan, 2024, Pulse
2 The Top 5 Ways DevOps Fails, Scot Finnie, 2018, DevOps
