I previously wrote about Hyper.sh as a nice step-up from Docker Compose: a good way to deploy an environment that is working as a Compose file without learning new orchestration tech. That still holds true, but after the experience of trying to make my deployment more robust on Hyper.sh, I’ve arrived at an important caveat: unless you’re in production.
Hyper.sh was great for experimentation and getting a cluster of containers up quickly. However, I ended up experiencing a number of instances where the service behaved inconsistently. I ran into more and more cases where it seemed like their basic building blocks were missing the features and glue to smoothly roll out a complex solution.
So my message to past-me is: just learn Kubernetes. Yes, there is a bunch of vocabulary to learn. There’s a learning curve. But I quickly found that it had the answers to my orchestration problems, where Hyper.sh or Docker Compose presented mostly limitations. Pretty early on it was clear how much more polished and robust Kubernetes was for solving the problems I had.
I also recommend working with Helm. Kubernetes feels weird because it’s an API that mostly communicates in terms of resources declared in YAML files. Helm provides a templating engine around those YAML files and commands that provide the procedural/operational logic that isn’t totally obvious when working directly with kubectl.
Plus, examining existing Helm Charts off the shelf is a great way to see how the pieces of the puzzle fit together.