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.
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.
