What constitutes knowing k8s well enough for it to be a net positive at a startup?
For example in my mind, whether I tie a bunch of services and a database or cache together on a virtual machine with Terraform, Docker Compose, or k8s yaml (or kustomize or helm charts or whatever), where do the k8s benefits come from beyond that? To me my use case seems entry level/basic, but I'm not sure where the more advanced features come into play.
Its not even necessarily that you know k8s. Its more that you know and understand the underlying ops principles / components. K8s is just a formalized layer of putting those together. So, if you can do all teh things in AWS that k8s provides for you, e.g. know when/why to setup a load balancer, or blob storage, or network storage, or domain routing, etc, then k8s lets you do those things in a more efficient way.
Bonus points if you wrap it with something like pulumi, because now as a solo dev you can massively leverage your knowledge to be able to handle a massive amount of ops while keeping up with app development.
> e.g. know when/why to setup a load balancer, or blob storage, or network storage, or domain routing
When it comes to performance and cost, I've been able to basically get a $100/mo OVH dedicated server and do everything I need on that.
I obviously understand why somebody might need blob storage, load balancers, etc.
I just haven't ran into the use case I guess? I once worked on a project where like 80 people during peak hours needed to do some relatively "write heavy" stuff to an API (1 row per scan of a barcode per like 500 orders a day for an e-commerce site)
Yeah I mean if you are aiming to optimize for running on single node clusters then something that is first and foremost an efficient bin-packer isn't a great fit. I'm also assuming the alternative is running on the cloud rather than a colo/dedicated server.
EDIT: to be clear K8s is not good for "POC" phase of development. Its definitely good for "ok this is a worthwhile product and we are now officially building this out for production".
I guess a better question is, how far can a single node get you performance wise (I guess you have to ignore disaster recovery/automatic rollover based on regions) without needing k8s? Like, "really far"? What's a good rule of thumb on when you should introduce k8s?
Its highly variable based on the specific workloads. Its going to be bottle-neck based. Thats different for everyone. And again, for moving from dedicated to non-dedicated its more of a cloud vs raw metal consideration. K8s is a "better" way to do cloud for most of the use-cases we are debating in this comment section.
devil's advocate but couldn't you technically (if you were trying to keep an entire software business's cost under say... $500/mo) run k8s (or k3s or whatever) in a production setting on a single node "raw metal"?
i know that's frowned upon but, i feel like performance/dollar comparsion, moving it to the cloud + k8s gets wildly more expensive quickly?
For example in my mind, whether I tie a bunch of services and a database or cache together on a virtual machine with Terraform, Docker Compose, or k8s yaml (or kustomize or helm charts or whatever), where do the k8s benefits come from beyond that? To me my use case seems entry level/basic, but I'm not sure where the more advanced features come into play.