Select Page

So many clients of mine tend to start with Kubernetes (K8s) whether it be in AWS, GCP, or some hand-baked thing on EC2s. Overall most startups don’t need a full-blown K8s solution. There is rarely a need to be multi-cloud and generally, it is something that just causes more unnecessary work and causes a bloated DevOps department.

Starting simple with something like Fly.IO, Fargate, or Cloud Run. These are all solutions that still run in the cloud and can reduce the amount of management that is necessary in order to run various services. This can allow for a highly resilient system to exist while not requiring a massive DevOps group to manage it and keep everything up to date.

Many times I have found that even as a company begins to scale this still tends to be a viable solution for them. This allows a very elastic scaling with very little in the way to prevent it from scaling.

Cost Differences

Overall there are some major cost differences that can happen. With a single node GKE cluster you are looking at between $100 and $250 per month in Cloud Cost just for the cluster. From there you then have to consider any maintenance cost that might have to happen.

With Fly.IO for a monolithic API and simple Postgres Database this same setup can fit within their Free Tier. This would allow the initial deployment to operate in a very cost-effective manner.


Within Kubernetes there is the continual need to upgrade systems and ensure that any patches are applied. There are also regular updates to the Kubernetes layer that has to be applied.

Using something like Fly.IO, Fargate, or Cloud Run removes a lot of the system management component that exists. It allows you to focus on your app development rather than having to fix little small problems.

When to use Kubernetes

Ultimately being a very big fan of Kubernetes personally there are absolutely times that is should be used. If you are preferring to deploy into a Datacenter rack rather than the cloud this could be a fantastic opportunity to leverage K8s. The other side would be if there is a need to be more multi-cloud and wanting to generalize deployments rather than having to create totally separate deployments.