Comment by nimbius | Hacker News Reader

Comment by nimbius | Hacker News Reader

I work as an engine mechanic full time, and im learning programming as a hobby. Kubernetes to me is like the shade-tree mechanic vs the professional.

Professional mechanics use high grade tools that can cost thousands of dollars each. We have laser alignment rigs, plasma cutters, computer controlled balancing and timing hardware, and high performance benchmarking hardware that can cost as much as the car you're working on. We have a "Kubernetes" like setup because we service hundreds of cars a month.

The shade-tree mechanic wrenching on her fox body mustang on the other hand? her hand-me-down tool box and a good set of sockets will get her by with about 90% of what she wants to do on that car. she doesnt need to perform a manifold remap, so she doesnt need a gas fluid analyzer any better than her own two ears.

I should also clarify that these two models are NOT mutually exclusive. If i take home an old Chevy from work, I can absolutely work on it with my own set of tools. And if the shade-tree wants to turn her mustang into a professional race car, she can send it to a professional "kubernetes" type shop that will scale that car up proper.

I don't quite resonate with the analogy here. It's about using the right tool for the job. Most small-scale personal projects, by their very definition, don't require an orchestration framework.

It's an old cliché, but car analogies rarely work for explaining computer phenomena. You won't be running a 1000 little kubernetes cars, and that's what k8s approach is all about running thousands of disposable little servers at Google scale.

With any car it's about making that single car more reliable or performant.

K8s doesn't care about reliability of any single instance, just the uptime of the whole service

The analogy shouldn't be hobbyists versus professionals.

It's more like you building your own car versus a Toyota manufacturing plant. You may think procuring and programming the robots to be an overkill for a single car, but it makes sense for a factory.

This is an interesting perspective because I view k8s as the "shade-tree" version of a robust cloud platform. It's cheap, quick, dirty, and probably can take off a few of your fingers if not done carefully, but the payoff is in being able to spin up lots of resources very quickly.

What do the pros use, then? I hear of things like DC/OS, Openstack, I know that Google's got "Borg", which is like professional k8s.

I work for one of those tech giants that I think falls into your "pro" category in a role that you could call dev ops. I used to work in a much smaller startup. The comparison of a tech giant's stack to large, growth stage startup tech stacks is like comparing trains to trucks. It's a qualitatively different problem because the difference between a few thousand and a few hundred thousand servers is Murphy's law.

In other words, I think there are two answers to your question of "what do the pros use?" The first answer is "Kubernetes, because that's the right tool for the job." The second answer is "My product division has an internal team the size of a growth stage startup, and it's specifically dedicated to solving server scaling problems, and that's just my product division."

Another analogy would be the question "how would an F1 team solve this problem?" One answer is "you don't need an F1 team for that", and the other is "first, hire an F1 team, then have them build all of the custom tooling the F1 car needs."

This doesn't make sense, and it's really the opposite of what you're saying. K8s is hard, but for large scale you need something robust that's tested at that scale. A collection of shell scripts is more like a beginner tool set. Yes, it's easy to learn, but it will break when you get serious.

For large scale you have to first make your application capable of scaling. That's a bit that's missing from most of these conversations. Only the simplest programs can "scale up" by just adding more programs - most have to be re-architected to move all the state in the program to some other service.

That is to say, if scaling is your primary concern, you have a dozen other things more important to fix than your choice to use shell scripts vs. Kubernetes.

And, fwiw, Linux has run professional services somewhere around 10x longer on those "beginner tools" than containers have even existed.

I think you mean "scale out" [1]? These days, it shouldn't really require a rearchitecting of a system. Almost all modern web frameworks are designed to be stateless anyway, externalizing ownership of state to databases and other services (themselves stateless APIs to databases).

[1] https://en.wikipedia.org/wiki/Scalability#Horizontal_and_ver...

There are a lot of fully professional, large-scale shops not using Kubernetes, so the analogy seems unfortunate, to me. But I guess that shows you how successful the marketing for this stuff has been, if you think that anyone not using it is acting like a "shade tree mechanic."

Reply on news.ycombinator.com