There’s a massive amount interest in platform engineering as a methodology for scaling DevOps workflows but it may be a while before the concept gets widely employed.
A survey of 100 DevOps engineers, platform engineers, developers, site reliability engineers and IT managers conducted by Civo, a cloud service provider, finds 85% of respondents work for organizations that have partially or fully embraced a DevOps culture, with nearly two-thirds (65%) identifying platform engineering as the next evolution of DevOps. Nearly a third (30%) of respondents work for organizations that are already currently evaluating whether they should adopt platform engineering.
Overall, the survey found 50% of the respondents at organizations that have adopted platform engineering reported improved standardization, with 43% also seeing faster product delivery.
However, only 41% of the respondents in DevOps roles that were familiar with platform engineering said they had a moderate to high level of familiarity with the concept. One of the reasons that issue exists is, historically, DevOps adoption within many IT teams has been driven from the bottom up. Platform engineering, in contrast, is an effort to centralize the management of DevOps workflows in a way that hopefully improves developer productivity while simultaneously reducing costs by eliminating redundant tools and platforms. The issue, of course, is that many smaller teams within organizations initially embraced DevOps to escape more restrictive approaches to building and deploying applications that were previously managed by a central IT team.
Many of those DevOps teams jealously guard their prerogative to add and replace tools as they see fit. If there is a corporate standard that narrows their tool options, it’s just a matter of time before those teams start to look for ways to end run the corporate standard. Of course, the philosophical battle between advocates for centralization and proponents of decentralization has been going on since mainframes were first usurped by minicomputers and then PCs. In this latest instance, organizations need to strive to strike a balance between both extremes in a way that reduces cognitive load for developers that today spend too much time maintaining development environments than they do writing actual code.
Platform engineering teams are counting on internal developer platforms (IDPs) to strike the balance between centralized workflows and developer productivity. The goal is to enable developers to self-service their own requirements as much as possible within the context of a standard set of “golden-path” workflows. When a developer requests a new environment, the IDP using calls to application programming interfaces (APIs) sets up a namespace, updates configurations, pulls any images that might be needed and connects to eternal resources such as databases. The IDP should provide developers with enough flexibility to employ new tools when required without unnecessarily adding tools and processes that are redundant to capabilities that already exist.
As every IT leader knows, that’s a tight line to walk so they would be well-advised to embrace platform engineering in phases. The most critical asset any DevOps team has is culture. Major changes to existing workflows that developers have not bought into are likely to do more to increase friction and strife than they do to reduce them. When it comes to any kind of change management, slow and steady usually wins the race. The worst thing that can happen after embracing platform engineering is for developer productivity to decline rather than improve.
Ultimately, platform engineering teams need to be squarely focused on bringing order to often chaotic application development process in a way that results in higher quality applications being consistently built faster. If platform engineering doesn’t result in material gains in developer productivity, it’s probable the overall effort required to embrace it won’t be justified.
