3 ms·

Reasonable-ish counter concerns but way overinflated in each case & loses it's persuasiveness by trying overhard to sell fear. Plenty of people run their etcd

Reasonable-ish counter concerns but way overinflated in each case & loses it's persuasiveness by trying overhard to sell fear. Plenty of people run their etcd on their control plane. If you are indeed a startup you might even consider not having dedicated control plane nodes. The idea of side-cars taking up another 100% more resources is perposterous, absurd. Running ingress takes up some overhead, but it also allows you to consider running a wholeot less load balancers if you have multiple services, letting kube do all the routing; this can save a good chunk of change on infra costs if you go for it. Things like errors devops, ci/cd are presented in the scariest possible terms. But it's not like these are non-issues without kubernetes. I've seen man-year of time go by building AWS Beanstalk and AWS ECS scripts, just to deploy stuff (build wasn't any better!). There's such a universe of mature & solid tools for Kubernetes that encompass a much more end-to-end handling. Plenty of gitops starter kits. Many of these you can try out in a day or less, see if you like the look & feel. And abandon and swap-out just as quickly. There's a much better base of options here than there is anywhere else.

asciii 4y ago
I also read the author's other article [0] and it seems that they are encountering engineers / teams who have not answered why they chose Kubernetes versus others options. Any initial project will have some legwork before any gets productive on it. > Reasonable-ish counter concerns but way overinflated in each case & loses it's persuasiveness by trying overhard to sell fear. My buddy uses K8s at their company for many clients(while they are small to medium sized) and they aggressively screen for the best engineers who can cut through the mud quickly and be productive with containers, Kubernetes, logging, etc. So it can work if the engineering are able to say No and work with the tools / expertise they have. [0]: https://thetechtrailblazer.blog/2023/02/14/dont-build-microservices-but-if-you-must-then-build-services/ https://thetechtrailblazer.blog/2023/02/14/dont-build-micros...
msm_ 4y ago
> Plenty of people run their etcd on their control plane. If you are indeed a startup you might even consider not having dedicated control plane nodes. The idea of side-cars taking up another 100% more resources is perposterous, absurd. I run my personal blog using k8s on a single-node "cluster" with a low-end VPS server [0]. So when I hear how hard and expensive it is to host k8s I die inside a little. This actually lets me save money, because when I find a better/cheaper server I just migrate: I copy my data files, install k8s, apply my yaml, and I'm done with the migration of my 20+ hosted services in less than an hour. [0]: Yes, this is obviously an overkill, I wanted to have some personal playground for k8s. And I like how clean my server is thanks to containerising everything.
- rektide 4y ago
  I too have been running single node k8s on tiny $5/mo vps and it works fine. Less than 500MB ram used for k3s. It also takes unbelievably little effort & is remarkably secure & useful out of the box. There's no intra-cluster permissions setup, but if you're a startup & especially if most devs are leveraging paved-road tools or gitops for ci/cd, maybe just trusting your team is enough, at least for the first years. Metrics, logging, postgres operator, lets-encrypt storage: all just worked. I had https webapps in under an hour. I did burn some significant time writing my own helm charts for dns (coredns & bind), but there were good existing options I would have been happy to use, but I wanted to learn helm & jave my specific idea done this particular way. Then my webapp had great dns integration too! As you say, the whole state of the world is pretty readily exportable & re-loadable. If someone does really goof up, as long as volumes & backups arent wiped out (often shipped to s3 compatible endpoints by many tools), it's bad & there's downtime yes, but the road to recovery can/should be incredibly fast. If you have history over time for backups, be easy enough to spot what changed that made things go bad.
brian-bk 4y ago
There's so many of these "k8s is too complex" blogs I have been thinking about where they come from. I feel like if a person strictly has an application-developer background, they just don't understand how much kubernetes has 'solved' from the time before kubernetes. Not that k8s is perfect, but they've never had to think about app runtime because ops teams helped. It can be complex if you had never finagled with webservers, config management, app segmentation, internal DNS, scaling, etc. As for trying to get at the real problem, perhaps there's room for tools that could make k8s better and understandable for these app-focused engineers (something like lens, but without stupid licensing).

asciii 4y ago

I also read the author's other article [0] and it seems that they are encountering engineers / teams who have not answered why they chose Kubernetes versus others options. Any initial project will have some legwork before any gets productive on it. > Reasonable-ish counter concerns but way overinflated in each case & loses it's persuasiveness by trying overhard to sell fear. My buddy uses K8s at their company for many clients(while they are small to medium sized) and they aggressively screen for the best engineers who can cut through the mud quickly and be productive with containers, Kubernetes, logging, etc. So it can work if the engineering are able to say No and work with the tools / expertise they have. [0]: https://thetechtrailblazer.blog/2023/02/14/dont-build-microservices-but-if-you-must-then-build-services/ https://thetechtrailblazer.blog/2023/02/14/dont-build-micros...

msm_ 4y ago

> Plenty of people run their etcd on their control plane. If you are indeed a startup you might even consider not having dedicated control plane nodes. The idea of side-cars taking up another 100% more resources is perposterous, absurd. I run my personal blog using k8s on a single-node "cluster" with a low-end VPS server [0]. So when I hear how hard and expensive it is to host k8s I die inside a little. This actually lets me save money, because when I find a better/cheaper server I just migrate: I copy my data files, install k8s, apply my yaml, and I'm done with the migration of my 20+ hosted services in less than an hour. [0]: Yes, this is obviously an overkill, I wanted to have some personal playground for k8s. And I like how clean my server is thanks to containerising everything.

rektide 4y ago
I too have been running single node k8s on tiny $5/mo vps and it works fine. Less than 500MB ram used for k3s. It also takes unbelievably little effort & is remarkably secure & useful out of the box. There's no intra-cluster permissions setup, but if you're a startup & especially if most devs are leveraging paved-road tools or gitops for ci/cd, maybe just trusting your team is enough, at least for the first years. Metrics, logging, postgres operator, lets-encrypt storage: all just worked. I had https webapps in under an hour. I did burn some significant time writing my own helm charts for dns (coredns & bind), but there were good existing options I would have been happy to use, but I wanted to learn helm & jave my specific idea done this particular way. Then my webapp had great dns integration too! As you say, the whole state of the world is pretty readily exportable & re-loadable. If someone does really goof up, as long as volumes & backups arent wiped out (often shipped to s3 compatible endpoints by many tools), it's bad & there's downtime yes, but the road to recovery can/should be incredibly fast. If you have history over time for backups, be easy enough to spot what changed that made things go bad.

brian-bk 4y ago

There's so many of these "k8s is too complex" blogs I have been thinking about where they come from. I feel like if a person strictly has an application-developer background, they just don't understand how much kubernetes has 'solved' from the time before kubernetes. Not that k8s is perfect, but they've never had to think about app runtime because ops teams helped. It can be complex if you had never finagled with webservers, config management, app segmentation, internal DNS, scaling, etc. As for trying to get at the real problem, perhaps there's room for tools that could make k8s better and understandable for these app-focused engineers (something like lens, but without stupid licensing).