3 ms·

K8s is overkill though. Google cloud run gives you the good bits with less work and it's still reasonably priced. Azure container apps in theory should be sim

K8s is overkill though. Google cloud run gives you the good bits with less work and it's still reasonably priced. Azure container apps in theory should be similarly good, but it's kind of buggy and poorly engineered.

qeternity 2y ago
Why do you say it's overkill? Why do people think k8s (or k3s) is some impossible monster? Have you deployed and managed k8s before? What did you find more complicated than learning the ins and outs of the cloud variants?
- CuriouslyC 2y ago
  I'm not saying it's an impossible monster but I can setup and deploy a project from scratch with cloud run in ~5 gcloud cli commands while being somewhat protected from my own ignorance.
  - mitjam 2y ago
    Caution: Working with CloudRun with ignorance on any level can lead to very large bills: https://news.ycombinator.com/item?id=25372336 https://news.ycombinator.com/item?id=25372336 - The article discussed there is a good cautionary tale: https://archive.is/D5qc8 https://archive.is/D5qc8 - I prefer to explore and experiment on a less scalable solution which is usually also less scalable in terms of costs.
- dinkleberg 2y ago
  In my experience, people who think k8s is really hard to user are either: a) someone who had k8s forced on them without getting a chance to learn it (or had no interest in the first place) and was stuck with its complexity, or b) has never actually used k8s and is just parroting what they've heard. The former situation does suck. K8s is amazing and once you understand it, it is easy to work with. But if you haven't learned the concepts and core resources, it will definitely appear as a black box with a ton of complexity. But I think for many of us who have used Kubernetes a lot, it is a no-brainer in a lot of situations as it doesn't matter which cloud provider you're using (for the most part), you get a common and familiar interface.
  - qeternity 2y ago
    I usually find that it's B. The number of professional programmers who don't have the slightest clue how a database actually works, much less the ability to just spin up a container containing one, is shocking.
    - dinkleberg 2y ago
      Sadly I think that extends to most people about most things. I’m certainly guilty of stating something I’ve heard but don’t actually know from time to time (though I do make a conscious effort not to). It is funny (or depressing, depending on your point of view) to catch people doing this by asking them when was the last time they did X or how they know whatever they’ve stated and then seeing the gears turn.
- EuAndreh 2y ago
  From the fact that the LoC count of the implementation is beyond "millions". How about this equivalence: I appreciate how extremely sophisticated GCC is, and the very well optimized output it generates. It is still is 100x more complex internally (and thus, error prone, buggy, more complex to modify when needed) than TinyCC, for instance.
  - qeternity 2y ago
    Um, ok. I think you're massively underestimating the LoC of the services mentioned (I would bet significant sums that cumulatively it would exceed a basic k8s deploy). I'm also not really sure what the relevance of LoC here is though? The Linux Kernel is a large codebase...but surely you don't object to using that?
victor106 2y ago
> Azure container apps in theory should be similarly good, but it's kind of buggy and poorly engineered. 100% agree. At a mega corp they were mandated to use Azure(worst decision) and we choose Azure container apps. Nothing worked: from the deployment ARM templates to scalability. It was a disaster. This was after we had the highest level of support from Azure. The engineer working with us in this almost admitted this shouldn’t have been released in it’s current form. I can’t for the life of me understand how Microsoft releases such products!!!
mitjam 2y ago
CloudRun with Django works well, but for a complete setup, you need to configure, manage and pay other services, too, like Cloud SQL for PostgreSQL, Memorystore for Redis, API Gateway, Observability, Cloud Build, Artefact Registry, Cloud Key Management, IAM, Pub/Sub, CDN, and Cloud Storage. When you have a live service, you probably also want to pay for Google Cloud Customer Care. The same is true for AWS and Azure. Depending on training and experience, it may be easier to setup a GCP than a Kubernetes based solution, but it's still not exactly trivial. And, once a fitting Kubernetes platform is up and running, it's almost trivial to add new services, as the article describes. I think, even in 2024, and even for a one-person business like the authors', starting with Kubernetes is not a bad decision. I'm currently building my own Kubernetes based platform, but on a less expensive service (Hetzner Cloud). I use a separate single-node Kubernetes "cluster" with Rancher for management, and ArgoCD for continuous deployment from git. Currently I only have a single-node "playground" cluster up and running for my "playground" workloads, to save costs, but I will upgrade this to a proper HA cluster before a service goes live. Later, I can still upgrade to GCP, or in my case probably Azure. Until then, I don't need to worry about large cloud bills, which is also a good thing.

qeternity 2y ago

Why do you say it's overkill? Why do people think k8s (or k3s) is some impossible monster? Have you deployed and managed k8s before? What did you find more complicated than learning the ins and outs of the cloud variants?

CuriouslyC 2y ago
I'm not saying it's an impossible monster but I can setup and deploy a project from scratch with cloud run in ~5 gcloud cli commands while being somewhat protected from my own ignorance.
- mitjam 2y ago
  Caution: Working with CloudRun with ignorance on any level can lead to very large bills: https://news.ycombinator.com/item?id=25372336 https://news.ycombinator.com/item?id=25372336 - The article discussed there is a good cautionary tale: https://archive.is/D5qc8 https://archive.is/D5qc8 - I prefer to explore and experiment on a less scalable solution which is usually also less scalable in terms of costs.
dinkleberg 2y ago
In my experience, people who think k8s is really hard to user are either: a) someone who had k8s forced on them without getting a chance to learn it (or had no interest in the first place) and was stuck with its complexity, or b) has never actually used k8s and is just parroting what they've heard. The former situation does suck. K8s is amazing and once you understand it, it is easy to work with. But if you haven't learned the concepts and core resources, it will definitely appear as a black box with a ton of complexity. But I think for many of us who have used Kubernetes a lot, it is a no-brainer in a lot of situations as it doesn't matter which cloud provider you're using (for the most part), you get a common and familiar interface.
- qeternity 2y ago
  I usually find that it's B. The number of professional programmers who don't have the slightest clue how a database actually works, much less the ability to just spin up a container containing one, is shocking.
  - dinkleberg 2y ago
    Sadly I think that extends to most people about most things. I’m certainly guilty of stating something I’ve heard but don’t actually know from time to time (though I do make a conscious effort not to). It is funny (or depressing, depending on your point of view) to catch people doing this by asking them when was the last time they did X or how they know whatever they’ve stated and then seeing the gears turn.
EuAndreh 2y ago
From the fact that the LoC count of the implementation is beyond "millions". How about this equivalence: I appreciate how extremely sophisticated GCC is, and the very well optimized output it generates. It is still is 100x more complex internally (and thus, error prone, buggy, more complex to modify when needed) than TinyCC, for instance.
- qeternity 2y ago
  Um, ok. I think you're massively underestimating the LoC of the services mentioned (I would bet significant sums that cumulatively it would exceed a basic k8s deploy). I'm also not really sure what the relevance of LoC here is though? The Linux Kernel is a large codebase...but surely you don't object to using that?

victor106 2y ago

> Azure container apps in theory should be similarly good, but it's kind of buggy and poorly engineered. 100% agree. At a mega corp they were mandated to use Azure(worst decision) and we choose Azure container apps. Nothing worked: from the deployment ARM templates to scalability. It was a disaster. This was after we had the highest level of support from Azure. The engineer working with us in this almost admitted this shouldn’t have been released in it’s current form. I can’t for the life of me understand how Microsoft releases such products!!!

mitjam 2y ago

CloudRun with Django works well, but for a complete setup, you need to configure, manage and pay other services, too, like Cloud SQL for PostgreSQL, Memorystore for Redis, API Gateway, Observability, Cloud Build, Artefact Registry, Cloud Key Management, IAM, Pub/Sub, CDN, and Cloud Storage. When you have a live service, you probably also want to pay for Google Cloud Customer Care. The same is true for AWS and Azure. Depending on training and experience, it may be easier to setup a GCP than a Kubernetes based solution, but it's still not exactly trivial. And, once a fitting Kubernetes platform is up and running, it's almost trivial to add new services, as the article describes. I think, even in 2024, and even for a one-person business like the authors', starting with Kubernetes is not a bad decision. I'm currently building my own Kubernetes based platform, but on a less expensive service (Hetzner Cloud). I use a separate single-node Kubernetes "cluster" with Rancher for management, and ArgoCD for continuous deployment from git. Currently I only have a single-node "playground" cluster up and running for my "playground" workloads, to save costs, but I will upgrade this to a proper HA cluster before a service goes live. Later, I can still upgrade to GCP, or in my case probably Azure. Until then, I don't need to worry about large cloud bills, which is also a good thing.