A Different Way to Think About Deploying Containers

This X thread begins with a big win:

​You dockerized your entire app. Your Node API, your React frontend, your Postgres DB all neatly packaged. Your docker-compose file brings it all up perfectly on your machine. You feel like a genius.

Then it talks about how reality hits when it’s time to run the same stack in production. Suddenly you need reliability, and scaling across multiple machines. You start asking questions you never considered during local development. Questions about service discovery, resilience, rolling updates, and all kinds of other stuff. So... what is the proposed solution?

Kubernetes

The post proposes Kubernetes as a solution to all these problems when deploying containers. For those of you who don’t spend your time in the devops trenches, here’s a quick breakdown of what Kubernetes (often referred to as k8s) is and what it does. K8s is referred to as an orchestrator: it takes care of scheduling containers across many different machines in different configurations, moving them around when necessary, and making sure they’re running properly. It helps handle things like horizontal scaling, making sure containers have adequate resources, handling networking, and more.

To get to a working deployment of the proposed app, though, you would probably need to learn at least a dozen different k8s concepts. Here’s a short list of what you might need: a Deployment to describe Pods in a ReplicaSet along with a Service, Ingress and Ingress Controller to hook up your domain. Helm to install Cert Manager so you can get SSL working. You’ll likely need to learn about plenty more along the way.

Something you’ll noticed in the original post is that the author doesn’t mention the Postgres service from his app. That’s because in the majority of cases, it’s best to use the managed data stores offered by the cloud provider.

One last note about Kubernetes is that despite it feeling like “standard” tooling that lays on top of cloud infrastructure, you have to keep in mind that each k8s distribution has quirks. So some thing in EKS might not work the same way in GKE, AKS, or DOKS. That means it’s not going to be your silver bullet to writing once and then deploying to different cloud accounts (i.e. if you need to deploy to your customers’ accounts).

A Different Approach: Defang

One of the key things to keep in mind about Kubernetes is that a lot of k8s concepts map onto underlying cloud infrastructure. For example, creating a Service in your k8s cluster may provision a load balancer in your cloud (outside your cluster). It’s not a 1-to-1 relationship, but it’s often necessary to understand. The real point is that it’s hugely complex, and to do it properly, you have to learn essentially as much as if you did a full cloud certification.

At Defang, our approach to the original post’s problem is different. Docker Compose is more of a logical description of your application, expressing relationships between services, what’s exposed, etc. Our tool takes a standard Docker Compose file and turns it into cloud‑native infrastructure on AWS or GCP based on some parameters. So when you’re ready to deploy, instead of typing your usual docker compose up, you can type defang compose up and be up and running in the cloud in minutes.

That command provisions the necessary compute resources, networking, load balancers, and more directly in your cloud account. It will also provision managed data stores using your cloud’s managed services, including Postgres, Redis, and MongoDB. The Defang CLI will also help you manage encrypted configuration like API keys properly.

Extras for AI Developers

Beyond all that, our tooling comes with features that machine‑learning and AI developers might appreciate. For example, it offers easy integration with AWS Bedrock and Google Vertex AI, streamlining workflows that rely on those services.

Conclusion

​In the end, Kubernetes has its place. It provides powerful primitives and is the right choice for certain types of organizations and workloads. It’s particularly useful when you need to orchestrate complex distributed systems that need special permissions or require an understanding of the specific compute environment, etc.

However, if your application can be accurately described by a Docker Compose file and is architected according to 12 Factor principles, a Compose file is likely sufficient. In those cases, using Defang is likely the easiest way to get a secure, scalable deployment without investing in a full Kubernetes setup. If you’re feeling overwhelmed by the never ending flexibility and complexity of k8s when you’re deploying containers, Defang might be worth checking out.