Platform engineering is one of those topics that can do as much to divide as it does to unite. In theory, platform engineering defines a framework that promises to enable organizations to manage DevOps workflows. The overall goal is to streamline processes in a way that eliminates bottlenecks, encourages developers to adhere to a common set of best practices and reduces costs.
As good as that all sounds, the issue is that many teams embraced DevOps in the first place to give application development teams the level of control they needed to build software quickly. In effect, DevOps at least initially gained traction as a rebellion against inflexible centralized IT teams that historically tried to enforce standards with an iron fist at the expense of enabling application developers to experiment with new innovative tools and platforms.
The trouble with that approach is that application developers will rebel by setting up their own shadow application development environments. Platform engineering advocates are making a case for a kinder, gentler form of centralized IT that seeks to provide all the benefits of centralized IT in a way that is flexible enough for application developers to support. Many application developers today are spending as much or more time managing development environments as they are writing code. Platform engineering will enable them to focus more of their time and energy on writing business logics versus mastering all the nuances of, for example, infrastructure-as-code (IaC) tools or an instance of Kubernetes.
Ultimately, platform engineering requires a level of trust between application developers and centralized IT operations teams to be achieved and maintained, says Dan Cirulli, senior director of product management for Nutanix. “Organizations are trying to standardize both the developer and the operator experience,” he says.
In an ideal world, platform engineering represents the establishment of a social contract through which centralized IT teams will view application developers as their customer rather than just another end user they are chartered to manage within the context of a set of inflexible rules.
It’s not clear how much traction platform engineering is gaining. A recent Futurum Research survey finds a full 93% respondents claim to have adopted platform engineering as a methodology for managing DevOps workflows at scale. The issue, of course, is that when it comes to platform engineering there are varying degrees of maturity, with most organizations still in the early stages.
Some will argue that many organizations that have embraced best DevOps practices have been successfully deploying and updating software at scale for years without needing to define yet another methodology that is little more than the revenge of centralized IT ruled by autocratic CIOs. Others will argue DevOps pipelines have become far too brittle and that, as result, the time has come to fundamentally rethink the approach at a time when, thanks to the rise of AI coding tools, those pipelines are likely to be soon overwhelmed anyway.
Additionally, platform engineering could also lead to a surge in adoption of platform-as-a-service (PaaS) environments that in their latest incarnation are more customizable. Many organizations now realize they are attempting to build and maintain their own custom PaaS environment, says Ram Iyengar, chief evangelist for the Cloud Foundry Foundation (CFF), which oversees the development of an open source PaaS. As a result, many are concluding it would be simpler to deploy a PaaS that they can customize as needed, he added. “People are having a more mature conversation,” he says.
Organizations are now spending more time tailoring their platform for their environment to ensure they are optimized for specific scenarios, adds Betty Junod, chief marketing officer for Heroku, a unit of Salesforce that provides IT organizations with a PaaS that can be consumed via a software-as-a-service (SaaS) platform.
Regardless of platform engineering approach, the one thing that is clear is that while most IT teams might be headed in the same general direction, the pace at which they are moving varies widely.