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

141–150 of 213 posts

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

#141

Post by hliyan »

zachlatta wrote: post #136
pavlov wrote: post #110

Earlier quoted context omitted.

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.

Who are also heavily trained in the physiology of the organs they operate on, long before they're allowed anywhere near a scalpel.

What you say about trades is true, but then we need to start making the distinction between software engineers and software technicians. I doubt that will go down well in an industry where everyone wants to be a senior software engineer, a tech lead or higher...

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

#142

Post by erikb »

ShroudedNight wrote: post #107
tananaev wrote: post #90

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 can make sense of all the back and forth in k8s networking? That needs more than package capturing I suppose. How do you translate a million packages into something useful?

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

#143

Post by [deleted] »

SmooL wrote: post #121
tananaev wrote: post #90

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…

I agree that it's not necessary, but: Sockets are generally accepted as the standard. If you want to stream data to another computer, that's pretty much the only way to do it. The solution has been decided already. A lot of these frameworks live in a space that's still evolving. We, as a community of developers, haven't agreed on the 1 best way to do it. As such, there are multiple offerings. In these cases, I feel i…

[deleted]

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

#144

Post by hennsen »

pavlov wrote: post #110
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."

Basically yes, if employers/customers only look for products and not general experience and signs of being a good crafts(wo)man it’s not useful.

On the other hand, someone who already worked with 10 Languages, 7 webframeworks and 5 deployment/config management tools plus showing good craftmanship has enough experience to learn one more of these quickly. Only for a short term gig, the learning/being productive relation could be disproportional.

I‘ve experienced it being habdled rather the latter than the former way and don’t remember not getting a job for having not yet worked with one of these tools, but bei g chosen for experience and quality work.

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

#145

Post by pas »

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.

K8s is a great system manager. A natural evolution of config management and containerization.

And it's good for deploying big systems with lots of moving parts (such a OpenStack, or any proprietary system, let's say a big e-commerce site).

And even if the problem is straightforward (just run these docker containers, just do this rolling upgrade, just do setup these nginx load balancers, just add these to monitoring), all of these are a chore, especially if done right. And config managers always fail at the premise of apply changes to a "known state" (or they spend an eternity checking the state), so why not fuse actual monitoring with config management, and a lot of nice concepts fall out automatically, like Deployments. No longer do you have to disable the alerting part of monitoring, or mark certain parts of the telemetry time series as irrelevant for SLA accounting because we were deploying (or cobble together scripts to handle this for you), and then evolve the whole system as the underlying components (the things that are being deployed) change.

Sure, k8s is not there yet, as the problem is big, complex, and hard to get right even in parts, but a lot better already than the simple one-man-army homegrown solutions. (IMHO)

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

#146

Post by erikb »

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…

> On the other hand there is no end on how low you can go in the technology stack.

Not completely true. I think it's possible to have a complete simplified image of a computer in ones head while working on the newest version of your web app, going into depth in this area where problems arise.

And usually it's the other way around than you might think. Sockets you learn once and can probably even apply in 40 years. The current hip web framework you can't even use anymore in the same company in 2-5 years.

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

#147

Post by erikb »

chrisweekly wrote: post #14
nimish wrote: post #9

kubernetes is a classic case of a tool designed for consultants and companies to sell consulting services (Including cloud services, which is why every cloud provider leapt onto it). In like 90% of the cases when someone used Kubernetes, Docker Swarm would have easily sufficed.

Docker Swarm is a hot mess.

It might be and still succeed compared to its big brother.

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

#148

Post by bryanrasmussen »

hliyan wrote: post #141
zachlatta wrote: post #136

Earlier quoted context omitted.

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.

Who are also heavily trained in the physiology of the organs they operate on, long before they're allowed anywhere near a scalpel. What you say about trades is true, but then we need to start making the distinction between software engineers and software technicians. I doubt that will go down well in an industry where everyone wants to be a senior software engineer, a tech lead or higher...

I'm thinking the physiology of the organs might be less complicated than understanding a modern applications at all levels of the stack.

Maybe that would be understanding the organs, the underlying physical processes those organs regulate, the chemicals that are released as parts of those processes, and the effects and composition of those chemicals, and if it is possible to induce similar effects through replacement chemicals in the way of medication.

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

#149

Post by pulsarpietro »

pas wrote: post #137
muxator wrote: post #104

Earlier quoted context omitted.

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…

> And how bad the demand side is when it comes to picking the experts.

You meant, there is a very strong demand ?

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

#150

Post by erikb »

nimish wrote: post #9

kubernetes is a classic case of a tool designed for consultants and companies to sell consulting services (Including cloud services, which is why every cloud provider leapt onto it). In like 90% of the cases when someone used Kubernetes, Docker Swarm would have easily sufficed.

Why is this so heavily downvoted? A clear, legit opinion to have.

In my experience it's even like this: I have never seen any working kubernetes app. But I deployed my own hello world docker swarm app in 2 days. (And that is a fact, not an opinion. The opinion part is up to you.)

Post reply on HN