The parable of the blind men and the elephant provides us with a way to understand why people can disagree on a new topic: by looking at it from only their own perspective, they miss out on the greater whole. Platform engineering is a relatively new approach to software delivery that is being examined by IT organizations and software engineering teams — with a lot of disagreement between them about what it is, what it does, and why you should or should not adopt it.
We believe that it’s important to think about software delivery holistically, which is why we like platform engineering. When individual teams only consider a part of the problem, they end up with fractured or problematic systems. Only by thinking of a software delivery platform as an engineered product do you “see the whole elephant.”
Here we present five common myths about platform engineering — what it is and what it isn’t — that we’ve heard when folks aren’t considering the whole picture. In part two of this blog post, we’ll tackle myths about how platforms are built, and what they should and shouldn’t do.
1. MYTH: A developer portal and an internal developer platform are the same thing
You probably already have a developer portal, and as such, may think that you’re already doing platform engineering. But a developer portal is actually the interface to the rest of the internal developer platform (sometimes called an “IDP”). It’s just the front door — it doesn’t solve the whole problem. And despite sounding very similar, an internal developer platform and a developer portal have several key differences. Let’s dive into the differences between the two.
A developer portal is an interface that helps software developers find and use the various services and tools that the IDP provides. A developer portal typically provides:
-
Execution of self-service templates to deploy and configure infrastructure and applications (otherwise known as a golden path)
-
A service catalog to track deployed resources and metadata (such as owner and environment)
-
Visual representation of the application service status (like SLOs, DORA metrics).
-
Documentation on the platform, application, API’s or even the code itself
An internal developer platform, on the other hand, enables developer self-service through the use of golden paths. The platform abstracts away technical complexities with approaches such as codified practices, setting company-wide configuration, and applying security controls. Each new service deployed from the IDP, e.g., Google Kubernetes Engine (GKE), Cloud Run, Compute Engine, or Cloud Workstations, is made immediately available on-demand without waiting for any tickets, manual approvals, or meetings.
A quick starting point for an internal developer platform might be to use an existing Google Cloud product like Cloud Run, which provides a UI for creating, deploying, and observing workloads, as well as an API for automation or command line access via gcloud. And while many Google Cloud products can be thought of as platforms, they’re often not sufficient on their own. To enforce constraints or encourage certain developer behaviors, organizations might want to limit their flexibility or combine usage of multiple products into a single interface, simplifying their developer experience.
Internal developer platforms should also provide appropriate limits. This might be done through setting “sensible defaults” and providing golden paths, or even by restricting the choice of resources and services to those that satisfy organizational policy. Disallowed resources or settings are not provided through the portal, or are otherwise marked as disallowed, possibly with an explanation or method to “break the glass” to violate such restrictions.
An example IDP and its dependencies
In this world, developers mostly interact with the developer portal UI, hiding the developer platform beneath it.
2. MYTH: We don’t need an internal developer platform
It depends! You really might need one – in fact you probably already have one. Whatever your current method to get your code to production is your platform. That might be a mess of different processes, systems, and people — it might change every time! For example, if you have a set of tickets to file to different siloed teams, we say you have “paperwork as a platform.” Or if you have to speak to a specific individual to launch something, you have “people as a platform” (if you’ve read The Phoenix Project, think of Brent).
Platform engineering starts with modeling the process (or an improved version of it) that you have today and building software to do it for you, instead of requiring every team to become experts in DevOps practices. That can start with simple CI/CD pipelines, and it can be improved with consistent observability or managed infrastructure services. By bringing these components together, a platform emerges. Presenting abstractions to developer teams to better knit these components together into a consistent, usable developer experience is the role of a platform engineering team, and the internal developer platform is the means by which this is achieved.
3. MYTH: Platform engineering is “just advanced DevOps”
On this we can all agree: DevOps is an organizational and cultural movement that aims to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders, where DevOps practices include
-
version control
-
continuous integration
-
trunk-based development
-
continuous testing
-
continuous delivery
-
architecture
-
cloud infrastructure
-
test management
But the DevOps model can face scalability challenges due to an overwhelming management of infrastructure. This may lead to cognitive overload, developer burnout, inconsistencies between teams, or cultural resistance.
Platform engineering is happening today as a natural evolution to ‘DevOps at scale.’ DevOps practices used within platform engineering include:
-
Taking a developer-centric approach
-
Automation and Infrastructure as Code (IaC)
-
Security and compliance
-
Observability
-
Continuous improvement
Platform engineering takes select DevOps practices and codifies them into software. So no, platform engineering isn’t simply advanced DevOps; think of it more as “shifting DevOps down” into the platform, allowing developers to follow some DevOps practices without having to be experts.
4. MYTH: Platform engineering is “just automation”
Automation lets teams reduce the need for human intervention when managing their systems. This can be done simply, as in a shell script, or it can be much more complex, nuanced, and scalable. Generally, when people deride something as “just automation” they’re referring to large numbers of trivial shell scripts that often break.
And it’s true: automation can in fact introduce new, more difficult-to-solve problems. Due to this, avoiding unchecked automation is understandable, where systems begin to fail not due to the quality of automation but due to socio-technical pressures like misinterpretation of signals, misunderstood designs, poor assumptions, or misaligned incentives.
But whereas the “bag of scripts” approach to automation is piecemeal, platform engineering takes a much more holistic approach, by considering the full system lifecycle, from service creation, configuration, and deployment, to monitoring, scaling, and eventual teardown.
So yes, platform engineering is indeed automation, but the platform is delivered as a product and designed for the full service lifecycle, not just bolted-on reactively.
5. MYTH: Platform engineering is just the latest fad
In recent years, the complexity of designing and managing a modern infrastructure and software stack has led to a significant increase in the cognitive load placed on software development teams. So much so that it’s become essential to abstract the deployment and management of these services. You simply can’t have deep knowledge at both the infrastructure and application layer when you have hundreds or thousands of microservices spread across many fleets of compute resources to manage.
Today, platform engineering addresses some real world problems, namely:
-
DevOps overload, a.k.a. cognitive load – when teams become bottlenecks as they try to manage the growing complexity of modern software
-
Developer friction – a team’s quantifiable slowdown from interacting with infrastructure, tooling, policy, and processes. See also: DORA metrics.
Platform engineering caters to the specific needs, processes, workflows, security, and infrastructure of an organization. Its goal is to reduce friction and cognitive overload, thereby improving developer experience.
Related, Platform as a Service (PaaS) predates platform engineering, but it was not always the right fit for some teams. How is platform engineering different from PaaS, you ask? While PaaS provides the technology to efficiently build applications and configure the necessary underlying infrastructure, it needs a surrounding ecosystem of people and processes to be adopted successfully. Platform engineering provides a method for a team to build an abstraction or extension of products, including a PaaS, implementing the constraints or freedoms that are appropriate for their organization. In other words, platform engineering is a response to the “technology-centric” model of PaaS, which doesn’t work for organizations that might need further customization.
In short, platform engineering is happening today as a natural evolution of the DevOps approach to systems of increasing scale. While the paradigm of “you build it, you run it” worked for systems of lower complexity and size, modern software systems are larger and more complex today than before, and the role of platform engineering has become increasingly vital in today’s world.
The elephant is starting to come into view… Dispelling these first 5 myths should help you understand what a platform is and what it isn’t. Be sure to read part two to find five more myths around how platforms are built, what they do and don’t do.