There's a distinction that comes up a lot in platform engineering conversations, and it's worth making explicit.

There's a difference between a team that operates infrastructure and a team that designs a platform.

Both teams run Kubernetes. Both teams write Terraform. Both teams deal with incidents, manage clusters, and keep things running. From the outside, they look similar. From the inside, they make decisions in fundamentally different ways.

The operating team asks: is this working? The platform team asks: why is this designed this way, and what does that design decision cost us over time?

This series has been about developing the second kind of thinking — and about the vocabulary that makes it possible.

What we covered

Six posts. Six patterns. Each one a different lens on a problem that platform engineers face every day.

Factory and Builder — environment provisioning without a creation model is slow, inconsistent, and doesn't scale. When you centralize creation logic, you get consistency, self-service, and the ability to evolve the implementation without changing the interface.

Facade — complexity leaks when there's no abstraction layer. The platform is a facade. The question isn't whether to build one — it's how opinionated to make it, and who it's designed for.

Observer — manual reconciliation doesn't scale. The Kubernetes controller loop is the Observer pattern at cluster scale. Toil is a symptom of missing observers. Name the toil, find the missing observer, build or adopt it.

Command — pipelines that apply changes directly are fast and invisible. GitOps decouples the command from its execution, and that decoupling gives you auditability, reversibility, and drift detection almost for free.

Adapter and Glue — every platform connects systems that weren't designed to talk to each other. That connective tissue is glue. In most platforms, glue is 60-80% of what the team actually builds and maintains. The question isn't whether you'll write it — it's whether you'll design it intentionally.

Strategy — deployment strategy hardcoded into pipelines is a hidden coupling that makes platforms less reliable and harder to evolve. When strategy is a first-class platform concern — declarative, observable, interchangeable — the whole delivery system gets more consistent.

The thread that connects them

Looking back at these six patterns, there's a common thread.

Every one of them is about the same thing: separating concerns that are accidentally coupled, and making that separation explicit.

Factory separates what gets created from how it's created. Facade separates the consumer's interface from the system's complexity. Observer separates the thing that changes from the things that react to it. Command separates the definition of a change from its execution. Adapter separates incompatible interfaces without modifying either. Strategy separates the delivery mechanism from the deployment approach.

This isn't a coincidence. The Gang of Four didn't invent these patterns — they documented solutions that experienced engineers kept independently arriving at, because these couplings cause the same problems everywhere. In codebases. In distributed systems. In platforms.

The platform is a system. It has the same structural problems that software has. And it responds to the same structural solutions.

From glue spaghetti to platform control plane

Earlier in this series, we talked about glue — the code that connects systems that weren't designed to talk to each other. And we mentioned an evolution that a lot of platform teams go through:

scripts/
  deploy.sh
  create-service.sh
  add-monitor.sh
  update-ingress.sh

This is where most platforms start. It's not wrong — it's the natural first step when you're moving fast and the priority is getting things working.

But at some point, the scripts become a liability. They accumulate. They drift. They're owned by whoever wrote them last. They break in ways that are hard to debug because they have no reconciliation semantics, no observability, no clear interfaces.

The teams that scale past this point aren't necessarily the ones with the best tools. They're the ones that start treating the platform as a product with an architecture — not just a collection of scripts that happen to run in the right order.

That shift looks like:

• Glue scripts become operators with proper reconciliation semantics
• Ad-hoc pipelines become platform APIs with clear contracts
• Scattered strategy implementations become a first-class delivery layer
• Manual processes become observers that react automatically
• Implicit conventions become explicit facades that abstract complexity

This is what a platform control plane looks like. Not a specific tool. A specific way of thinking about what the platform is and how it should behave.

And it maps almost exactly to the patterns in this series.

The vocabulary is the point

I want to be honest about what this series was and wasn't trying to do.

It wasn't trying to teach you Kubernetes. You already know Kubernetes. It wasn't trying to convince you to use Argo Rollouts or Crossplane or External Secrets Operator. Those are good tools, but the patterns exist independently of the tools.

What it was trying to do is give you vocabulary.

Vocabulary matters for a few reasons.

It makes architectural decisions explicit. When your team debates whether to expose Kubernetes directly to developers, "how much facade do we build" is a more productive framing than "should we use Backstage or not." The pattern gives the conversation a shape.

It helps you diagnose problems. When your pipelines are slow and tightly coupled, that's not just a pipeline problem — it's a symptom of missing separation of concerns. When you name the pattern that's missing or being violated, the solution space becomes clearer.

It connects you to a larger body of knowledge. The Gang of Four documented these patterns in 1994. Thirty years of software engineers have written about them, extended them, and argued about their limits. That literature is available to platform engineers too — it just needs translation.

And it levels the conversation. When a platform engineer and a software architect talk about the same problem using the same vocabulary, they can build on each other's thinking instead of talking past each other. The platform stops being "the infra people's problem" and starts being a shared architectural concern.

What comes next

This series ends here, but the topic doesn't.

We covered six patterns from the structural and behavioral categories — the ones most directly applicable to platform engineering. There's more to explore: architectural styles like event-driven systems and how they map to platform data planes, distributed systems patterns and how they show up in multi-cluster architectures, and the evolution from platform-as-infrastructure to platform-as-product.

If any of these posts sparked a question, a disagreement, or a "this is exactly what we're dealing with right now" — I'd genuinely like to hear about it.

Hit reply at blog@parraletz.dev. That's where the real conversation happens.

Here's a situation most platform teams have been in.

A team wants to do a canary deployment. So they modify the pipeline. They add a step that deploys to 10% of traffic, waits, checks some metric, then either proceeds or rolls back. It works. Six months later, a different team wants the same thing — but their pipeline is structured differently, so they write their own version. Then someone wants blue/green. Another pipeline modification. Then progressive delivery with automated analysis. Another version, in another pipeline, maintained by another team.

You now have five different implementations of deployment strategies scattered across your CI/CD system. None of them are consistent. All of them are someone's responsibility to maintain. And when something goes wrong mid-deployment, the person on call has to figure out which version of the strategy they're dealing with before they can even start debugging.

This is what happens when deployment strategy is hardcoded into the pipeline instead of being a first-class concern of the platform.

The problem

A deployment pipeline has two distinct jobs that are often collapsed into one.

The first job is delivery: take the artifact, get it to the cluster. The second job is strategy: decide how it gets there — all at once, gradually, with traffic splitting, with automated rollback triggers.

When these two jobs live in the same pipeline, the strategy becomes tightly coupled to the delivery mechanism. Changing the strategy means changing the pipeline. Testing a new approach means modifying infrastructure that other things depend on. And because pipelines are usually owned by individual teams rather than the platform, you end up with strategy logic that's duplicated, inconsistent, and invisible to anyone outside that team.

The deeper problem is that strategy decisions are cross-cutting. They affect reliability, blast radius, rollback time, and developer confidence. They deserve to be made once, implemented well, and available to every team — not reinvented in every pipeline.

Why it hurts

Imagine a deployment goes wrong mid-canary. Traffic is split 20/80 between the new version and the old one. The new version has a bug. You need to roll back.

If the canary logic lives in the pipeline, rollback means re-running the pipeline in reverse — or manually adjusting traffic weights in whatever tool manages them, if you can even find where that is. The pipeline ran its steps and moved on. It's not watching. It's not reacting. It doesn't know the deployment is in a bad state.

Now multiply this by the number of services your platform supports. Each one with its own pipeline, its own strategy implementation, its own rollback procedure. Your platform's deployment reliability is only as good as the worst pipeline in the system.

And when a postmortem asks "why did we deploy 100% of traffic at once to a service that had no rollback plan" — the answer is usually "because the pipeline didn't have that logic and nobody thought to add it."

What the pattern says

The Strategy pattern says: define a family of algorithms, encapsulate each one, and make them interchangeable. The caller selects which strategy to use. The strategy handles the implementation. Neither needs to know the details of the other.

In software, this pattern appears in sorting algorithms, payment processors, compression formats — anywhere you have multiple ways to accomplish the same goal and want to switch between them without changing the code that uses them.

In platform engineering, deployment strategies are exactly this. Rolling update, blue/green, canary, progressive delivery with automated analysis — these are a family of algorithms for getting a new version of software in front of users. They have different risk profiles, different rollback characteristics, different observability requirements. But from the application's perspective, the goal is the same: deploy this version.

The Strategy pattern says that choice should be declarative and interchangeable — not hardcoded into a pipeline.

Where you see this in practice

Argo Rollouts is the clearest implementation of this pattern in the Kubernetes ecosystem. You define a Rollout resource instead of a standard Deployment, and you declare your strategy in the spec:

strategy:
  canary:
    steps:
    - setWeight: 20
    - pause: {duration: 10m}
    - setWeight: 50
    - pause: {duration: 10m}
    - setWeight: 100

The application doesn't know what strategy is being used. The pipeline doesn't implement the strategy — it just triggers the rollout. Argo Rollouts is the executor that watches the rollout progress, manages traffic weights, and reacts to what it sees.

Switching from canary to blue/green is a change to the Rollout spec. Not a pipeline rewrite. Not a new set of scripts. A declarative change to the strategy definition.

Flagger takes the same idea and adds automated analysis. It watches metrics from Prometheus, Datadog, or other sources during a canary deployment and makes promotion decisions automatically. The strategy isn't just declared — it's reactive. If error rates spike, the rollout stops. If latency degrades, it rolls back. The strategy responds to real system state rather than waiting for a human to notice.

Feature flags are a strategy pattern applied at the application layer. Tools like LaunchDarkly, Unleash, or Flagsmith let you decouple the deployment of code from the activation of features. You deploy 100% of traffic — but only 10% of users see the new behavior. The strategy is controlled by the platform, not the pipeline.

The common thread: in all of these, the strategy is a separate, interchangeable concern. It's not woven into the delivery mechanism. It can be changed, tested, and evolved independently.

Hardcoding strategy is an antipattern

When deployment strategy lives in the pipeline, you've created a hidden coupling that's easy to miss until it causes a problem.

The pipeline owns delivery and strategy. Changing one risks breaking the other. Testing a new strategy means modifying production infrastructure. Rolling back a failed strategy change means a pipeline change, not a config change. And visibility into what strategy a given service uses requires reading pipeline code — not a platform API or a manifest in Git.

This is the antipattern. Not because pipelines are bad, but because strategy is a platform concern that's been pushed into a delivery concern. The blast radius of a mistake is larger than it needs to be. The iteration speed on strategy improvements is slower than it needs to be.

Separating strategy from delivery — making it declarative, observable, and interchangeable — is one of the higher-leverage improvements a platform team can make to their deployment reliability.

What changes when you think this way

When strategy is a first-class platform concern, a few things shift.

Reliability becomes consistent. Every service that uses the platform gets the same deployment strategy primitives — canary, blue/green, progressive delivery — without each team having to implement them. The platform team implements once. Every team benefits.

Iteration gets faster. When a team wants to try a more conservative canary rollout, they change a few lines in their Rollout spec. They don't open a ticket to the platform team. They don't modify a shared pipeline. They make a declarative change and the platform handles the rest.

Postmortems get cleaner. When a deployment goes wrong, the strategy execution is visible in the platform — Argo Rollouts has an API, a UI, a clear audit trail. The question "what happened during the rollout" has an answer that doesn't require reading pipeline logs.

The goal isn't to make deployment more complex. It's to make the complexity live in the right place — a dedicated, observable, interchangeable strategy layer — rather than scattered across dozens of pipelines that each solve the same problem in a slightly different way.

Does your platform have a consistent deployment strategy story, or is it still living in individual pipelines? Hit reply at blog@parraletz.dev.

Here's something that doesn't show up in architecture diagrams.

You have Kubernetes. You have Terraform. You have GitHub Actions, ArgoCD, Datadog, Vault, and a developer portal. Each of those tools is well-documented, widely adopted, and excellent at what it does.

None of them were designed to talk to each other.

So you write code that connects them. Code that translates a GitHub push into a Terraform run. Code that creates a Datadog monitor when a new service is deployed. Code that bridges Vault secrets into Kubernetes. Code that turns a Backstage template into a repo, a pipeline, a namespace, and an ArgoCD application.

That code is glue. And in most platforms, it's not a minor detail — it's the majority of what the platform actually is.

The problem

Platform teams spend a lot of time talking about the tools. Kubernetes vs. Nomad. ArgoCD vs. Flux. Terraform vs. Pulumi. The tools are visible, they have logos, they have docs, they have Slack communities.

The glue is invisible. It lives in scripts/ directories, in Lambda functions nobody documented, in GitHub Actions workflows that have grown to 400 lines, in CronJobs that someone wrote two years ago and that now run in production and that nobody fully understands anymore.

The problem isn't that glue exists. Glue is inevitable — any platform that connects more than two systems will have it. The problem is that most teams treat glue as an afterthought rather than as a first-class part of the platform. It accumulates without design. It grows without standards. And eventually it becomes the thing that breaks most often and is hardest to fix.

What glue actually is

In platform engineering, glue is any code or automation that:

• doesn't contain business logic
• doesn't belong to any specific tool
• exists solely to integrate systems

It shows up in many forms. Scripts that generate manifests and inject variables. Webhooks that trigger downstream workflows. Small services that transform data between formats. Operators that watch Kubernetes resources and call external APIs. Lambda functions that bridge cloud events to internal systems.

Take a simple example. A developer pushes code. You want your internal platform API to know about it — who pushed, what SHA, what repo — so it can update the deployment record, trigger downstream automation, and eventually show up in your developer portal.

GitHub doesn't know about your platform API. Your platform API doesn't know about GitHub. So you write glue:

import { Octokit } from "@octokit/rest"
import axios from "axios"

async function notifyDeployment(repo: string, sha: string) {
  const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN })

  const commit = await octokit.repos.getCommit({
    owner: "org",
    repo,
    ref: sha
  })

  await axios.post("https://platform-api/deployments", {
    repo,
    sha,
    author: commit.data.commit.author?.name
  })
}

This code is not part of GitHub. It's not part of Kubernetes. It's not part of Datadog. It exists only to connect them. That's glue.

Where glue lives in a real platform

A typical delivery flow looks something like this:

GitHub push
    ↓
GitHub Actions
    ↓
Terraform / Helm
    ↓
Kubernetes
    ↓
ArgoCD
    ↓
Datadog
    ↓
Slack notification

Everything in that diagram is a well-known tool. But everything between those tools — the thing that takes output from one and feeds it to the next, that translates formats, that triggers the next step, that handles errors in the transition — is glue.

In practice, platform glue tends to cluster around five areas:

CI/CD glue — scripts and pipeline steps that connect your version control to your delivery system. Generating manifests from templates. Injecting environment-specific variables. Validating policy before apply. Running post-deploy checks.

GitOps glue — the translation layer between developer intent and the manifests that ArgoCD or Flux actually apply. A service.yaml that describes what a developer wants gets translated into Helm values, which become an Argo Rollout, which triggers a Datadog monitor creation. Each step in that chain is glue.

Observability glue — automation that creates dashboards, alerts, and SLOs when a new service is registered. Without this, observability setup is manual and inconsistent. With it, every service gets a standard monitoring baseline automatically.

Security glue — the code that bridges Vault, IAM, Kubernetes service accounts, and CI/CD pipelines. External Secrets Operator is a well-known example of productized security glue, but most platforms have additional custom pieces connecting their specific identity model to their specific secret stores.

Developer experience glue — the automation behind an IDP action. When a developer creates a service in Backstage, something has to run the repo template, call Terraform, register the ArgoCD application, and create the initial deployment. That workflow is pure glue logic.

The Adapter pattern: a frame for thinking about glue

The Adapter pattern from software design is the closest conceptual frame for what glue does. It says: when two systems have incompatible interfaces, build a component that translates between them without changing either system.

That's exactly what glue is. ESO is an adapter between secret managers and Kubernetes. KEDA is an adapter between external event sources and the Kubernetes scaling API. Your notifyDeployment function is an adapter between GitHub and your platform API.

Thinking about glue as adapters is useful because it sets a design standard. A well-designed adapter:

• translates between two specific interfaces without changing either
• reconciles continuously rather than running once and hoping
• handles the source being unavailable gracefully
• surfaces errors through observable, standard mechanisms
• is maintainable by someone other than the person who wrote it

Most ad-hoc glue fails on at least three of those. That's not a criticism — it's a pattern. Glue starts as a quick script because the need is urgent, and it evolves into a liability because nobody went back to design it properly.

The 60-80% problem

In practice, a significant portion of what a platform team actually builds and maintains is glue. Not Kubernetes. Not Terraform. The code that connects them.

This is a pattern that shows up repeatedly in mature platform teams: the tools are 20% of the work, the integrations between them are 80%. And yet most platform teams staff, document, and design for the tools — not the glue.

The teams that handle this well tend to go through the same evolution:

scripts/
  deploy.sh
  create-service.sh
  add-monitor.sh
  update-ingress.sh

This works at small scale. It stops working when you have ten teams, three environments, and a platform that needs to be reliable rather than just functional.

So the scripts get promoted. Some become operators. Some become controllers. Some become platform services with proper APIs. The glue doesn't disappear — it gets intentional design applied to it. The platform stops being a collection of scripts that connect tools and starts being a system with clear interfaces, reconciliation semantics, and something approaching reliability.

That evolution — from glue spaghetti to platform control plane — is its own topic. But it starts with recognizing that the glue is not a side effect of the platform. In many cases, the glue is the platform.

What does your glue look like today — scattered scripts, promoted operators, or something in between? Hit reply at blog@parraletz.dev.

Here's a scenario that plays out in a lot of platform teams.

Your CI/CD pipeline runs kubectl apply as a job step. It exits zero. The pipeline goes green. Deployment successful — or so the dashboard says. But nobody actually knows if the manifest that was applied was valid, if the pods came up healthy, or if the service is responding. So you add another job to check. And another to verify the rollout. And a retry mechanism for when the check fails. And now your pipeline is a sequence of shell scripts duct-taped together, each one trying to compensate for the fact that the previous step had no way to confirm its own outcome.

And when something goes wrong — which it does — you're cross-referencing pipeline logs, Kubernetes events, and Slack messages trying to reconstruct what actually happened and in what order.

This is the problem that GitOps solves. But the usual explanation — "Git is your source of truth" — doesn't tell you why that works, or why it's architecturally sound rather than just a convention someone decided to follow.

The Command pattern does.

The problem

Pipelines that apply changes directly are fast and simple. They're also invisible.

When a CI/CD pipeline runs kubectl apply or terraform apply directly, the action happens and disappears. You have a log entry somewhere, maybe. You have the pipeline run in your CI system, if you know where to look. But the intent — what was supposed to happen, who requested it, what the expected state was — isn't captured anywhere durable.

This creates a class of problems that compound over time. Drift between what's in your repo and what's actually running. No reliable way to roll back a change without re-running a pipeline in reverse. Audit trails that live in your CI system instead of with the infrastructure they describe. And a mental model problem: nobody has a single place to look to understand the current intended state of the system.

The deeper issue is that executing and recording are coupled. The change happens and the record of the change is scattered across logs, pipeline runs, and people's memory. When something goes wrong, you're reconstructing history instead of reading it.

Why it hurts

Imagine you need to answer a simple question: what changed in the production cluster between Tuesday and Thursday?

Without GitOps, that question requires cross-referencing CI pipeline runs, Kubernetes audit logs, Slack messages, and whoever was on call. Each of those sources has partial information. None of them has the full picture. And if the change was a manual kubectl apply that someone ran from their laptop, it might not appear anywhere at all.

Now multiply that across ten services, three environments, and a team of fifteen. The cognitive overhead of understanding the current state of your platform becomes a full-time job. And when incidents happen — which they do — the time you spend reconstructing what changed is time you're not spending fixing the problem.

What the pattern says

The Command pattern says: instead of executing an action directly, encapsulate it as an object — something that can be stored, passed around, queued, undone, or audited — and separate the act of defining the command from the act of executing it.

In software, this pattern shows up in undo/redo systems, job queues, and transaction logs. The key insight is that by making the command a first-class thing — not just a function call that disappears — you gain properties you couldn't have otherwise: history, reversibility, auditability, and the ability to replay or defer execution.

In platform engineering, a Git commit in a GitOps repository is exactly this. It's not just a text change. It's a persisted command — with an author, a timestamp, a description of intent, and the ability to be reversed with a git revert. The commit is the command object. ArgoCD or Flux is the executor that reads that command and applies it to the cluster.

The separation is the point. The commit and the apply are two distinct steps, with Git in between acting as a durable, auditable command queue.

Where you see this in practice

ArgoCD and Flux are Command pattern executors. Their job is to watch a Git repository — the command queue — and continuously reconcile the cluster state against the commands stored there. When a new commit arrives, they execute it. When the cluster drifts from the desired state, they re-execute the last command to bring it back.

This is why GitOps gives you drift detection almost for free. The executor is always comparing what the command says against what's actually running. Drift is just a command that hasn't been fully executed yet.

Terraform with remote state applies the same idea to infrastructure. The .tf files are the commands. The state file is the record of what's been executed. terraform plan shows you what the command would do before you run it. terraform apply executes it. The separation between plan and apply is the Command pattern in action.

Pull Request workflows add another layer. Before a command is committed to the queue, it goes through review. The PR is the command in draft — visible, discussable, and rejectable before it's persisted. Merge is the moment the command becomes official. This is why "GitOps with PR-based workflows" gives you change management essentially for free, without a separate tool.

Argo Workflows and Tekton extend this to pipeline definitions. The pipeline itself is a command — defined declaratively, stored in Git, executed by the platform. You're not running imperative scripts. You're defining commands that the platform knows how to execute.

What changes when you think this way

The Command framing answers a question that comes up constantly: why GitOps instead of just running kubectl apply in a pipeline?

The answer isn't "because GitOps is best practice." The answer is that running kubectl apply in a pipeline couples execution to the pipeline run. The command and its execution happen at the same time and leave no durable record tied to the infrastructure itself. GitOps decouples them — the command lives in Git, the executor applies it, and the two can operate independently.

That decoupling gives you things that are very hard to retrofit:

• Auditability — every change has an author, a timestamp, and a description, tied to the infrastructure it describes
• Reversibility — rolling back is a git revert, not a re-run of a pipeline in the right order with the right parameters
• Drift detection — the executor knows what the command says and can tell you when reality disagrees
• Separation of concerns — the team that defines what should be running is decoupled from the mechanism that makes it run

Once you see a Git commit as a command object rather than just a file change, the architecture of GitOps stops being a convention and starts being a deliberate design choice with clear properties. And that makes it much easier to explain, defend, and extend.

Is your team still running direct applies in pipelines? Or have you made the jump to GitOps? Either way — what's the hardest part of the transition? Hit reply at blog@parraletz.dev.

At some point, most platform teams hit the same wall.

A service goes down. An secret expires. A node runs out of disk. And the first question in the postmortem is always the same: why didn't we know sooner?

So you add more monitoring. More alerts. More dashboards. And somewhere along the way, someone suggests: "we should build a controller that watches for this and reacts automatically."

That controller is an Observer. You probably didn't call it that either.

The problem

Manual reconciliation doesn't scale.

When your platform grows — more clusters, more teams, more services — the list of things someone needs to watch and react to grows with it. Certificate expiration. Secret rotation. Node pressure. Deployment drift. Config changes that need to propagate across namespaces.

If the reaction to any of these depends on a human noticing and acting, you have a fragile system. Not because your team is slow, but because humans aren't designed to watch dozens of state transitions simultaneously and react to all of them in real time.

The deeper problem is coupling. When your response logic lives in runbooks, scripts, or people's heads, it's tightly coupled to whoever wrote it. It doesn't compose. It doesn't scale. And it breaks in the exact moment you need it most — when things are moving fast and nobody has time to read the runbook.

Why it hurts

Think about secret rotation without automation. Someone sets a reminder. The reminder gets missed. The secret expires in production on a Friday at 5pm. Three people get paged. The incident takes two hours to resolve, not because the fix is hard, but because nobody had a clear picture of what was watching what.

Or think about configuration drift. A team manually edits a ConfigMap in staging. Nobody notices it diverged from what's in Git. Three weeks later, a deployment to production behaves differently than expected. The diff is one line. Finding it takes half a day.

These aren't rare edge cases. They're the steady background noise of a platform that reacts to change manually instead of automatically.

What the pattern says

The Observer pattern says: when the state of something changes, every component that cares about that change gets notified and can react — without the thing that changed needing to know who's watching.

There are two roles. The subject holds state and emits events when that state changes. The observers subscribe to those events and decide what to do with them. The subject doesn't care how many observers there are or what they do. The observers don't care how the state changed or who triggered it.

The key property is decoupling. The thing that changes and the things that react to that change don't need to know about each other. You can add new observers without touching the subject. You can change how the subject works without touching the observers.

Where you see this in practice

The Kubernetes controller loop is the Observer pattern implemented at cluster scale — and it's the most important example in this entire series.

Every controller in Kubernetes follows the same structure: watch a resource for changes, compare the current state against the desired state, and act to close the gap. The API server is the subject. Controllers are the observers. When you create a Deployment, the Deployment controller observes that event and starts reconciling — creating ReplicaSets, scheduling Pods, updating status.

You didn't wire them together explicitly. The controller registered its interest in Deployments, and the API server notifies it when something changes. That's the pattern.

Operators extend this to your own domain. When you write a Kubernetes Operator — or adopt one like External Secrets Operator, Cert-Manager, or Argo Rollouts — you're writing an Observer for a specific kind of state change. External Secrets Operator watches for ExternalSecret resources and reacts by fetching secrets from Vault or AWS Secrets Manager and syncing them into Kubernetes Secrets. Cert-Manager watches for Certificate resources and reacts by requesting TLS certificates from Let's Encrypt.

Each of these is an automated response to a state change. No runbook. No human in the loop. The observer watches, the event happens, the reaction fires.

Argo Rollouts takes this further into deployment strategy. It observes metrics from Prometheus during a canary deployment and reacts automatically — promote if the error rate stays below the threshold, roll back if it spikes. The deployment strategy becomes a set of Observer reactions to real-time system state rather than a manual decision made by an engineer watching a dashboard.

When to write one and when not to

Knowing this pattern helps you make a decision that comes up more often than it should: should we write a custom operator for this?

The answer is usually: only if the thing you're watching and the reaction you need aren't covered by an existing operator, and only if the operational value justifies the maintenance cost.

Writing an operator is committing to a stateful, long-running Observer. It will need to handle edge cases — what happens if it misses an event? What if the reaction fails halfway? What if the resource it's watching gets deleted while it's processing? These aren't reasons not to write one, but they're reasons to reach for an existing operator first and build a custom one only when you have a clear gap.

The pattern also helps you evaluate existing tools more clearly. When you're comparing Cert-Manager vs. manually rotating certificates via a CronJob, you're really comparing "a well-designed Observer with proper reconciliation semantics" vs. "a polling loop that approximates observation." That framing makes the tradeoff obvious.

What changes when you think this way

When you see your platform through the Observer lens, the question shifts from "who is responsible for watching this?" to "what should be watching this automatically?"

That's not just a semantic difference. It changes how you design for reliability. Instead of writing runbooks that tell humans what to watch and when to react, you build controllers that watch continuously and react consistently. The human moves from being the observer to being the designer of observers.

It also changes how you think about toil. Toil — the repetitive, manual, automatable work that plagues ops teams — is almost always a symptom of missing observers. If someone is manually rotating secrets, there's no secret observer. If someone is manually syncing configs across environments, there's no config observer. If someone is manually checking whether a canary deployment looks healthy enough to promote, there's no metrics observer.

Name the toil. Find the missing observer. Build or adopt it.

What's something your team is still watching manually that should have an observer by now? Hit reply at blog@parraletz.dev — I'd bet the pattern already exists.

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.

Every platform team eventually faces the same request, over and over again.

A developer needs a new environment — staging, a feature branch, a sandbox for testing. They open a ticket, fill out a form, ping someone on Slack, or run a script they half-understand. A few minutes or a few days later, the environment exists. Or it doesn't. Or it exists but it's missing the secrets. Or the resource limits are wrong. Or it was set up differently than the last one.

This is the problem: environment provisioning without a clear creation model is slow, inconsistent, and doesn't scale.

Why it hurts

When there's no centralized creation logic, every team invents their own process. Some copy-paste Terraform from a previous project. Some run scripts that only the original author understands. Some open tickets and wait.

The result is environments that drift. Staging doesn't match production. The new service has a different secret management setup than everything else. Resource limits are either too tight or nonexistent. And every time something breaks, the platform team has to reverse-engineer how that environment was created in the first place.

Beyond the technical debt, there's a trust problem. Developers stop trusting that the environment they get will actually work. They start maintaining their own workarounds. The platform team loses credibility not because they're incompetent, but because the process itself is unreliable.

What the pattern says

The Factory pattern says: instead of letting every caller decide how to create something, you centralize that creation logic in one place. The caller says what they want. The factory decides how to build it.

The Abstract Factory goes one level up — it creates families of related objects that are meant to work together. Not just a namespace, but a namespace plus secrets plus network policies plus resource quotas plus an observability entry. Things that belong together get created together, consistently, every time.

In software, this pattern exists to avoid the chaos of scattered instantiation logic. In platform engineering, it exists for the same reason: to avoid the chaos of scattered provisioning logic.

Where you see this in practice

Crossplane is the clearest implementation of this pattern in the cloud-native ecosystem. You define a Composite Resource — say, an AppEnvironment — and Crossplane composes it from lower-level resources: an RDS instance, an S3 bucket, a Kubernetes namespace, an IAM role. The developer asks for an AppEnvironment. They don't know or care what's underneath. The factory handles it.

The AppEnvironment XRD is the interface. The composition is the implementation. You can swap the implementation — move from AWS to GCP, change the database engine — without touching the interface the developer uses.

Backstage Software Templates work the same way. A developer picks a template — "Python microservice", "data pipeline", "internal tool" — and gets back a repo, a CI/CD pipeline, a Kubernetes manifest, and a service catalog entry. The template is the factory. The developer just chose the product type.

Terraform modules are the most familiar version of this idea. A well-designed module is a factory for infrastructure — you pass in variables (the what), the module handles the implementation details (the how). The problem is that most teams end up with modules that are too thin, just wrappers around resources, instead of modules that encapsulate a meaningful unit of infrastructure with sensible defaults and guardrails built in.

The Builder pattern: when creation has steps

The Builder pattern is a close relative. Where Factory focuses on what you're creating, Builder focuses on how you assemble something complex step by step.

Think of a cluster bootstrap pipeline. It doesn't create everything at once. It runs in stages: provision the cluster, install the CNI, configure cert-manager, deploy the ingress controller, register with ArgoCD, apply the base manifests. Each step depends on the previous one. The order matters.

Helm with dependencies, Terraform with depends_on, pipelines chaining multiple workspaces — these are all Builder implementations. You're constructing a complex result piece by piece, in a defined sequence, with a clear separation between "how we build this" and "what we end up with."

AWS CDK is an interesting case here. It's deeply influenced by the Builder pattern — you construct infrastructure programmatically using loops, conditionals, and abstractions. The mental model is sound. But it also requires teams to fully commit to that abstraction layer, which is a significant shift if your team lives in Terraform or plain YAML. That might be part of why CDK hasn't seen the adoption you'd expect given how well-designed it is — the pattern is right, but the switching cost is real.

The distinction between Factory and Builder matters when something breaks. A Factory failure tells you what couldn't be created. A Builder failure tells you which step broke — which is much easier to recover from.

What changes when you think this way

When someone on your team says "we should let teams provision their own environments", the Factory framing turns a vague discussion into a concrete design question: how much of the creation logic do you centralize, and how much flexibility do you expose?

Do you give teams raw Terraform and hope they follow conventions? That's no factory — just scattered creation logic waiting to drift. Do you give them a module with sensible defaults and a few knobs to turn? That's a thin factory. Do you give them a Backstage template that hides everything behind a form? That's a full factory.

Each of those is a valid choice depending on your context. The pattern doesn't tell you which one to pick — it gives you the vocabulary to make that decision intentionally instead of stumbling into it.

You're not debating Terraform vs. Crossplane. You're debating how much creation logic should live in one place, and who should own it. That's an architectural decision. It deserves to be treated like one.

How does your team handle environment provisioning today — scattered scripts, thin modules, or full abstraction? Hit reply at blog@parraletz.dev — curious where people have landed on this.

At some point, most platform engineers end up in a conversation with a senior dev or a software architect where you're trying to explain how your infrastructure works.

And somewhere in the middle of that conversation, something clicks. You're both describing the same problems. You're reaching for the same solutions. The only difference is the vocabulary — they say "Facade", you say "developer abstraction layer". They say "Observer pattern", you say "controller loop". They say "Command", you say "GitOps".

Same architecture. Different words.

What I've found is that design patterns aren't really a software thing. They're a complexity thing. And if there's one domain that deals with complexity at scale every single day, it's platform engineering.

This post is the first in a series that explores exactly that.

The problem with how design patterns are taught

Design patterns come from a book called Design Patterns, published in 1994 by four authors the industry nicknamed the "Gang of Four" (GoF). The book is genuinely great. It's also full of examples like "imagine you have a WordDocument class and you need a PDFDocument class..."

If your day-to-day doesn't involve classes and inheritance, that framing is just noise.

But the patterns themselves aren't really about code. They're about how to deal with complexity as a system grows. And platforms have exactly those problems — just at a different scale and with different tools.

The thesis of this series is pretty straightforward: the design patterns developers learned in school or from a book? You're already applying them in your platform. Nobody just introduced them by name.

Three quick examples to make the case

The Facade: why platform teams exist in the first place

The Facade pattern says that when a system gets too complex, you build a simplified interface on top. Consumers talk to the facade, not to the guts of the system.

That's exactly what an Internal Developer Platform does. Your developers shouldn't need to know whether a secret comes from Vault, AWS Secrets Manager, or a ConfigMap. They shouldn't need to care which CNI the cluster runs, or how the ingress controller works under the hood. The platform is the facade. You're the one designing it.

When your team debates whether to expose Kubernetes directly to developers or abstract it behind a Backstage template — that's a conversation about how much facade to build. That's design work, not ops work.

The Observer: the controller loop you already know

The Observer pattern says that when an object's state changes, everything that depends on it gets notified automatically.

The Kubernetes controller loop is exactly that, implemented at cluster scale. There's a desired state (what's in etcd), an actual state (what's running), and controllers that watch the gap and act on it. Argo Rollouts watches Prometheus metrics to decide whether a canary should keep going or roll back. External Secrets Operator watches Vault for changes and syncs secrets accordingly.

Every operator you write or adopt is an implementation of the Observer pattern. Knowing that helps you decide when writing one actually makes sense — and when it's just adding complexity for fun.

The Command: why GitOps makes sense from first principles

The Command pattern says that instead of executing an action directly, you wrap it in an object that can be stored, passed around, undone, or audited.

A commit in your GitOps repo is exactly that. It's not just a text change. It's a persisted command — with an author, a timestamp, and the ability to be reversed with a git revert. ArgoCD or Flux is the executor that takes that command and applies it to the cluster.

The question "why GitOps instead of pipelines that just run kubectl apply?" has a deeper answer than "because it's best practice." It has an architectural answer: because separating the command from its execution gives you properties — auditability, reversibility, a single source of truth — that you'd otherwise have to build from scratch.

Where this is going

This is just the hook. The rest of the series goes pattern by pattern, connecting each one to real platform decisions:

• Factory and Builder → how an IDP thinks when it provisions environments
• Facade → the cost of cognitive load and the Golden Path
• Observer → when to write an operator and when to step back
• Command → GitOps explained from first principles
• Adapter → why the Kubernetes ecosystem is basically a catalog of adapters, and why that's a feature
• Strategy → why hardcoding your deployment strategy into the pipeline is an antipattern

The goal isn't for you to finish this series knowing more pattern trivia. The goal is that next time you make a platform decision, you have better vocabulary to explain it, defend it, or challenge it.

There's a practical side to this that I find underrated: patterns also help you diagnose problems. If your pipelines are slow and tightly coupled, that's not just a pipeline problem — that's a symptom of missing separation of concerns, which maps directly to specific patterns that exist precisely to solve it. Once you can name what's wrong architecturally, the solution space gets a lot clearer. You stop googling "how to speed up my CI pipeline" and start asking "what's the right pattern for decoupling this."

Because the difference between a team that operates infrastructure and one that designs a platform isn't the tool stack. It's whether they're making architectural decisions on purpose — or just stumbling into them.

If this resonates, the next posts go deeper on each pattern. You can follow along or reply directly at blog@parraletz.dev — I read everything.

bash

ml-project/
├── .git/
├── src/
│   └── train.py
├── data/
│   └── training.csv  # 5GB, in Git
└── models/
    └── model.pkl     # 2GB, in Git

Primera pregunta: ¿Cómo está esto en Git?

Respuesta común:

bash

# .gitignore
data/
models/

# Entonces... ¿cómo compartes los datos?
# "Los tenemos en S3"

# ¿Versionados?
# "...no"

El problema fundamental:

Código es fácil:

python

# Version 1
model = Model(lr=0.01)

# Version 2
model = Model(lr=0.001)

# Git diff:
- model = Model(lr=0.01)
+ model = Model(lr=0.001)

# Clear, concise, mergeable

Datos no:

training.parquet v1: 50GB
training.parquet v2: 55GB

# Git diff:
Binary files differ

# ¿Qué cambió?
# - ¿5GB de nuevas filas?
# - ¿Se modificaron filas existentes?
# - ¿Cambió el schema?
# ¿Quién sabe?

Los 5 problemas de versionar datos:

PROBLEMA 1: Tamaño

bash

git add data/training.parquet  # 50GB

# Git:
error: File data/training.parquet is 50GB
hint: Use Git LFS for files larger than 100MB

git lfs install
git lfs track "*.parquet"
git add data/training.parquet
git push

# GitHub/GitLab:
error: File exceeds 5GB limit
# Even with LFS

PROBLEMA 2: Performance

bash

git clone repo

# With 50GB dataset in Git:
# Clone time: 45 minutes
# Disk usage: 100GB (working copy + .git)
# CI/CD: Timeout después de 1 hora

PROBLEMA 3: No es text-based

bash

git diff data/training.csv

# CSV de 10M filas:
+row_9874561,value1,value2,...
+row_9874562,value1,value2,...
-row_9874563,old_value1,old_value2,...
...
# 10 million line diff
# Inútil

PROBLEMA 4: Merge conflicts

bash

# Branch A: Agrega 1M filas
# Branch B: Agrega 1M filas diferentes

git merge branch-b

CONFLICT in data/training.csv
# ¿Cómo resuelves esto?
# ¿Manualmente en un CSV de 15M filas?

PROBLEMA 5: Cost

bash

# Git LFS en GitHub
# - Free: 1GB storage, 1GB bandwidth
# - Paid: $5/month per 50GB storage

# Dataset de 500GB:
# $50/month solo para storage
# + bandwidth costs

# S3:
# $11.50/month per 500GB
# Mucho más barato
```

---

**Por qué los datos son diferentes del código:**

| Característica | Código | Datos |
|----------------|--------|-------|
| Tamaño | KB-MB | GB-TB |
| Formato | Text | Binary (parquet, tfrecord) |
| Cambios | Líneas específicas | Filas/distribuciones |
| Merge | Posible | Imposible |
| Diff | Meaningful | "Binary files differ" |
| Storage | Git OK | Git no funciona |
| Versioning | Commits | Checksums/hashes |

---

**Lo que realmente necesitas:**

No solo versionar archivos. Versionar **contexto**:

**1. El dataset mismo**
```
training.parquet
  - Size: 50GB
  - Hash: a1b2c3d4e5f6
  - Location: s3://data/training/v2.3.1/

2. Metadata

yaml

dataset: training-v2.3.1
created: 2024-01-15
rows: 1,234,567
columns: 45
schema:
  user_id: int64
  timestamp: datetime64
  feature_1: float64
  ...
source: production-db
query: |
  SELECT * FROM events
  WHERE date > '2023-01-01'
  AND user_type = 'active'

3. Statistics

yaml

distributions:
  feature_1:
    mean: 0.547
    std: 0.231
    min: 0.0
    max: 1.0
  feature_2:
    unique_values: 47
    top_3: ['A', 'B', 'C']
    missing: 2.3%
```

**4. Lineage**
```
training-v2.3.1
  ← derived from raw-events-v1.5.2
    ← extracted from production-db
      ← populated by application-v2.1.0

5. Validation

yaml

checks:
  - no_missing_values: PASS
  - schema_match: PASS
  - distribution_drift: WARN (feature_3 shifted)
  - no_duplicates: PASS
```

---

**Casos reales donde Git falló:**

**CASO 1: El dataset "desapareció"**
```
DS: "Necesito el dataset de hace 3 meses"
Yo: "¿Está en Git?"
DS: "No, era muy grande"
Yo: "¿Dónde está?"
DS: "En s3://data/training.parquet"
Yo: "Eso se sobrescribe cada semana"
DS: "..."

# Dataset perdido para siempre
# 3 meses de trabajo para re-generarlo

CASO 2: El merge conflict imposible

bash

git merge feature-new-data-source

CONFLICT in data/training.csv

# 10 million lines en conflict
# Impossible resolver manualmente
# Tuvimos que re-generar todo el dataset
# 2 semanas de trabajo perdidas

CASO 3: El CI/CD que nunca terminó

yaml

# .github/workflows/train.yaml
steps:
  - name: Checkout
    uses: actions/checkout@v3

  # Descarga 50GB de datos de Git LFS
  # Timeout después de 6 horas
  # CI/CD nunca completa
  # No podemos hacer automated training
```

---

**La solución correcta:**
```
Código → Git
Datos → Data versioning tool (DVC, LakeFS, etc.)
Modelos → Model registry (MLflow, etc.)
```

**Separación de concerns:**
```
┌─────────────────────────────────────┐
│           Git (Source Control)      │
│                                     │
│  - Code                             │
│  - Config                           │
│  - Pipelines                        │
│  - .dvc files (pointers)           │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│     DVC/LakeFS (Data Versioning)    │
│                                     │
│  - Training datasets                │
│  - Validation datasets              │
│  - Feature sets                     │
│  - Metadata                         │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│      MLflow (Model Registry)        │
│                                     │
│  - Trained models                   │
│  - Metrics                          │
│  - Hyperparameters                  │
│  - Artifacts                        │
└─────────────────────────────────────┘

Ejemplo práctico:

SIN data versioning:

python

# train.py
data = pd.read_parquet("s3://data/training.parquet")
model = train(data)
mlflow.log_model(model, "model")

# 3 meses después:
# "¿Con qué datos se entrenó este modelo?"
# "...no sé"

CON data versioning:

python

# train.py
import dvc.api

# Pull specific data version
data_version = "v2.3.1"
with dvc.api.open(
    'data/training.parquet',
    rev=data_version
) as f:
    data = pd.read_parquet(f)

# Train
model = train(data)

# Log everything
mlflow.log_param("data_version", data_version)
mlflow.log_param("data_hash", get_data_hash())
mlflow.log_param("data_rows", len(data))
mlflow.log_model(model, "model")

# 3 meses después:
# "¿Con qué datos se entrenó?"
# "data_version: v2.3.1, hash: a1b2c3"
# "Puedo reproducirlo: dvc checkout v2.3.1"

Las preguntas críticas:

Puedes responder:

1. Reproducibilidad

¿Puedes reproducir el experimento #142?
→ Sí: data v2.1.3 + code commit abc123

2. Debugging

¿Por qué el modelo empeoró?
→ Data drift: v2.3.1 vs v2.3.2
→ mean(feature_x): 0.5 → 0.7

3. Compliance

¿Qué datos personales contiene este modelo?
→ Dataset v2.1.3
→ Metadata dice: no PII
→ Validation logs confirman

4. Rollback

Necesito volver al dataset de la semana pasada
→ dvc checkout v2.2.9
→ 30 segundos

Comparativa rápida:

Tu turno: ¿Cómo versionas tus datos hoy? ¿O es "latest.parquet" y rezar?