Live data from Hacker News

Why Does Developing on Kubernetes Suck?

blog.tilt.dev

71–80 of 87 posts

Re: Why Does Developing on Kubernetes Suck?

#71
What an immature and rude way to criticize a young open source project. I’m disappointed that so many in our community appreciate this disrespectful writing style criticizing our k8s supporting peers.

Secondly, developing on Kubernetes “sucks” compared to what? Mesos? Docker Swarm?

Maybe this engineer is still frustrated with Tilt’s failure as a business (https://www.fastcompany.com/3069164/how-tilt-veered-off-cour...) and Airbnb imposing changes on his workflows like how they deploy their apps. If that’s true then I hope he finds more healthy and mature habits to manage his anger.

Re: Why Does Developing on Kubernetes Suck?

#72
post #48

Earlier quoted context omitted.

>Their workflows is insanely complex and requires hours if not a day to deploy a single change... Isn't this what micro-services were supposed to be the solution to? I get the feeling the whole thing is oversold.

Isn't it kind of defeating the purpose of micro-services if you deploy every one of them every time?

Exactly! I've seen this so many times in the past few months... It seems peoples don't understand the true nature of microservices

Re: Why Does Developing on Kubernetes Suck?

#73
post #57
post #33

Earlier quoted context omitted.

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?

> So the win is not having to manage something

Exactly!

> How is that a fair comparison?

Not only is it a fair comparison, but I'd say it's the entire raison d'etre of using any orchestration platform: You get to farm out bits of the infrastructure to others. Getting on k8s enables you to not have to run your own infrastructure, whereas having VMs being your abstraction sorta by definition does not.

Re: Why Does Developing on Kubernetes Suck?

#74
post #49

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…

Exactly... HA is about being able to sleep more peacefully each night.

Re: Why Does Developing on Kubernetes Suck?

#75

What an immature and rude way to criticize a young open source project. I’m disappointed that so many in our community appreciate this disrespectful writing style criticizing our k8s supporting peers. Secondly, developing on Kubernetes “sucks” compared to what? Mesos? Docker Swarm? Maybe this engineer is still frustrated with Tilt’s failure as a business ( https://www.fastcompany.com/3069164/how-tilt-veered-off-cour.…

> Secondly, developing on Kubernetes “sucks” compared to what? Mesos? Docker Swarm?

My thoughts exactly. I feel like most people who complain about these things are just feeling grumpy about the overall experience, and aren't always quite sure where to place the blame.

It takes a lot of introspection to know exactly where a system should be better than it is... "this yaml is too complex", until you start thinking about how you'd do it better, and then you realize all the problems each of the similar approaches have, and that a lot of it was done for a reason, etc.

Or you start comparing k8s to completely different approaches like just rsyncing some files to a remote webserver and SIGHUP'ing it, which is much simpler but has its own host of reliability/testability/reproducability concerns.

I think in reality, people are overwhelmed by what it really takes to adopt best practices (declarative deployment, CI/CD, health checks, service discovery, etc). Practices that have been hard fought and discovered over many years of people trying things and failing. K8S IMO represents the state of the art in a lot of them, but too often people place blame on k8s when what they're really doing is questioning the best practices themselves. Practices that are also shared across k8s's competitors like mesos and docker swarm.

Re: Why Does Developing on Kubernetes Suck?

#76
post #41

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 may be a useful framework, but "amazingly helpful" is not a word I'd use for it. To me, it's a half-assed collection of five hundred nearly identical (but all slightly different) yaml files masquerading as "abstraction". And because they're yaml you can't refactor out the common part.

Well, to be fair, yaml itself doesn't exactly have a stellar reputation, but I've never seen fifty lines of yaml that could convey so little information in any other place.

Re: Why Does Developing on Kubernetes Suck?

#78
I share the vision of this article. We are working on the same problem at Okteto Inc.

As an ex-docker employee, I love to work with docker-compose and I agree it is usually a good enough abstraction for development.

But it is not only about the tool, I think the future of development is on the cloud and Kubernetes is a perfect fit for ephemeral dev environments:

- You have unlimited hardware and network resources but efficiently shared by all your team.

- You can share endpoints for fast validation and easier integration with external systems and webhooks.

- You reduce k8s integration issues.

- You have access to infra services like service mesh, logs aggregators and metrics from development.

We just need to improve our dev tools to reach a great dev experience on remote Kubernetes clusters. I have been working like this for 2 years now and I can say my dev experience is much better than before. I have replicable dev environments, I can spin a new dev environment on a new namespace for each git branch, switch dev environments with a single command, and deploy my changes instantly.

And 5G is just around the corner and it will make the experience even better.

Re: Why Does Developing on Kubernetes Suck?

#79
post #72

Earlier quoted context omitted.

Isn't it kind of defeating the purpose of micro-services if you deploy every one of them every time?

Exactly! I've seen this so many times in the past few months... It seems peoples don't understand the true nature of microservices

Yep, it’s common enough that it’s considered an anti-pattern. It’s called “distributed monolith.”
Post reply on HN