Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Is Platform Engineering the Future of DevOps or Just a Passing Trend?
Should your organization jump on the platform engineering bandwagon? Here are the pros and cons of platform engineering.
5 Min Read
Alamy
In case you missed it, platform engineering is the latest, greatest trend in the world of DevOps. Many folks say that if you want to take DevOps to the next level, you need platform engineering. The practice is "key to unlocking DevOps at scale," as Ronan Keenan of Perforce told IT Pro Today.
On the other hand, reasonable people can debate whether platform engineering really has the bright future that its most vocal advocates predict. You wouldn't be crazy for taking the position that platform engineering will turn out to be a passing fad, and that it won't exert a long-term impact on DevOps.
Let's take a look at what the future of platform engineering might entail — and whether every organization that wants to stay up-to-date should be jumping on the platform engineering bandwagon.
What Is Platform Engineering?
Put simply, platform engineering is the practice of giving developers inside an organization easy access to the tools and services they need to be productive. Typically, those tools and services are made available via an Internal Developer Platform, or IDP, which is more or less like a marketplace that a company's engineers can use to roll out ready-made solutions on a self-service basis.
The main goal of platform engineering is to ensure that developers can quickly access the technical resources they need to do their jobs. Rather than having to set up infrastructure, provision environments, deploy software development tools, and so on from scratch, platform engineering makes preconfigured solutions available on demand.
An additional benefit of platform engineering is that it helps bring consistency to internal development tools. When developers can obtain what they need via a central catalog, all development teams within the organization will (in theory, at least) use the same solutions, configured in the same basic ways. That's better than having each team or individual developer set up bespoke environments and services, which are harder to monitor and maintain.
Will Platform Engineering Transform DevOps?
Most people see platform engineering as an extension of DevOps, not an alternative to it. They argue that platform engineering helps DevOps teams achieve greater levels of productivity by introducing new efficiencies to the setup and provisioning processes that DevOps teams rely on to write and deploy software.
In that sense, platform engineering does indeed stand to create a lot of value. Arguably, DevOps has plateaued at many companies because DevOps tools and practices — which were introduced in the late 2000s and gained widespread adoption starting in the mid-2010s — are now fully mature within a majority of organizations. There's not much room for improvement or ability to create additional value through standard DevOps.
By rounding out the rough edges of DevOps provisioning and deployment processes, however, platform engineering does create ways to drive new value in the realm of DevOps.
Could Platform Engineering Fizzle Out in the Future?
That said, I tend to think that platform engineering's potential to transform DevOps in a radical way is limited. Platform engineering will likely be part of many DevOps organizations' futures, but I am doubtful that it will end up becoming a must-have practice at virtually every organization.
There are several reasons why platform engineering might not prove highly valuable over the long term for most organizations:
Small companies may not need platform engineering: Platform engineering and IDPs are great at very large organizations that would otherwise struggle to maintain consistency across internal development solutions. It creates less value at startups and smaller businesses, where it's easier to maintain consistent sets of solutions in an informal way, without building an IDP.
Large companies may not do platform engineering effectively: Although large companies stand to gain more from platform engineering, it's harder for them to do platform engineering well. The more engineers you have, the more difficult it is to figure out what all of them need and want from an IDP. I expect some organizations will invest lots of time in building IDPs, only to discover that the solutions they implement aren't in alignment with what their engineers actually need.
Platform engineering can't deliver every solution developers need: You can't anticipate, build, and preconfigure every possible technical service or tool that developers might require ahead of time. Even with a robust IDP in place, your development teams are likely to have to acquire some solutions from other sources. As a result, platform engineering's ability to streamline and automate all aspects of provisioning is limited. Some aspects of developer self-service will always be manual.
Platform engineering doesn't benefit all teams equally: Some development teams are constantly deploying new environments, CI/CD pipelines, and so on. But I'd wager that the majority of teams require new services and tools only occasionally because their workflows don't change often. The latter group stands to gain less from platform engineering because they are not constantly having to deploy new solutions. Once they have environments and pipelines in place, they are likely to keep using them for years.
In short, platform engineering certainly holds great potential for supercharging the workflows of some development and DevOps teams at some organizations. But to predict that platform engineering will become an essential ingredient in DevOps success for every business seems far-fetched. I don't think platform engineering will be a fad, but I also don't think it will end up having as great an impact on software engineering practices as DevOps did.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
