Live data from Hacker News

Will Kubernetes Collapse Under the Weight of Its Complexity?

influxdata.com

131–140 of 213 posts

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#131
post #70

Earlier quoted context omitted.

But it’s trivial to start typing in Word. Spell checking is easy, as are basic formatting operations. Loading/saving work the way you’d expect. Yes you can write a dissertation with a ton of support from Word to make you life easier, but doing simple things is simple. It sounds like that’s what missing from kubectl. Even for a small start it takes a lot of knowledge. To continue the Word analogy, that sounds like LaT…

K8s changed the way I thought software should be built, because it presents the data centre as an API. K8s is also not that complicated after you grok it. It's also pretty easy to get started for simple cases. It's just that you need to switch your mindset a bit; but the benefits from the mental switch are non-negligble.

> K8s is also not that complicated after you grok it.

Writing (or code-generating) a bunch of YAML configs is the easiest part about K8s. Diagnosing why in the world it misbehaves in some weird manner is where the real complexity is.

Of course, this does not apply when you're not a system administrator, but just an user of someone's else (Google) K8s.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#132
post #98

Microsoft Word is also incredibly complex software with decades of development and features, and yet it's just a word processor. Everyone uses a small subset of the actual functionality which is why the entire system can be complex and simple at the same time, depending on your needs. It's exactly the same with Kubernetes. It's just clustering software that ties multiple servers together to give you an PaaS-like work…

YES. THIS!! I'm a single-person ops team for my startup. Granted, I MAY be an exceptional learner and not realize it, but I mostly consider myself an under-achieving stoner. I chose Kubernetes as our platform a few years ago and it's been absolutely wonderful and only getting better. Every once in a while I do a thought experiment with my co-workers to ensure Kubernetes is still the product for us. It is. We all love…

> I think the complexity is over stated.

This is because you don't manage K8s and don't deal with this complexity. Google does.

Now, imagine a case where suddenly one pod can't ping another, but packets flow okay in reverse direction. The cost suddenly goes up from "writing a few YAML files" to "debugging CNI".

> What is this nebulous "complicated part" of setting up kubernetes? You literally hit a button and it creates your cluster.

That is, if you want to depend on other companies to provide your infrastructure. Which is perfectly reasonable business decision, but the opposite (self-managed bare-metal colocated servers) is also perfectly reasonable.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#133
post #71
post #35

Earlier quoted context omitted.

There's no single design that suits everyone. It's a toolbox. The job of choosing the right tool is on you.

There’s a big difference between a toolbox and a box with those same tools jumbled up inside. One is organized and sensible. The other is a mess. Just because they are both technically capable of the same things doesn’t mean we shouldn’t hold ourselves to the higher standard. (Haven’t used Kubernetes, just going with the analogy)

Don't pile in on k8s criticism without familiarizing yourself, please.

IMO it's a bit like Java for the cloud, the write once run anywhere bit (same caveats, but the win is still there). It intermediates the differences between cloud platforms. That alone makes it strategically worthwhile even if it was overcomplicated. But I don't think it is. Its core control loop is simple in principle, and the concepts and extension points fall out pretty naturally from it. It is a well-designed system at core and can support improvements over time without accruing cruft indefinitely, for example. Part of that makes it look like a bag of decoupled tools. But that's a strength of the system in the longer term.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#134
post #79

This whole image, to me, represents a big problem with software engineering today: https://twitter.com/dankohn1/status/989956137603747840 The industry is full of engineers who are experts in weirdly named "technologies" (which are really just products and libraries) but have no idea how the actual technologies (e.g. TCP/IP, file systems, memory hierarchy etc.) work. I don't know what to think when I meet engineers wh…

You are soo right ! There is a shift going on between "operators" and "engineer", many "software engineering" jobs mainly configure and operate on the top of somebody's else product.

They do write code but the technical job, per-se, is not that skilled.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#135

Earlier quoted context omitted.

I have a mixed feeling about this. On one hand I definitely agree that it's good to know lower level technologies and that's something I always ask people in the interviews. I think it's important because I know it. On the other hand there is no end on how low you can go in the technology stack. Do you need to know how sockets works underneath? Low level network protocols? Do you need to know how hardware works becau…

Being able to go all the way down the software stack makes it much, much easier to keep said stack honest. Debugging is often a desperate attempt at establishing ground truth. Without a low-level understanding, you're always a the mercy of your tools, and how they have decided to curate the information they're feeding you. Even the most well-meaning curation can be so frustratingly deceiving as to incite violence, an…

> you're always a the mercy of your tools

More than tools they are products nowadays :-(

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#136
post #110
post #79

This whole image, to me, represents a big problem with software engineering today: https://twitter.com/dankohn1/status/989956137603747840 The industry is full of engineers who are experts in weirdly named "technologies" (which are really just products and libraries) but have no idea how the actual technologies (e.g. TCP/IP, file systems, memory hierarchy etc.) work. I don't know what to think when I meet engineers wh…

The overemphasis on products is a real problem because it makes the industry so susceptible to marketing snake-oil. Who would trust a doctor who proclaims his expertise in terms of brand names: "I've got ten years of experience in Cipro and Amoxil. Lately I've been prescribing Zithromax too! It's exciting to write that big Z. I really like Pfizer's community, their Slack is so helpful."

We trust surgeons who proclaim expertise in specific named procedures.

Whether we like it or not, software engineering is becoming a trade. Trades aren't inherently low skill or high skill.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#137

Earlier quoted context omitted.

I have a mixed feeling about this. On one hand I definitely agree that it's good to know lower level technologies and that's something I always ask people in the interviews. I think it's important because I know it. On the other hand there is no end on how low you can go in the technology stack. Do you need to know how sockets works underneath? Low level network protocols? Do you need to know how hardware works becau…

My personal advice in this cases is: try to be familiar with (at least) the abstraction layers below and above you. Are you a storage expert? Do not ignore how storage hardware is designed (even on a historical perspective) and frequently think about the system calls it is your responsibility to implement. Are you developing a sidecar proxy? Be fluent in low level network programming, and be aware of the interface yo…

There are specialist subfields of programming nowadays: frontend, mobile app, embedded/microcontroller.

And a frontend sitebuilder doesen't have to know anything about transistors, FinFET, system calls, and only the most curious would know about reflow and painting calls in a browser's rendering engine. Sure, the quest for performance always pushes people toward the metal, but from a website's perspective that's just the browser, and maybe TCP window tuning. (And sometimes someone finds that DNS was slow, but sometimes it was a bad BGP constellation, and there was nothing to do really. Or maybe the load balancer - or the backend - was overloaded because there was mutex contention in the kernel - or in the DB behind the backend, but that's again rather far from the usual sphere of investigation for "Frontend Engineers".)

The imporant point would be to be able to go deeper, if there's a need. Or go higher, more abstract. That's engineering (or software design), recognizing, analyzing, and solving problems.

I can't really blame the people who get by just knowing parts of AWS. They make great money by being a Cloud Consultant. It simply shows the low hanging fruits on the market. And how bad the demand side is when it comes to picking the experts.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#138
post #122
post #103

Earlier quoted context omitted.

Actually, my point was not that Kubernetes (and other "technologies" like it) is complicated, but that people tend to make it a be all and end all without actually understanding how it works under the hood. You're right about one thing: I've seen plenty of people proposing Kubernetes (or Docker Swarm or whatever) for simple systems that clearly don't need it.

> for simple systems that clearly don't need it. unless you have a single server with no availability your system is probably not "simple".

We do have a hundred or so servers with multiple redundancies, but we've done okay without Kubernetes...

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#139
post #125
post #79

This whole image, to me, represents a big problem with software engineering today: https://twitter.com/dankohn1/status/989956137603747840 The industry is full of engineers who are experts in weirdly named "technologies" (which are really just products and libraries) but have no idea how the actual technologies (e.g. TCP/IP, file systems, memory hierarchy etc.) work. I don't know what to think when I meet engineers wh…

I expect people said this about developers that just knew about TCP/IP and not how the PHY worked. At every level of abstraction they is a boundary that people may not choose (or have time) to pass. I'm not saying everyone should be forced to learn about every layer, but these knowledge boundaries exist everywhere, and I'm not sure what can be done to improve the situation...

There's no problem with not knowing the deeper/higher layers. The problem is when someone outright ignores their ignorance, when someone doesn't even acknowledge their boundaries. And when those boundaries are set in stone. ("I won't touch the terminal." or "I won't touch C." or "I won't touch CSS.")

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#140

> kubectl scaffold mysql --generate This exists, its called helm, which in fact delivers the productivity gains the author is looking for.

I have Kubernetes in Action on my desk and I haven’t cracked it open yet because Kubernetes seems monstrously complex. Sure helm gets you up and running. When something goes wrong in prod at 3am, what do you do?

K8s is actually fairly simple and self-evident once you understand about 3 core ideas: etcd being the repository of state, in particular the spec; controllers with control loops bringing status into line with spec (the core mechanism in k8s, this is key); and a familiarity with the options on pods & deployments, for initialisation, service discovery, liveness, readiness, etc. that let the system make decisions globally while you only worry about local status (this is most of what you need to know as a dev deploying a service).

Don't buy the FUD. There's a lot of it about. K8s commoditises cloud providers. It's a strategic weapon against AWS lock-in.

Post reply on HN