The Facade Is the Product
The Facade Is the Product
There's a question that comes up in almost every platform team at some point:
Should we expose Kubernetes directly to developers, or should we abstract it?
It sounds like a tooling debate. Backstage vs. raw manifests. Helm charts vs. a self-service portal. YAML vs. a form. But underneath all of that, it's actually a design question — and the Facade pattern is the lens that makes it clearer.
What the pattern says
The Facade pattern is straightforward: when a system is too complex for its consumers to deal with directly, you build a simpler interface on top. Consumers interact with the facade. The complexity lives behind it.
The key word is consumers. A facade isn't about hiding things from people who need to know them. It's about not burdening people with complexity that isn't relevant to their job.
Your developers don't need to know which CNI the cluster runs. They don't need to understand how cert-manager issues TLS certificates, or whether secrets come from Vault or AWS Secrets Manager or an ESO sync. That's not their job. Their job is to ship features. Your job, as a platform engineer, is to make sure the infrastructure complexity doesn't get in the way of that.
The platform is the facade. That's not a metaphor — it's the actual pattern.
The cost of not having one
When there's no facade, the complexity leaks.
Developers end up learning Kubernetes internals just to deploy an app. They copy-paste manifests they don't fully understand. They ping the platform team every time something doesn't work because they don't have the mental model to debug it themselves. The platform team becomes a bottleneck — not because they're slow, but because the interface they've built requires too much context to use independently.
This is what the CNCF calls cognitive load, and reducing it is one of the central arguments for Platform Engineering as a discipline. The Platform Engineering Maturity Model essentially describes a journey from "no facade" to "well-designed facade" — from teams managing raw infrastructure to teams consuming curated, opinionated abstractions.
The Facade pattern gives that journey a name and a shape.
The Golden Path is a facade with an opinion
The Golden Path concept — popularized by Spotify and now widely referenced in the platform engineering community — is a specific flavor of the Facade pattern.
It's not just an abstraction. It's an opinionated abstraction. You're not trying to support every possible way to deploy an app. You're defining the recommended way, making it the easiest path, and letting teams deviate only when they have a good reason.
That opinion is the point. A facade without an opinion is just indirection — you've added a layer but haven't reduced the decision space. A Golden Path says: we've already made the hard calls about logging, secrets management, resource limits, and deployment strategy. If you follow this path, those problems are solved for you.
The tradeoff is real though. The more opinionated the facade, the less flexibility consumers have. Getting that balance right — tight enough to provide value, loose enough not to become a cage — is one of the harder design problems in platform engineering.
Where you see this in practice
Backstage Software Templates are a facade over your entire delivery stack. The developer sees a form. Behind it: a repo is created, a CI pipeline is wired up, a Kubernetes namespace is provisioned, a service catalog entry is registered. The facade collapses a multi-step, multi-system process into a single interaction.
Helm charts as internal abstractions are a more granular facade. Instead of exposing raw Kubernetes manifests, you expose a values.yaml with the knobs that actually matter for your context — image tag, replicas, resource tier. Everything else is a sensible default hidden inside the chart.
Port, Cortex, or any internal developer portal — same pattern, different surface. The portal is the facade. It shows developers what they need: service health, deployment status, ownership, runbooks. It hides what they don't: the underlying observability stack, the alerting rules, the infrastructure topology.
Even something as simple as a well-designed Makefile or a CLI wrapper around your deployment scripts is a facade. You're reducing the interface to the things that matter for the person using it.
What changes when you think this way
Back to the original question: should you expose Kubernetes directly or abstract it?
The Facade pattern reframes it. The real question isn't about Kubernetes — it's about who your consumer is and what complexity is relevant to them.
If your consumers are platform engineers building on top of the platform, some Kubernetes exposure might be appropriate. They have the context to use it well. If your consumers are product developers who need to ship features, exposing Kubernetes is almost always the wrong call. The abstraction isn't hiding something useful from them — it's removing friction that shouldn't exist in the first place.
But the more practical shift is this: once you see the platform as a facade, you start asking different questions. Instead of "how do we document all this so developers can figure it out", you ask "what should developers never need to figure out in the first place." Instead of "how do we give developers more access", you ask "what's the right interface for this consumer."
The facade you build should match the consumer you're designing for. And that's a product decision, not a tooling one.
What does your facade look like today — close to the metal, fully abstracted, or somewhere in between? Reply at blog@parraletz.dev.
