Ten microservices on this cluster are deployed by ArgoCD. Prometheus, Grafana, AlertManager, Elasticsearch, Filebeat and Kibana are not. They are installed by Helm, by hand, from a bastion host.
That looks like the part I did not get around to automating. It is deliberate, and the reason is a question worth asking of any GitOps setup: what do you debug ArgoCD with?
I deployed the same Spring Boot JAR on EC2 with an Auto Scaling Group, on ECS Fargate, on a bare metal Kubernetes cluster, and on EKS. The artifact never changed. Everything that changed between the four is therefore not a property of the application, which makes it a fairly honest way to find out what each layer actually costs to operate.
I went back through a year of my own failures across five projects and found the same one ten times. Every case had the same shape: I set a value, the tool accepted it, the tool did not apply it, and nothing anywhere said so.
This is the list, grouped by the reason each tool stayed quiet, because the groups turn out to be more useful than the instances.
Every image my pipelines build gets tagged twice, and only one of those tags is permitted to reach a cluster. This is the reasoning behind that split, why the version comes from a different place in every language, and the specific production failure that made me put both images of a two-image application in a single commit.
I implemented an identical DevSecOps pipeline twice for three applications, once as a Jenkinsfile and once as a GitHub Actions workflow. Same stages, same tools, same artifacts. Jenkins consistently needed about 40 percent more code. This is where that difference comes from, which of the divergences actually mattered, and the one place the two implementations had quietly stopped being identical without either file looking wrong.
I wrote the same DevSecOps pipeline for a Spring Boot app, a Flask app and a Node three-tier app. The stage order came out identical in all three. The stage count did not: 14, 16 and 21. This is what stayed fixed, what diverged, and why trying to force uniformity made every pipeline worse.
The build step succeeded. The next step scanned the image it had just produced and reported that no such image existed. Both steps were correct: the image was real, and it was not anywhere Trivy knew how to look. This is what load: true actually does, and why a scanner that fails to find an image is a more dangerous failure than one that finds vulnerabilities.
None of these were reported by anything. The pipeline was green before each fix and green after it. What changed is what the green meant: a coverage graph that was measuring infrastructure failures as test regressions, a success banner claiming images were published when nothing had been pushed, and a tag that would have deployed the four-character string null if one stage had ever been skipped.
Splitting an Express app into three tiers took one line out of server.js. That line was the only thing serving the frontend, and removing it created a question the original architecture never had to answer: with the API no longer serving the UI, what does? I tried three answers before the right one, and each failure was a different lesson about what decoupling actually costs.
Getting a playground published is not the same as getting it usable. Between "the VM booted" and "a stranger can do the thing you built this for" sits a pile of work: packages, repositories, config files, seeded data, services that need to be running. The iximiuz Labs manifest gives you two places to put that work, and your Dockerfile is a third.
I picked the third for all six of my images. This is what the other two do, when each one is right, and the reasoning that made me choose the one I did.