Cloud-Native Complexity vs. The Almighty Bash Script
Description
A black-and-white cartoon meme, set in front of a warehouse, contrasting two approaches to system administration and automation. On the left, a developer pushes a cart piled high with boxes, each bearing the logo of a complex cloud-native or DevOps tool, including Kubernetes, Istio, KEDA, Argo CD, Knative, Prometheus, and others. Another character asks, 'Is that all you need?'. On the right, a second developer stands calmly, holding a single, small box labeled 'bash scripts' and replies confidently, 'Yes.'. The meme satirizes the perceived over-engineering and immense complexity of the modern cloud-native and DevOps landscape, particularly the Kubernetes ecosystem. It champions the minimalist and powerful philosophy of using simple, fundamental tools like shell scripts to accomplish tasks. The humor resonates with experienced engineers who have witnessed the high operational overhead of these complex systems and appreciate the raw utility and simplicity of a well-written script, suggesting it's often a more pragmatic solution than adopting a massive stack of technologies
Comments
26Comment deleted
The Kubernetes stack is great until a certificate expires in the service mesh and brings everything down. Meanwhile, my bash script just keeps running, blissfully unaware of what a 'sidecar proxy' even is
It’s still a single “cp” in a while-true loop - just wrapped in Helm, Argo, Istio, Prometheus and KEDA so we can invoice it as a self-healing, cloud-native, GitOps-driven microservice
The same bash script that's been running in production since 2008 has outlived three Kubernetes migrations, two microservice rewrites, and the entire team that originally complained about it
One of them will spend Q3 migrating service meshes; the other will still be running the same cron job that's had five nines since 2014
After 15 years in the industry, you realize that 90% of 'cloud-native microservices orchestration' problems can be solved with a well-written bash script, cron, and rsync. The other 10% probably didn't need solving in the first place - but good luck explaining that to the team that just spent six months setting up their Kubernetes cluster with service mesh, observability stack, and GitOps pipeline to deploy a static website
Provisioned half the CNCF landscape so one bash script could run with a sidecar and GitOps - congratulations, we invented enterprise cron
Bash: because who needs a Kubernetes cluster when 'for i in *; do ...' scales to prod?
Dragging in Kubernetes, Istio, KEDA, Prometheus and Helm to solve a cronjob is peak platform energy; a 12‑line bash with set -euo pipefail and a systemd timer would’ve shipped yesterday
To be honest, pure shell scripts are rare - they always rely on many external utilities. Comment deleted
For anything more than the simplest use cases I would generally prefer to build a tool in C++ or Java. But for simple things bash is great, though honestly I'd prefer powershell for scripting, even if there's some really stupid quirks in powershell. Comment deleted
Powershell is fairly sensible language core (I see hints of ML in there) trying to wrap a dozen incompatible and incoherent ways MS came up with to componentize code and provide interfaces, efectivelly becoming yet another competing way to do things with impedance mismatches all over increasing the overall complexity. I wish unix shells had less footguns but obviously this is not the way. Comment deleted
unix shells have footguns? Comment deleted
Well, the whole error handling thing is PITA, the way parameter expansions work is generally not what you want (though zsh fixes that for most part, though not completely), and there's lot of tedium in general in making sure the things you are passing around really are what you think they are. Comment deleted
I do generally have a much better time dealing with zsh than bash, but it also seems like it's got some performance overhead. Comment deleted
What are you doing with shell that you need to fine-tune it's performance? Comment deleted
I dont need to, it's just something I've noticed. Comment deleted
I've noticed people having issues with random scripts from the internet supposed to increase the bling of your prompt and such (usually of questionable quality) Outside of that and calling external tools like in vcs_info I don't see difference interactively. I'd suspect that for running POSIX sh scripts it might be not as fast (I'd probably use mksh for that) but those do a lot of work with external tools for which zsh has builtins and proper data structures, so actual rewrites run way faster IME. But I can't really recall using any too intensive scripts lately. Comment deleted
My biggest complaints are how non-class functions output basically everything in one big mess, and how loops have inconsistent syntax. For example, in a for loop a continue statement functions like you'd expect in any other language, but in a foreach-object loop a continue statement functions like a break. It's dumb, they should be consistent. Comment deleted
aight, but those aren't really footguns, just generally bad design, no? Comment deleted
Bad design is exactly what I'm complaining about. Comment deleted
fair Comment deleted
Would F# work for you instead? I don't know how easy it's to use it as a script / REPL but in concept it feels quite close to what PS wanted to be while being programming language with some actual design. Comment deleted
The syntax annoyance is pretty minor, it's just a gotcha you've got to be aware of. The non-class function issue is resolved by only using class functions unless you really need to do otherwise. Class functions also have the added benefit of types. Comment deleted
I think it is possible to replace KEDA and Helm by bash scripts, but whole K8s? And how to replace Docker? Comment deleted
I do my cobntainers with mix of unshare, execline scripts and patched s6 (because CLONE_PIDNS semantics are braindead). For more turnkey component you may use runc. Comment deleted
ha ha serverless.yaml go brr Comment deleted