Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Does Developing on Kubernetes Suck?

blog.tilt.dev

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Why Does Developing on Kubernetes Suck?

#51

Post by LaGrange »

hmottestad wrote: post #22
rooam-dev wrote: post #19

Earlier quoted context omitted.

Ability to run locally a production like setup (at smaller scale of course) is a big plus imho. 1st, you know how it works, 2nd smaller iterations/feedaback cycles (restart locally vs. push and wait for tests to run).

I agree with this. But usually you have both. A staging/test environment is nice, but if you have 5 developers and one test env then devs will quickly end up in line waiting for the test env to free up. Remote debugging is also hard. Much easier when running locally.

The idea is that you have a dev cluster _per developer_. I've ran with something similar way back working for a certain notable Perl shop way before k8s/Docker became popular, and I have to say it has a lot going for it, especially for more complex setups and more annoying database stuff. It was an (on-demand one-click provisioned) _VM_ per service per dev, though, so the biggest annoyance (no code reload, slow fs sync) was nullified by popular preference for either Vim or Emacs — with my current preference for VS Code I'd probably be annoyed by it. Also it's a bit expensive, I guess, but you can stuff a lot of VMs into a single big server.

Re: Why Does Developing on Kubernetes Suck?

#52

Post by dragonsh »

OJFord wrote: post #41
dragonsh wrote: post #30

Earlier quoted context omitted.

1. Kubernetes is when your service needs google kind of load which 90% of systems don't. Just trade it for simple VM or use LXD containers. Don't jump on next hype cycle. If something works for Google does not mean will work for you. 2. Don't spend too much on it just use traditional knowledge and, you can still use bare-metal, VM or LXD container. Focus on application not on programming a tool designed to solve prob…

> Kubernetes is when your service needs google kind of load which 90% of systems don't. This is the most frustrating but oft repeated nonsense about k8s. Kubernetes is an amazingly helpful abstraction for any amount of load on any larger than trivially tiny set of services/storage/etc. When you, like 90% of systems, don't have Google kind of load, you don't need Google number of nodes. Machine count corresponds to lo…

> Machine count corresponds to load; abstraction doesn't.

K8s is developed to manage large number of service nodes running docker or oci containers coming from Google borg project. So it was designed for managing google level of service loads. It doesn't help when a service is only for few million users with few hundred or thousand containers. LXD and traditional tools can already do it without learning new way with lots of moving parts.

Re: Why Does Developing on Kubernetes Suck?

#53

Post by tutfbhuf »

dragonsh wrote: post #52
OJFord wrote: post #41

Earlier quoted context omitted.

> Kubernetes is when your service needs google kind of load which 90% of systems don't. This is the most frustrating but oft repeated nonsense about k8s. Kubernetes is an amazingly helpful abstraction for any amount of load on any larger than trivially tiny set of services/storage/etc. When you, like 90% of systems, don't have Google kind of load, you don't need Google number of nodes. Machine count corresponds to lo…

> Machine count corresponds to load; abstraction doesn't. K8s is developed to manage large number of service nodes running docker or oci containers coming from Google borg project. So it was designed for managing google level of service loads. It doesn't help when a service is only for few million users with few hundred or thousand containers. LXD and traditional tools can already do it without learning new way with…

> It doesn't help when a service is only for few million users with few hundred or thousand containers.

Well my company switched from VMs to k8s (few hundred containers) and it helped. Proof me wrong.

Re: Why Does Developing on Kubernetes Suck?

#55

Post by oblio »

tutfbhuf wrote: post #53
dragonsh wrote: post #52

Earlier quoted context omitted.

> Machine count corresponds to load; abstraction doesn't. K8s is developed to manage large number of service nodes running docker or oci containers coming from Google borg project. So it was designed for managing google level of service loads. It doesn't help when a service is only for few million users with few hundred or thousand containers. LXD and traditional tools can already do it without learning new way with…

> It doesn't help when a service is only for few million users with few hundred or thousand containers. Well my company switched from VMs to k8s (few hundred containers) and it helped. Proof me wrong.

Do you manage Kubernetes, personally? Did you manage the VMs?

Re: Why Does Developing on Kubernetes Suck?

#56

Post by oblio »

OJFord wrote: post #41
dragonsh wrote: post #30

Earlier quoted context omitted.

1. Kubernetes is when your service needs google kind of load which 90% of systems don't. Just trade it for simple VM or use LXD containers. Don't jump on next hype cycle. If something works for Google does not mean will work for you. 2. Don't spend too much on it just use traditional knowledge and, you can still use bare-metal, VM or LXD container. Focus on application not on programming a tool designed to solve prob…

> Kubernetes is when your service needs google kind of load which 90% of systems don't. This is the most frustrating but oft repeated nonsense about k8s. Kubernetes is an amazingly helpful abstraction for any amount of load on any larger than trivially tiny set of services/storage/etc. When you, like 90% of systems, don't have Google kind of load, you don't need Google number of nodes. Machine count corresponds to lo…

> Kubernetes is an amazingly helpful abstraction for any amount of load on any larger than trivially tiny set of services/storage/etc.

Abstractions have a cost. You either pay the cloud provider or you pay the Ops team that runs the cluster.

If you're fine with that and have evaluated the costs correctly, great!

Re: Why Does Developing on Kubernetes Suck?

#57

Post by oblio »

nouney wrote: post #33
dragonsh wrote: post #30

Earlier quoted context omitted.

1. Kubernetes is when your service needs google kind of load which 90% of systems don't. Just trade it for simple VM or use LXD containers. Don't jump on next hype cycle. If something works for Google does not mean will work for you. 2. Don't spend too much on it just use traditional knowledge and, you can still use bare-metal, VM or LXD container. Focus on application not on programming a tool designed to solve prob…

Managing a VM vs a managed Kubernetes cluster? I'd choose kubernetes without hesitating

> Managing a VM vs a managed Kubernetes cluster?

So the win is not having to manage something :-) How is that a fair comparison?

Re: Why Does Developing on Kubernetes Suck?

#58

Post by sametmax »

tinco wrote: post #49
sametmax wrote: post #38

Earlier quoted context omitted.

The trick is to understand that most products don't need to have 99% uptime. Your business will be fine if you are offline once in a while. Hell, the stock market goes offline every night. Those last % of uptime are very, very expensive at every level (money, people, logistic...). They better be worth it.

There's a difference between going offline at a set time for a set amount of time, and going offline randomly for unpredictable amounts of time. HA is not just about getting that sixth 9, it's also about the peace of mind that you are insulated from a range of problems. Not only would I not worry about our SQL service going down, I also don't have to worry about what I have to do when a node goes down, because that's…

Even an occasional site crash is ok. I'm not saying it's a good user xp, and avoiding it is both better for the tech team and the marketting one.

But the cost of a 500 is always to be balanced with the cost of going full throttle with micro services.

As perfectionists, it's easy to fall into the trap of choosing the later by default.

Re: Why Does Developing on Kubernetes Suck?

#60

Post by tutfbhuf »

oblio wrote: post #55
tutfbhuf wrote: post #53

Earlier quoted context omitted.

> It doesn't help when a service is only for few million users with few hundred or thousand containers. Well my company switched from VMs to k8s (few hundred containers) and it helped. Proof me wrong.

Do you manage Kubernetes, personally? Did you manage the VMs?

Yes, i'm a DevOps engineer. I have to say, we use the Google Cloud and many Google Services, this makes live so much easier. Before that we managed everything ourselves on bare metal with debian VMs.
Post reply on HN