5 more myths about platform engineering: how it’s built, what it does, and what it doesn’t

In an earlier post, we discussed some persistent myths about platform engineering — what it is, what it isn’t, and ways in which you’re already performing core platform engineering tasks. Here, we will cover five more myths, this time about how platforms are built, what they do, and what they don't. 

6. MYTH: Platform engineering eliminates the need for infrastructure teams

Even if you have the best developer platform on the planet, it still runs on top of complex infrastructure, which will always require ongoing maintenance by specialists who understand it. After all, someone needs to architect, manage, scale, troubleshoot, and optimize that infrastructure. And try as you might, that infrastructure will continue to fail just as it did before you introduced platform engineering. A common mistake is to eliminate the infrastructure team and to expect a totally new team to make up for that loss. Infrastructure teams already have the expertise to handle these responsibilities, and as such,  are good candidates to become platform engineers. By using the team with institutional knowledge of the underlying infrastructure, you're more likely to adapt your current system into a viable, engineered platform.

However, what platform engineering does change is how infrastructure specialists prepare for and respond to failures, as the platform engineering role is more focused on platform development, and less on manual, repetitive tasks. So while platform engineering changes the nature of infrastructure work, it doesn’t eliminate it altogether. You still need to build a self-service catalog of golden paths that developers can select to deploy their applications. That catalog needs to be documented and refined, advocated for within the organization, and introduced to new engineers. Improvements to the platform also need to be rolled out to existing tenants. Scale and security are always a source of new issues. Infrastructure experts are extremely valuable members of any IT staff; allowing them to codify their knowledge into a platform is essential to an organization looking to succeed at software delivery.

Finally, even the most mature platforms have components that fall outside the scope of automation, and infrastructure experts will still be responsible for them. And that’s OK, because they understand this work firsthand, so are better able to prioritize which features to add to the platform engineering product backlog. New systems come online and evolve, cloud providers expand their offerings, but the platform is never done.

7. MYTH: Introducing platform engineering will dramatically impact staffing costs

Part of building a platform engineering team is taking the people with the most DevOps skills within an organization and evolving into the new structure. This allows them and the organization to better apply DevOps principles with fewer people, using  self-service automation and golden paths.

A common concern is that a platform engineering team will require a lot of additional personnel. A platform engineering team indeed needs to be staffed, but that staff can come from existing operations and software engineering teams. Over time, the resulting platform should more than pay for itself by leveraging gains from shared services. In other words, the platform engineering team is an investment that you can fund from existing in-house teams. One model to consider is Google SRE's history of sublinear scaling, where the teams responsible for ensuring availability set objectives to grow their headcount at a lower growth rate than the system they run.

When introducing platform engineering, an antipattern would be to expect a reduction of operations staff or developers out of the gate. Retraining existing teams works well because they're already familiar with your business needs, and have a lot of experience with the underlying infrastructure, whether it’s exposed directly or via a platform. In fact, we observe that teams that adopt platform engineering end up finding that more work can be done by the same individuals because there’s a platform that they can leverage.

When implemented correctly, platform engineering increases efficiency and reduces operational overhead:

• Automating deployment pipelines, infrastructure, and configuration reduces manual work.

• The self-service model reduces bottlenecks, as there’s minimal intervention required from operations teams

• Workflows become streamlined, allowing teams to do more with the same (or potentially even fewer) resources.

And while you may need to do some initial upskilling or hiring, over time, the transition to platform engineering unlocks long-term efficiency by applying platform expertise across the organization.

8. MYTH: Adopting platform engineering today will quickly solve all my biggest problems

In any complex environment, hoping for a quick-fix is almost always wishful thinking. Change takes time, and the timeline for that change needs to account for identifying your organization's constraints and how quickly it can curate relevant solutions.

Nor is there a one-size-fits-all approach to platform engineering; it needs to be tailored to meet the specific needs of your organization. However, you *can* achieve faster results by building out a minimal viable platform (MVP), starting from a subset of your user base and creating a fast feedback loop.

Starting with some pre-made MVPs can help to bootstrap a team, but it is important to not make the mistake and think that you can "buy your way out of this" by adopting a fully-built platform, and presto! Improving immediately. Investment, research, and introspection are the right path forward here. By starting with an MVP and adding capabilities based on early adopters’ feedback, you can iteratively build a platform that starts delivering value quickly.  Don't try to design the perfect platform with a five year plan.

In short, platform engineering is a journey that requires a change in mindset across development and operations, a cultural shift to embrace the platform, golden path engineering, and tooling to address friction in the development process. All of which takes time to get it right.

9. MYTH: You should apply platform engineering practices to every application

Platform engineers actively analyze and identify tasks or processes which create a high cognitive load on development and operations teams, taking targeted actions to alleviate the burden. That does not describe all tasks and processes within a software delivery organization.

As such, consider applying platform engineering to applications where developers are overwhelmed by infrastructure complexities, or the operations team faces constant friction. In these situations, a "golden path" approach can streamline development and management. This typically involves selecting suitable cloud services, automating deployments, and establishing standardized configurations.

First, focus on abstracting things that have the highest usage and toil, i.e., services that both take a high cognitive load and are frequently used. Prioritizing these systems allows the benefits of the platform to be realized sooner.

Make sure your abstractions provide value, sensible defaults, along with guidance and explanations for why you made certain choices. Having "break-glass" methods for stepping outside the platform if needed is highly encouraged. At least initially, think in terms of building a platform for depth rather than breadth.  Satisfy and automate common use-cases as completely as you can before moving on to new ones.

Similarly, don't start with the biggest, most important service to your organization. An antipattern is to adopt the "biggest bang" application first, to maximize gain over time.  This is likely to fail, as teams haven’t had the time to develop confidence in your nascent platform, or the platform doesn’t yet have the requisite capabilities. Instead, start with smaller, less-demanding services.

A team doesn’t need to deploy every service when adopting the platform. You can aim to adopt some large percentage of them, but there will always be "strays" that might require a separate approach. As long as the discussion happens and is documented for future re-evaluation, don't worry too much about that.

10. MYTH: All cloud services map to platform engineering

When people begin their platform engineering journey, they often ask us "does this cloud service map to platform engineering?” Don’t mistake adopting a cloud service for practicing platform engineering. This misunderstanding hinders effective implementation, and suggests that there’s an unclear understanding of what platform engineering actually is.While you can use any cloud service with platform engineering, what matters is how you integrate that cloud service into your developer experience through the platform.

Let’s briefly revisit core platform engineering practices and processes, so that you can decide for yourself whether a cloud service or product is a fit for your platform.

Your next steps with platform engineering

Over the course of this blog, you’ve learned that platform engineering is a new approach to managing IT infrastructure and software development. It aims to streamline the software development process by providing developers with self-service tools and platforms, abstracting away complex infrastructure details, and automating repetitive tasks. While it builds on existing practices like DevOps and automation, it is worth considering this on its own to ensure the most benefit for teams.

Key takeaways:

• Platform Engineering is a natural evolution of DevOps, aiming to address the challenges of modern software development at scale.

• It's not a one-size-fits-all solution and requires a tailored approach to meet your organization's specific needs.

• Start small with a minimal viable platform, prioritize high-value tasks, and iterate based on feedback to build a platform that truly delivers value to your developers and organization.

Keep reading about golden paths and laying the foundation for a career in platform engineering. Also check out recorded talks from PlatformCon. Last but not least, be sure to contribute to the annual DORA survey!