Platform Engineering: What Does ‘Good’ Look Like?
To improve the developer experience, organizations are increasingly looking to platform engineering to reduce toil and focus on revenue-generating features and innovation.
Platform engineering brings two major benefits. The first is the introduction of self-service capabilities, allowing people across an organization to experiment with new software. The second is the inclusion of automated infrastructure operations, ensuring experiments are carried out in well-managed environments.
These benefits are so significant that Gartner estimates that 80% of large software engineering organizations will have established platform engineering teams by 2026. But what’s behind the hype?
What Is Platform Engineering?
A platform engineering approach complements DevOps. The “platform” is an internal environment created as a space for developers to build and run software — such as applications, tools and workflows — in a secure, compliant environment.
The primary aim of platform engineering is to efficiently scale developer efforts while mitigating security and availability risks. Developer platforms combat the significant costs and complexity that can accrue from development at scale. These costs are most commonly the result of developers spinning up individual environments for each project — and even for individual test cases within projects. Another benefit is an increased ability to work at scale, thanks to the ability to automate operational processes that derives from working in a unified platform.
For this approach to be successful, software must be deployed within the same platform. On the surface, this may make a platform engineering approach seem like a constraint on productivity, but it can actually unleash developer creativity and significantly reduce day-to-day toil.
Build vs. Buy: How Can Organizations Implement It?
For platform engineering to be a success, the platform must be implemented the right way. With the level of customization that organizations need from their platforms, it is impossible to simply buy an off-the-shelf product. Meanwhile, there are scores of point products and open source projects available to address the myriad infrastructure, CI/CD, security and other “jobs to be done” when deploying and running software in production.
This means that organizations are instead required to do some engineering work around the products they have purchased or open source software they have adopted. But the question is: How much is the right amount to engineer yourself? Instead of driving what makes these organizations special, platform engineering can become a distraction from business goals.
The solution to this is for organizations to build the leanest possible platform. Platform engineering teams shouldn’t have to build from scratch; platforms should be built on top of other platforms. Organizations don’t want their software teams doing all the work, from plugging in the servers through to product delivery, and they certainly shouldn’t expect platform engineering teams to fully implement a platform from the ground up.
Instead, these teams need to build on the shoulders of giants. To drive this approach, organizations should buy as many Platform as a Service (PaaS) and Software as a Service (SaaS) tools as possible, and tie these together to build a finished, viable platform. There is more than enough work to do in maintaining, integrating and updating the most basic of platform experiences. This includes building the interfaces and APIs that internal engineers will use, which can mitigate vendor lock-in.
In this model, each organization’s platform is custom-built, but sits on top of existing, supported, purchasable tools. With this approach, organizations can move away from the dichotomy of build vs. buy, and focus on fine-tuning their platform to meet their organization’s needs.
What Needs to Happen for It to Become the Norm?
Many organizations have struggled in adopting DevOps because roles and responsibilities can seem overwhelming. If developers are responsible for everything in their stack, every day in production, they can become mired in toil that isn’t delivering business value. But traditional infrastructure and operations teams are often not measured for developer efficiency, so developers are left filing tickets and waiting.
For platform engineering to be successful, it requires full organizational buy-in. Silos need to be eliminated in order to build better experiences for internal users. Platform engineering requires its own team to be successful; it can’t simply be seen as an extension of IT.
Alongside operational changes, platform engineering also requires a cultural shift within development teams to prioritize nonfunctional requirements like availability and security, in addition to individual features. Platforms should help make the right thing the easy thing, but accountability is shared between a lean platform team and its users: software development teams.
As is always the case when organizations overhaul their workflows, half measures aren’t enough. Without full buy-in from every developer in an organization, as well as support from senior team members, businesses will be unable to successfully implement platform engineering.
Why Should Developers Care?
It’s easy for large software engineering organizations to have a sprawling, overcomplicated tech stack. This can make maintenance a nightmare and lead to long, slow release cycles and stressful outages. Adopting platform engineering trades complexity for a much leaner stack, removing unimportant or toilsome parts. Decision-makers must be unafraid to decommission tools or close environments they don’t need — and even automate this process once developers trust the platform they are working on. Indeed, automation can make decommissioning part of a platform’s life cycle, baking it into existing processes to save time and money.
A platform engineering approach can also bring significant time savings for developers, as well as for infrastructure and operations teams. These teams can eliminate entire categories of routine requests from developers. Platform teams automate routine, repetitive tasks, such as spinning up new environments, managing infrastructure, creating and configuring repositories, and handling CI/CD pipelines to smoothen development cycles and reduce toil.
The time and workload savings that developers can create by offloading work to a platform can provide major incentive to migrate existing applications to the platform. These benefits can also bring significant cost savings to businesses as developers are more productive, eliminating the need for additional contractors and staff augmentation services.
Platform Engineering for the Future
Ultimately, the aim of platform engineering is to encourage developers — regardless of their team or function — to use the platform and not experiment outside of it. When working within this set framework, with fully implemented toolchains and workflows, developers can focus on coding rather than having to worry about infrastructure. This significantly reduces their day-to-day workload, allowing them to thrive rather than simply survive.
