Setting up Kubernetes is a fixed cost in the beginning with clear payoffs. Things like microk8s, Rancher or GKE/EKS make it a lot easier to set up than it used to be. Deploying your app is then just a simple Helm chart, or another way of getting deployments out. If I was running any kind of business that was making more than zero dollars I would absolutely go with Kubernetes. I don't think it's as complicated as people think at any rate, and it lets you use premade Helm charts which can simplify the deployment of things like Clickhouse.
No it's not, assuming your database sits outside k8s there's absolutely nothing that needs to be fit inside k8s, a simple machine running docker if needed is more than sufficient.
K8s is such a huge mental overhead that if it's not already naturally in your head because you've had extensive experience (or apparently born geniuses) no one with limited tech budget should ever do this.
All of these tools (Terraform, Kubernetes, Github Actions/Other CI) seem like overkill until a node dies and you need to recreate it, or configuration gets messed up and you don't remember how you deployed it in the first place. It sounds like the OP has had experience with these problems. If these aren't problems you have interest in solving, then Heroku or a similar platform would be the way to go.
Running a business on a single node is not advisable. If your scale is that small, or uptime doesn't matter, then sure go with that. If you're running on multiple nodes, you're going to need a way to schedule containers to your cluster one way or another. Scheduling and orchestrating is where complexity get introduced - Kubernetes wrangles this complexity.
You can run a lot on a $5 server. I would probably run 3 $10 servers for a small business at least, which feels like still within the realm of a cheap budget for business infrastructure costs.
As far as Kubernetes complexity goes, I think this is a self-perpetuating idea on internet tech communities. I don't think it compares to the complexity of actually programming the web apps themselves. There's like 6 resource types you have to be familiar with to work with Kubernetes, and most of that will just be Deployments (where containers actually get scheduled and run, health checks, etc). The others are for configuration and routing.
I have had significantly better uptime with my production dashboard app running on an EC2 instance that has been up and running for 3 years straight, than every other team I am aware of that uses kubernetes. The more complexity you add, the worse things get.
Of course, you can't most of the time run production apps on a single machine, but my general approach has been to add the least amount of infra overhead - in our case it has been elastic beanstalk. It has been reliabile and zero touch for us for years now. I have heard of some people saying EB is good till it works and when it doesn't you're screwed - my backup plan for that case is to continue keeping that EC2 instance running, and generally make sure you can run your app without too much hassle in a fundamentally different stack at any given time.
In the end, by depending on RDS and EB we have never had to worry about infra or scaling in our team. This is in stark contrast to every other team I've seen or worked with, where upgrading your eks version, or certificates expiring or etcd getting unresponsive or environment variables leaking between multiple prod and stage or someone accidentally deploying to prod because they didn't specify the correct name space in their deploy script or a hundred other reasons made their k8s deployment a nightmare. You can argue that this is a sign of bad training or practice, but I'm working with the same engineers on this stack that's so much more foolproof so when can we start blaming the tool a bit as well?
> configuration gets messed up and you don't remember how you deployed it in the first place
Configuration getting messed up sounds more like a k8s problem than anything else. In any case, if you aren't using git and don't know how to at least back things up you really should be asking yourself if a tech company is right for you, as a one man/woman operation. There are countless other ways to make money online. Etsy, Craigslist, Shopify, etc.
> until a node dies and you need to recreate it
The way to solve both of these problems on a single node operation is to create a snapshot/clone of your machine. At that point you would really just need to worry about the IP address changing and/or updating DNS when restoring the image. The best part is you can take this "master" copy and deploy it as a staging server. Or even horizontally scale by throwing a load balancer on top. You can even get your VM exactly how you want it locally and then deploy it to DO, Linode, Vultr or whatever.
> Configuration getting messed up sounds more like a k8s problem than anything else. In any case, if you aren't using git and don't know how to at least back things up you really should be asking yourself if a tech company is right for you, as a one man/woman operation. There are countless other ways to make money online. Etsy, Craigslist, Shopify, etc.
I don't know if this was to intended to directed at me, but all of the tools mentioned imply using them with git or other version control, hence Github actions / CI. Kubernetes does not spontaneously mess up your configuration, well intentioned developers do. Willingness to learn new-ish technology puts you in a much better standing for running a tech business.
The snapshot/restore method is fine if you don't plan on updating very often, but this isn't a good alternative to infrastructure as code. I would make a base image that bootstraps your node to a cluster in Packer and then hand off all the deployment of nodes/DNS/Loadbalancer wiring in Terraform. Then just snapshot your database volumes as normal and deploy with your orchestration.
