Run One Big App
What is a large app: It’s either one that needs the scale, eg. because you are in the lucky positon of having many customers. It’s also an app you have built with the help of pre-existing building blocks that you cannot compile in, but run separately. I have made large efforts to get a (Python) app down to almost nothing. This is not as easy as it sounds, as with the long-wait AI you need non-blocking, background processing, often in multiple channels, CPU bound (eg. image transcoding) and external service latency bound (AI APIs), you might want an LLM Gateway, MCP Gateway to keep external secrets away from agents, you need Redis, and of course a database. Large apps can be small with apps that need many moving parts. This is where Kubernetes shines. Once you (or your agent) has setup the a working deployment, you can manage and update it quite easily. This will make you more willing to try new things out, to build an app that integrates other things that you don’t need to build on your own.
What the platform gives you
Any big app needs multiple stages. You can separate them with node pools and namespaces, but then you still share the same control plane. With Gardener, clusters are cheap, can be even cheaper when ephemeral, and you will soon realize, that you really don’t want to live without a staging cluster, anymore. You don’t need to fear updates of any kind, anymore. Just think about this!
What your app should bring
The platform handles the infrastructure layer. Your application has to meet it halfway to even be deployable. With some extra work you can make it easy to observe and maybe even self-healing.
Package as a container
Your application runs as a container image. Enough said.
Be stateless
You can run single replicas, but then there will be downtimes, eg. on node upgrades and app upgrades. If you want to get rid of this, you need at least 2 replicas. The app must be able to deal with it and it generally means: The app itself is stateless and only uses stateful other things like databases or cloud storage.
Have good health and readiness probes
A liveness probe that always returns 200 when it’s up, even when the database it depends on is down, means Kubernetes cannot see that your app is not healthy and ready to serve traffic. Thankfully, agents are really good at writing these things.
Be configurable from the outside
Your app should not bake in things that need to be variable. Configuration belongs in ConfigMaps and Secrets. This is standard best practice even before the twelve-factor manifesto was a thing and maybe thanks to that, the agents are really good at writing apps and Dockerfiles that meet these requirements.