Comment by dvcrn | Hacker News Reader

Comment by dvcrn | Hacker News Reader

Parent Full thread

Why not take the initial complexity cost and learn k8s and containerization? That's what I've been doing as a step-up from Heroku and have been very happy with it.

My project currently runs on Digitalocean managed k8s and setting it up really wasn't hard. I had everything already in containers for dev/prod anyway, and having those run on k8s just meant I had to write the deployment manifests that pull the containers and setup the pods.

What I love about managed k8s (and also shared a couple times in comments on HN) is that it's separated from the servers below. I can have 20 containers (that can be separate things all-together) running on the cheapest Droplet and would only pay whatever that droplet costs, so under $20. Then when I need more power, I just scale the Droplets used for the k8s cluster and my pods/containers get shoveled around the available resources automatically.

I liked this approach so much that I now have a private 'personal projects cluster' that runs on digitalocean with the cheapest/weakest droplet avvailable, and whenver I have a small hobby project that needs to be hosted somewhere, I just add that container to the k8s cluster and be done with it.

I’m waiting for digital ocean to have something like google cloud run.

Google cloud run is essentially here is a docker image that listens on the $PORT env variable. Spin it up when you get requests. It will handle X queries per second (you can set limit). If more than X, scale it up to this many replicas.

I pay about 10 cents for my site. Zero maintenance. I push code to GitHub, GitHub builds an image, pushes to GCR and tells cloud run to use new image.

This is how things ought to work for simple web server like functionality. “Here’s a dockerfile and source tree, build it, run it and auto scale it with this https domain” Boom!

What sort of cold start time do you get with that out of interest?

Not sure about exact numbers on the cold start but we avoid it altogether with a keep-warm request every minute.

Makes sense, and the 10 cents in your above comment is literal with a keep-warm every minute? That's pretty solid!

Even with no cron, it was <500ms cold start. With a cron that hit every 5 mins, I saw less <100ms to hit US central and back (from Seattle).

I pay 10 cents a month to google. They have no shame charging me 3 cents on my credit card.

Why not take the initial complexity cost and learn k8s and containerization?

I would argue that the complexity cost is ongoing not just front loaded. There is an overhead for every new application. For instance putting it in a Docker image, deploying it using gitops flavour of the month and then any extra policy management and routing.

> Why not take the initial complexity cost and learn k8s and containerization?

Security, OS patches, maintaince and more than anything DDOS attacks. I don't want to handle all that, I just want to concentrate on development not maintaince.

Managed k8s offerings usually take care of everything below the k8s API. Our GKEs auto-upgrade their control plane and the worker nodes, both OS and k8s versions. I could force my way onto the workers via SSH if I really wanted to, but by default I can't even get on those machines. All you ever do yourself is kubectl this, kubectl that. I believe DO's k8s offering is like that as well.

You're still self-hosting, just on top of k8s rather than on top of VMs. All the ingress is your problem, logging, monitoring...

It's only managed in the same way that AWS Elastic Beanstalk is managed.

This is always great until there is a bug somewhere in the infr layer. Then having k8s is no longer such a good idea.

A non tech person could say the same about having an "app" at all.

True, but at while later of “tech” is useful to you? I often solve problems with only google sheets. Why bother with an app if you don’t need it. Same for other layers of “infra”.

Reply on news.ycombinator.com