Look, I've been working with DevOps tools for years, and here's what drives me crazy: Everyone argues about which tool is "best" when they're all just different types of glue.
You wouldn't use super glue to fix a cardboard box, and you wouldn't use duct tape for fine woodworking. Yet in DevOps, people constantly debate Kubernetes vs Docker vs NixOS like there's one universal answer.
I got excited when I realized that thinking about infrastructure tools like adhesives instantly clarifies which tool to use when. It's not about strength alone - it's about matching the right bonding properties to your specific project needs.
Quick Solution Overview
Here's my glue classification system for DevOps tools:
- Duct Tape (Bash + Debian) - Quick fixes that actually work
- White Glue (Docker) - Reliable, generic, widely supported
- Super Glue (NixOS) - Bonds everything perfectly, but requires precision
- Epoxy (Kubernetes) - Industrial strength when mixed correctly
- Deployment Platforms - The surface everything sticks to
What You Get From This Framework
- Stop tool paralysis - Clear decision criteria for any project
- Match complexity to needs - Don't over-engineer simple problems
- Plan migrations logically - Understand what you're trading off
- Communicate with stakeholders - Everyone understands glue metaphors
- Future-proof decisions - Choose tools that grow with your needs
The Glue Spectrum: From Duct Tape to Epoxy
Duct Tape: Bash Scripts + Debian (The Honest Fix)
When to use: Quick fixes, prototypes, anything that needs to work right now
Why it works: Everyone knows how to use it, fixes 80% of problems, readily available everywhere
# Classic duct tape solution
#!/bin/bash
while ! curl -f http://localhost:8080/health; do
echo "Service down, restarting..."
docker restart my-app
sleep 30
done
The truth about duct tape: When my monitoring system went down at 3 AM, I didn't reach for Prometheus and Grafana. I wrote a 5-line bash script that checked service health every minute. It ran for 6 months while we built the "proper" solution.
Why people underestimate it: Duct tape isn't pretty, but it's often the most pragmatic choice. Simple systems are easier for humans AND AI to understand and improve. That matters more than architectural purity.
White Glue: Docker (The Reliable Standard)
When to use: Standard applications, team environments, anything needing portability
Why it works: Generic enough for most use cases, well-documented, massive ecosystem support
# Docker: Works everywhere, predictable results
FROM node:18-alpine
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["npm", "start"]
The Docker reality: It's not exotic, but it eliminates "works on my machine" problems. Like white glue, you don't reach for it because it's exciting - you reach for it because it consistently does what you expect.
Sweet spot: When you need something that works consistently across different environments without requiring your entire team to become infrastructure experts.
Super Glue: NixOS (The Precision Tool)
When to use: Complex configurations, reproducible systems, when you need everything to fit perfectly
Why it's powerful: Bonds to every part of your system, creates incredibly strong connections, nearly impossible to break when applied correctly
# NixOS: Precise configuration that sticks to everything
{ config, pkgs, ... }: {
services.nginx = {
enable = true;
virtualHosts."myapp.local" = {
locations."/" = {
proxyPass = "http://localhost:3000";
};
};
};
networking.firewall.allowedTCPPorts = [ 80 443 ];
}
The NixOS revelation: I spent months rebuilding my infrastructure with NixOS flakes. Like super glue, it required patience to learn and careful application, but now my infrastructure is unbreakable and perfectly reproducible.
The trade-off: Super glue can be overwhelming. If you accidentally get it where you don't want it, removal is difficult. But when you need precision bonding across your entire system, nothing else compares.
Epoxy: Kubernetes (Industrial Strength Complexity)
When to use: High-scale applications, complex orchestration, when you need industrial-grade reliability
Why it's powerful: Incredible strength when the two-part mixture is applied correctly, handles extreme loads and conditions
# Kubernetes: Complex setup, industrial results
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: my-app:latest
resources:
requests:
memory: "64Mi"
cpu: "250m"
The Kubernetes paradox: Like epoxy, you need to mix multiple components (pods, services, ingress, ConfigMaps) in precise ratios. Mess up the mixture and nothing works. Get it right and you have industrial-strength infrastructure.
The reality check: Most projects don't need epoxy-level strength. Using Kubernetes for a simple web app is like using structural adhesive to hang a picture frame - technically impressive but practically insane.
Here's What I Actually Do
Start with duct tape: Bash script + simple deployment gets you to market fastest
Upgrade to white glue: Docker when you need consistency across environments
Apply super glue selectively: NixOS for critical infrastructure that must be perfect
Mix epoxy carefully: Kubernetes only when you truly need the scale and complexity
Remember the surface: Deployment platforms are what everything sticks to
The Surface Matters: Deployment Platforms
Here's what people miss: The glue is only as good as the surface you're sticking to.
Deployment platforms like AWS Amplify, Vercel, or Railway are the prepared surfaces that make all your glue work better:
- AWS Amplify: Pre-prepped surface for static sites and simple apps
- Vercel: Smooth, clean surface optimized for frontend frameworks
- Railway/Render: Textured surface that grips Docker containers perfectly
- Bare Metal: Raw surface - you control everything but must prep it yourself
My deployment evolution: I went from complex Kubernetes setups to simple git-push deployments on Amplify. Like switching from mixing epoxy to using pre-applied adhesive strips - sometimes the simpler approach is actually superior.
Why This Framework Actually Works
This framework matches tool complexity to problem complexity. Stop using industrial adhesives for household repairs.
It accounts for team skills. Not everyone needs to know how to mix epoxy.
It considers maintenance burden. Duct tape is easy to replace; epoxy requires specialized knowledge.
It enables smart migrations. Understand what you're gaining and losing when switching adhesives.
The human factor: Simple systems are easier for you (and AI assistants) to understand, debug, and improve. That cognitive load reduction matters more than theoretical maximum strength.
Quick Decision Framework
Choose duct tape when you need it working today, team skills are mixed, or the problem might change.
Choose white glue when you need reliability across environments, standard use case, good documentation matters.
Choose super glue when configuration precision is critical, reproducibility is essential, you have time to learn.
Choose epoxy when you need industrial scale, have dedicated DevOps expertise, complexity is justified by requirements.
The Uncomfortable Truth
Most successful companies I know started with duct tape, migrated to white glue, and selectively applied super glue or epoxy only where needed. The companies that failed often started by mixing epoxy when they should have been reaching for duct tape.
Your infrastructure doesn't need to be perfect - it needs to work reliably and be maintainable by your actual team. Sometimes the best technical decision is choosing the "worse" tool that your team can actually use effectively.
The best infrastructure is the one that ships features reliably while letting your team sleep at night. Choose your glue accordingly.
Try this today: Look at your current DevOps stack. Are you using epoxy where duct tape would work? White glue where super glue is needed? Match your adhesive to your actual requirements, not your imagined scale.
Content on this blog was created using human and AI-assisted workflows described here. Original ideas and editorial decisions by Justin Quaintance.