I think that “modern” shrink-wrapped software (Helm Charts) is like fast food. It takes only a couple of seconds to eat (deploy), but isn’t a long-term healthy thing to do.
Not all Helm Charts are like this. I’m specifically talking about any Helm Chart that’s big enough to include other Helm Charts. I’m going to pick on Wordpress as the example in this blog post.
Why Are Helm Charts Fast Food, Exactly?
The allure of this Wordpress Helm Chart is strong.
Look at this single command:
helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress
What does this command actually do? A lot of stuff:
- A WordPress deployment running version 6.8.1 in containers based on Debian 12
- A complete MariaDB database deployment as a dependent Helm chart
- Memcached included (optional) as a dependent Helm chart
- Multiple Kubernetes secrets for storing passwords and configuration
- Persistent volume claims (PVCs) for both WordPress and MariaDB data
- Kubernetes Services for accessing WordPress and its database
- Ingress resources for external access
- ConfigMaps for Apache and WordPress configuration
- NetworkPolicies for security
- ServiceAccount for permissions
- Optional HorizontalPodAutoscaler and PodDisruptionBudget for scaling and availability
- Monitoring resources including ServiceMonitor for Prometheus integration
All of this is templated with a common library chart that provides reusable components across Bitnami charts. The chart includes over 20 template files and a values.yaml with HUNDREDS of configurable options. This is the “value meal” of cloud native applications - everything bundled together for convenience. Heck I’m surprised they didn’t throw in the Prometheus too.
But wait, setting up this Wordpress Helm Chart would save an operator hours of configuring Kubernetes. What is the problem?
It Isn’t Just Helm
Helm is popular, but there are lots of ways to shove yaml you didn’t read into your k8s cluster and watch it go.
Take for example the docs on how to install Kueue.
Only 13,880 lines of yaml:
curl -s -L https://github.com/kubernetes-sigs/kueue/releases/download/v0.13.1/manifests.yaml | wc -l
13880
If those were calories, it would be about 24 Big Macs.
Fast Food Has Its Place
Just like fast food, comprehensive Helm Charts absolutely have their place in the ecosystem. If you are hungry and need something quick, by all means install this fast Helm Chart.
But just as you wouldn’t build your entire diet around fast food, you shouldn’t build your entire production infrastructure on complex, nested Helm Charts. The convenience comes with hidden costs: troubleshooting complexity, upgrade challenges, and security implications of running more components than you actually need.
For example, while it sounds great that you can install this chart and get a database up in seconds, is that really how you want to run a database… in production?
Trick question. After installing that database Helm chart, you probably have no idea how it is running.
The “Illusion” Of Shrink-Wrapped Software
My main point here is that this class of software packaging gives the illusion of robustness. You don’t see how the sausage is made, it looks safe and appetizing.
Why wouldn’t you want to install Wordpress this way?
Day 1 vs Day 2 Operations
These charts highlight the fundamental tension between Day 1 and Day 2 operations in cloud native environments.
Day 1 is when the fast food Helm Chart shines - you’re hungry (need a deployment), you order (run helm install), and within minutes you’re eating (application is running). The immediate gratification is undeniable.
But then comes Day 2 - the ongoing maintenance, updates, troubleshooting, and scaling that make up the majority of an application’s lifecycle. This is where the fast food approach starts to show its limitations. When you need to upgrade just one component, or when a security vulnerability affects a specific dependency, you’re often forced to deal with the entire bundle.
Day 2 is when things break. I just don’t want to be on-call for this helm chart on day 2.
But Kyle, Is This Really Any Different Than Linux System Packages?
In some ways, YES!
Just like one would not (realistically) run apt install wordpress and expect to have a robust system.
For Day 2, you are going to need to know how to keep that Wordpress install up to date, deal with backups, handle changes in requirements.
But in other ways, NO!
System packages usually don’t presume to pull in the kitchen sink. Mostly they expect that there is a sysadmin behind the wheel who has an idea on how they actually want to tie all the pieces together.
I think the more fundamental difference is that Linux system packages really are a transport for files, maybe some running services. K8s yaml is very much about a running distributed system.
Is This Abstraction? Or Is It Just Packaging?
Helm Charts: are they truly abstractions, or are they just packaging?
I argue that Helm Charts are NOT abstractions at all. They are just bundling YAML together. I dare say they are actually unintentionally obfuscating how things actually work.
And the YAML isn’t exactly helping.
Why do you think all these Helm charts have hundreds of parameters?
This isn’t exactly like a library function in a piece of code with inputs and outputs. This is a real distributed system with LOTS of moving parts.
In the Kubernetes case, I argue that you really do need to understand those parts if you are going to run Wordpress in a production environment. In the code library case, you usually do not (99% of the time).
So What Are We Supposed To Do? Decompose These Charts And Remake Them?
I think so yes.
Day 1? Sure, install Helm Chart in a test environment to see what you want.
Day 2? Install Wordpress in a more sustainable way. With individual components that you understand. With storage, networking, databases, caching, and ingress, all done in an idiomatic way for your environment.
Am I So Out Of Touch? No, It’s The Children Who Are Wrong.
I actually do think I’m wrong, just not wrong yet.
These still feel like early days, where the industry is still trying to figure out what the next level of abstraction is supposed to look like.
Something similar happened with configuration management tools (Chef/Puppet/Ansible/Salt), but eventually the community was established and things stabilized.
For Puppet, The Puppet Forge centralized modules and Vox Pupuli stepped up and maintains the majority of the popular modules. Chef has something simlar with Sous Chefs in the Chef Supermarket.
With Kubernetes, there is no first-party package manager. Helm is just the de facto standard. Perhaps Kubernetes 2.0 will come with a native package manager.
Then, just like the Configuration Management camp, using community modules may not be so insane.
Till then, I’m going to remain skeptical at any k8s application tutorial that advertises that I can get system running in seconds.
Comment via email