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.