Platform engineering has emerged as a term that at its core describes a shift toward more centralization of DevOps processes and workflows. The adoption of DevOps workflows in most organizations has tended to flow from the bottom up. As a result, it’s fairly common for multiple application development teams within an organization to have adopted multiple DevOps platforms to manage workflows. Advocates for platform engineering are making a case for eliminating many of those redundant platforms in favor of, for example, a single continuous integration/continuous delivery (CI/CD) platform that serves as a corporate standard.
At the core of any approach to platform engineering is the assumption that centralization will reduce costs by eliminating redundancy. At a time when more organizations are more sensitive to the cost of IT there is always going to be a natural tendency toward rationalization of platforms. Trouble, however, inevitably arises when centralization results in loss of flexibility. Many of the teams adopt best DevOps want to be able 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.
The philosophical battle between advocates for centralization and proponents of decentralization has been going on since mainframes were first usurped by minicomputers and the subsequent rise of PCs and workstations. In this latest instance, organizations need to strive to strike a balance between both extremes. If each development team has its own DevOps platform the overall process for building and deploying applications can easily become chaotic. Platform engineering teams attempt to bring order to a process in a way that should ultimately enable higher quality applications to consistently be built faster.
A recent survey of 438 IT practitioners sponsored by Puppet finds more than half of respondents (51%) have already adopted platform engineering in the last three years, with 93% describing it as a step in the right direction. Top benefits cited include system reliability (60%), improved efficiency (59%), faster delivery times (58%) and improving workflow and process standards (57%). More than half of respondents (51%) that have adopted platform engineering said development speed has somewhat increased since the inception of the platform team, and 42% say it’s increased by “a great deal.”
Developers, however, don’t tend to appreciate too much structure. In fact, the best and brightest developers often shy away from it. That’s why there are so many developers that prefer to work for smaller companies or even themselves versus working in a larger enterprise that tends to view software development as the rough equivalent of a digital factory. If organizations want to attract the best and brightest developer talent, they need to create a work environment that is inviting. Centralization taken to an extreme will result in large numbers of developers heading toward the exit sign.
None of these means that platform engineering is a bad idea, but care needs to be taken when it comes to applying it. Fiefdoms can easily arise that are then jealously guarded. No matter how benevolent developers will eventually rebel against any regime they view as authoritarian. A successful platform engineering team keeps in mind the needs of the developers they serve rather than just the wishes of a CIO or CTO that is far removed from the software development lifecycle.
Ultimately, platform engineering doesn’t replace DevOps as much as it does define a more structured approach to managing workflows. That kind of adult supervision in many organizations is long overdue. The issue is the degree of supervision that needs to be applied will vary widely from one organization to another because, as always, there’s no such thing as a one size fits all approach to neither DevOps in general nor, more specifically, platform engineering.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
