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

Will Kubernetes Collapse Under the Weight of Its Complexity?

influxdata.com

Post reply on HN
Print view View original

101–110 of 213 posts

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

#101

Post by manigandham »

hliyan wrote: post #99
manigandham wrote: post #92

Earlier quoted context omitted.

Yes, there should be a baseline of understanding. It's unpopular to say but this field has too much complaining about things not being "easy enough" because of a lack of understanding concepts and architecture with too much focus on products, like you describe. Would you complain that you can't be a doctor without significant training or a lawyer without understanding the law? At some point, knowledge is required. Di…

Not sure exactly what you're trying to say, but it seems like your second paragraph skillfully refutes the points you seem to be making in your first and third.

You need a real understanding of the problem and possible solutions to actually solve something. Tools (regardless of complexity) only help you solve it once you understand.

People tend to say Kubernetes is complicated because they don't understand the problems it's solving in the first place. If they did, it would be rather straightforward or they would recognize they don't need it in the first place.

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

#102

Post by EtienneK »

jtwaleson wrote: post #63

Heroku / Cloud Foundry offer exactly what the author points towards: a very simple user interface for developers. InfluxDB will of course needs stateful applications so it's not a good use case for them. The Cloud Foundry community has started exploring a switch from their own container management system to K8s. If that becomes real, CF would "just" become a nice user interface on top of k8s. The right move imho.

This is basically what OpenShift is. Highly recommended.

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

#103

Post by hliyan »

manigandham wrote: post #101
hliyan wrote: post #99

Earlier quoted context omitted.

Not sure exactly what you're trying to say, but it seems like your second paragraph skillfully refutes the points you seem to be making in your first and third.

You need a real understanding of the problem and possible solutions to actually solve something. Tools (regardless of complexity) only help you solve it once you understand. People tend to say Kubernetes is complicated because they don't understand the problems it's solving in the first place. If they did, it would be rather straightforward or they would recognize they don't need it in the first place.

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.

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

#104

Post by muxator »

tananaev wrote: post #90
hliyan wrote: 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 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 you are offering to the application.

Are you a manager? Focus on your own manager and objectives, but do not forget to empathically look at your team members.

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

#105

Post by gaius »

hliyan wrote: 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 don't know what to think when I meet engineers who know how to setup an ELB on AWS but don't quite understand what a socket is...

I keep meeting people who list say Postgres as a skill and when probed they admit they just clicked a button in Amazon RDS and that’s all they know about it. At some point it crosses the line into outright deception. This is the other side of the coin on why interviewing is so broken too.

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

#107

Post by ShroudedNight »

tananaev wrote: post #90
hliyan wrote: 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 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, and god help you if something you're interacting with has a smug sense of knowing what's best for you.

There have been a number of cases where I've had to rely on the ability to debug binaries directly at -O3, or to resort to Wireshark to get the dose of reality needed to challenge my [our] flawed mental model. If I hadn't been able to do those things, I'd probably still be there, pondering those defects, if not in body [due to declaring outright failure], at least in spirit.

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

#108

Post by gaius »

hliyan wrote: post #103
manigandham wrote: post #101

Earlier quoted context omitted.

You need a real understanding of the problem and possible solutions to actually solve something. Tools (regardless of complexity) only help you solve it once you understand. People tend to say Kubernetes is complicated because they don't understand the problems it's solving in the first place. If they did, it would be rather straightforward or they would recognize they don't need it in the first place.

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.

I've seen plenty of people proposing Kubernetes (or Docker Swarm or whatever) for simple systems that clearly don't need it.

That may be deliberate resume-padding. Same as most Hadoop implementations.

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

#109

Post by hardwaresofton »

pcthrowaway wrote: post #83
hardwaresofton wrote: post #69

This blog post starts under a false premise. Kubernetes is not for app developers, it is the substrate on which applications, databases, and other workloads run. Just like you wouldn't want an application developer SSHing into machines in production (assuming you have ops people), you don't want them to use kubernetes, except kubernetes has done one better -- it's abstracted so well (especially with the introduction…

> "the only concession I would make is that they could all be in the same daemon (one executable), but that's actually worse at scale, and harder to debug -- all of these services can produce a lot of logs." This is already a thing, sort of, called hyperkube: https://github.com/kubernetes/kubernetes/blob/master/cluster... The caveat is that each daemon has to be started separately still

hyperkube was what i used when I got my first cluster up and running (this was when coreos still hosted kubernetes baremetal setup guides not just pointing everyone to tectonic), I remember it fondly :)

I didn't include it due to that caveat, and the general feeling that the processes really are meant to be started separately. I haven't seen anyone try and run these processes with some sort of supervisor but it seems like that's not "the way" and wouldn't really even offer any benefits.

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

#110

Post by pavlov »

hliyan wrote: 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."

Post reply on HN