Live data from Hacker News

Why Does Developing on Kubernetes Suck?

blog.tilt.dev

41–50 of 87 posts

Re: Why Does Developing on Kubernetes Suck?

#41
post #2

Ok, wow. Talk about mixed feelings towards the article... the author is clearly knowledgeable, but it is so unclear why in the world does he opt for this kind of torture. 1. Why kubernetes for development? For most cases you don't need the whole orchestration over multiple nodes overhead, docker-compose is just fine. Incidentally, your push/pull problem is solved as you pull the dependencies and BUILD your app locall…

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 load; abstraction doesn't.

Re: Why Does Developing on Kubernetes Suck?

#42

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…

This misses the genius of k8s. When you adopt it, you’re adopting a completely declarative way of provisioning your system. It’s a total paradigm shift and I will never go back. My big want, is a kube as a service for small workloads - I.e I can just apply a deployment and everything goes up, no cluster considerations or whatever.

It's good if you found it working for you. If your team can grok over all of k8s complexity and moving parts, stick with it, use the tools your team is comfortable with. I tried working with docker since 2013 and later with Kubernetes, I still go back to LXD. In my view less systems and moving parts less complexity, maintenance and cognitive load. On top of it I don't have to give up decades of knowledge I learned regarding cluster and distributed computing on bare-metal and VM as I can apply the same to LXD. Obviously I can do that with Kata containers, but they didn't fit with my team either. Also for most of services with users in the range of 160-180 million LXD work fine.

Re: Why Does Developing on Kubernetes Suck?

#43
post #13
post #4

> Why Does Developing on Kubernetes Suck ? IMHO because we are in a phase of transition. Having worked for years in software industry , I'm convinced we are halfway to a much bigger transformation for Software Engineers / SRE , Developers etc... I work in a Neobank ( N26 , Revolut, etc...) , we are currently in the process of re-writing our entire Core Banking System with MicroServices on top of Kubernetes with Kafka…

> Their workflows is insanely complex and requires hours if not a day to deploy a single change... obviously let's not even talk about the amount of work our SRE has in the pipe to "package" the entire stack of 150+ services in K8 through a single YAML file.... One should always keep in mind the famous aphorism: > "All problems in computer science can be solved by another level of indirection, except for the problem…

That's a fantastic quote. Don't know how I haven't come across it before. It definitely sums up our profession in a nutshell.

Re: Why Does Developing on Kubernetes Suck?

#45
The one thing I have found tedious with k8s clusters is when you need to work on the host system in relation to a specific pod. E.g. to diagnose kernel issues or for profiling/debugging tools that need unrestricted root.

This can require jumping through several hoops. Find the node, get through some bastion host, inject SSH keys into target node, build an SSH chain to get into the host, then escalate from admin to root account.

It would be nice if kubectl offered an escape hatch for these kinds of things, assuming one has sufficient permissions.

Re: Why Does Developing on Kubernetes Suck?

#46
post #4

> Why Does Developing on Kubernetes Suck ? IMHO because we are in a phase of transition. Having worked for years in software industry , I'm convinced we are halfway to a much bigger transformation for Software Engineers / SRE , Developers etc... I work in a Neobank ( N26 , Revolut, etc...) , we are currently in the process of re-writing our entire Core Banking System with MicroServices on top of Kubernetes with Kafka…

>I'm sure this complexity is temporary. One tech will automate all of this away and building , deploying and running will be much simpler.

Kubernetes was supposed to be one of those technologies.

Re: Why Does Developing on Kubernetes Suck?

#47
post #18

What would you recommend for development of some private project on a local server? No cloud cluster, bare metal and great opportunity to learn. Something on the order of 20-40 services for even the most trivial things. Development speed above all else

Hi aloer!

Garden co-founder, so perhaps (likely) a little biased[0].

Depending on your needs, Garden and Tilt are both great solutions, with slightly different philosophies.

It's easy to get started with Tilt if you already have the Kubernetes manifests. If not, Garden might better suit your needs since its "container" module type allows you to provide only a minimal description of your module which Garden then maps into K8s manifests. So you won't have to write the full specs for 20+ services. (Garden also supports Kubernetes manifests and Helm charts if that's your jazz).

Garden will also manage the dependencies between all your services (at a granularity of builds, deploys, tasks, and tests). So if service12 needs to be built before service20, and service18 needs to be deployed before service5, but only after the database migration for service2 is completed, Garden can take care of that. This also improves dev speed since Garden knows exactly what to re-build and re-deploy as you make changes to your source code.

And on the topic of dev speed, Garden supports both hot-reloading and in-cluster building which allows you to share build caches with the rest of you team.

In general, there are a lot of interesting tools in this space and it's evolving rapidly. So even though developing on Kubernetes on your local laptop _can_ suck, developing distributed systems doesn't have to.

[0]: https://github.com/garden-io/garden

Re: Why Does Developing on Kubernetes Suck?

#48
post #4

> Why Does Developing on Kubernetes Suck ? IMHO because we are in a phase of transition. Having worked for years in software industry , I'm convinced we are halfway to a much bigger transformation for Software Engineers / SRE , Developers etc... I work in a Neobank ( N26 , Revolut, etc...) , we are currently in the process of re-writing our entire Core Banking System with MicroServices on top of Kubernetes with Kafka…

>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.

Re: Why Does Developing on Kubernetes Suck?

#49
post #32

Earlier quoted context omitted.

for development, i agree. For production/testing/staging - hmmmm, it depends. I have taken a particular liking to the self-healing/HA properties of kubernetes. You just swap the dead nodes out without significant impact on the production... it's awesome.

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 automated.

Re: Why Does Developing on Kubernetes Suck?

#50
post #48
post #4

> Why Does Developing on Kubernetes Suck ? IMHO because we are in a phase of transition. Having worked for years in software industry , I'm convinced we are halfway to a much bigger transformation for Software Engineers / SRE , Developers etc... I work in a Neobank ( N26 , Revolut, etc...) , we are currently in the process of re-writing our entire Core Banking System with MicroServices on top of Kubernetes with Kafka…

>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?
Post reply on HN