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

Google admits Kubernetes container tech is too complex

theregister.com

Post reply on HN
Print view View original

171–180 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#171

Post by machiaweliczny »

durnygbur wrote: post #87
hliyan wrote: post #29

The implementation details and management tools aside, the mental model for what is basically interconnected hardware should never be this complex.

Hey that's only BE, throw in Angular with Observables and NgRx on the FE and people will start jumping out of the windows from insanity.

That's why I don't trust anything from google. They just release too complex software (cause theirs devs can deal with this crap anyway and it's good to let others suffer xD)

Only thing that's somewhat good is Go lang.

Re: Google admits Kubernetes container tech is too complex

#172

Post by kkapelon »

colesantiago wrote: post #10

What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.

> I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it.

I just enter my Honda Civic and drive to my office. Simple. I call it "Sedan".

(Honda Civic driver looking at an 18-wheeler in the highway and not understanding why somebody would use that)

In all seriousness though, Kubernetes solves a specific set of problems. Just because you personally don't have these problems, doesn't mean that Kubernetes is bad, or that people who use it, don't need it.

Re: Google admits Kubernetes container tech is too complex

#173

Post by YawningAngel »

machiaweliczny wrote: post #158
endymi0n wrote: post #71

Earlier quoted context omitted.

I fully agree with your points and would sum them up as "Kubernetes has a steep learning curve, a (quite) large interface and ample opportunities to shoot yourself into the foot with it" (plus, they're very funny). However playing the devil's advocate here: If you actually took the steps of learning the basic abstractions, then for me it's really hard to see what you could still get rid of. If you actually go all-in…

IMO fixing BEAM VM to easily work on cluster could be better for distributed systems than k8s.

That would do nothing to help the 99% of users who don't use BEAM VM languages

Re: Google admits Kubernetes container tech is too complex

#174

Post by machiaweliczny »

deckard1 wrote: post #66
keanebean86 wrote: post #18

Earlier quoted context omitted.

The circle of tech: 1. Someone has an idea. It's alright. Really good for their use case. Someone else hears about it, likes it, and adapts it to a similar use case. So and so forth until the idea has a large user base 2. Employees of large companies hear about the idea and implement it 3. Marketing gets a hold of the idea, gives it a flashy name, and uses it in promotions 4. A majority of the loudest voices in the i…

You have a lot of tech companies digging up gold, and a whole lot more selling shovels to the rest of the crowd. Most of the software tech world is bullshit. Most best practices are bullshit. And, if I were feeling a bit conspiratorial, I'd say the large tech companies do this on purpose. They promote fads that overburden any smaller company with more modest budgets, thus keeping competitors at an arm's length. Resum…

There's hope that companies that have to be competitive from poorer countries will push correct technologies. I see it happening in UK, Brazil, Russia etc.

But it's no good to be big company when Whatsapp can be build by one person you missed to hire.

Re: Google admits Kubernetes container tech is too complex

#175

Post by stewartmcgown »

KronisLV wrote: post #155
sofixa wrote: post #79

Earlier quoted context omitted.

Docker Swarm is pretty much abandonware/on life support at best, so one should avoid using it for new stuff. Hashicorp's Nomad is the best choice on the complexity for features scale IMHO, and that's why i'm writing an article how great it is, how easier some things are and what's missing compared to Kubernetes.

And yet, Docker Compose is pretty popular for local development, so much so, that it's not uncommon to find a docker-compose.yml in the repositories for many open source projects. And Docker Swarm builds on that, by bridging the gap between Docker Compose and multi-server deployments, with tools like Swarmpit and Podman for easier management of it as well, much like Rancher does for Kubernetes. I agree that Docker Sw…

Absolutely. We use Swarm in production at ecoeats and it's a dream for simple clustering with multiple services. Using Hetzner clouds volume plugin gives EBS-like functionality too.

Re: Google admits Kubernetes container tech is too complex

#176

Post by bob1029 »

I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today).

For our current stack, the answer has been to make the entire business application run as a single process. We also use a single (mono) repository because it is a natural fit with the grain of the software.

As far as I am aware, there is no reason a single process cannot exploit the full resources of any computer. Modern x86 servers are ridiculously fast, as long as you can get at them directly. AspNetCore + SQLite (properly tuned) running on a 64 core Epyc serving web clients using Kestrel will probably be sufficient for 99.9% of business applications today. You can handle millions of simultaneous clients without blinking. Who even has that many total customers right now?

Horizonal scalability is simply a band-aid for poor engineering in most (not all) applications. The poor engineering, in my experience, is typically caused by underestimating how fast a single x86 thread is and exploring the concurrent & distributed computing rabbit hole from there. It is a rabbit hole that should go unexplored, if ever possible.

Here's a quick trick if none of the above sticks: If one of your consultants or developers tells you they can make your application faster by adding a bunch of additional computers, you are almost certainly getting taken for a ride.

Re: Google admits Kubernetes container tech is too complex

#177

Post by ahoka »

diarrhea wrote: post #148
FlyingSnake wrote: post #109

Putting on my Asbestos Longjohns: The more I look into k8s ecosystem, the more I'm convinced that it's one of those things that suits FAANG etc, but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill. After all no one got fired for buying IBM and recommending Kubernetes. Most teams need a simpler deployment strategies that other's have succinctly mentio…

A friend of mine is a contributor to k8s itself, and of course, this all comes incredibly easy to them. Following their recommendation, I gave it a shot for my single-person, single-node (!) homelab, all without using MicroK8s, k3s or similar. After a week of almost full-time work, I threw in the towel. Admittedly, I also had to learn concepts like reverse proxies alongside, too, so I was by no means well-equipped to…

Yeah, of course running random docker compose files and containers from the internet and blissfully exposing your mongodb or whatnot service unsecured to the whole world seems like an easy, non-complicated alternative. Kubernetes has a few shitty defaults, like exposing a service account for all pods by default or allowing to mutate pod image tags, but most of the functionality it provides is a must have when you actually care about your SLA. Rolling updates with health check and configured back-off time? Separate ingress for OAM and live traffic with automatic HTTPS, etc? I could go on.

Re: Google admits Kubernetes container tech is too complex

#179

Post by sunshinerag »

minitoar wrote: post #25
keanebean86 wrote: post #18

Earlier quoted context omitted.

The circle of tech: 1. Someone has an idea. It's alright. Really good for their use case. Someone else hears about it, likes it, and adapts it to a similar use case. So and so forth until the idea has a large user base 2. Employees of large companies hear about the idea and implement it 3. Marketing gets a hold of the idea, gives it a flashy name, and uses it in promotions 4. A majority of the loudest voices in the i…

Good news, you can invest in my new startup where we are solving just that issue with a decentralized social technology blockchain oracle that will make and enforce these decisions, reducing tech churn and enhancing developer productivity.

Ashok?

Re: Google admits Kubernetes container tech is too complex

#180

Post by durnygbur »

machiaweliczny wrote: post #171
durnygbur wrote: post #87

Earlier quoted context omitted.

Hey that's only BE, throw in Angular with Observables and NgRx on the FE and people will start jumping out of the windows from insanity.

That's why I don't trust anything from google. They just release too complex software (cause theirs devs can deal with this crap anyway and it's good to let others suffer xD) Only thing that's somewhat good is Go lang.

...and I haven't even mentioned writing tests for it.
Post reply on HN