Sure, I know iptables, namespaces, cgroups and containers and lxc. I stopped right here and did not bother to learn Kubernetes because all of this knowledge gives me enough to run anything I want, websites, applications, hadoop clusters and so on without it. I can debug my stack and resolve any issues with confidence, have upgrades and do autoscaling (using AWS). Why should I even think about Kubernetes? Now the real question is, if you need to learn all these to run Kubernetes than is it really tool they are trying to sell it is? One of the promise I often hear is that you don’t need systems knowledge or SREs to run it. Yet I read these stories and many customers reach out for help because they have an undebugable problem in production and nobody can help. I learned in the last 20 years working as a systems engineer that the best tools or stacks are ones easy to understand, debug and fix. Black box computing is the worst, when things happen for no good reason and it is hard to find out the root cause.

> One of the promise I often hear is that you don’t need systems knowledge or SREs to run it.

Maybe if you use GKE that might be the case, but otherwise, running Kubernetes is a fools errand if you don’t have extensive experience with systems and SRE, imho, and anyone telling you otherwise is selling snake oil. Sure, you might get lucky and never have a major issue, but do you really want to depend on luck?

> I learned in the last 20 years working as a systems engineer that the best tools or stacks are ones easy to understand, debug and fix.

Sure, that’s an ideal goal and one I strive for too when possible, but there’s a reason why many SRE folks make a very large salary compared to national averages. Hard work is expected from time to time.

How is AWS not black box computing? Isn't it worse than a black box? Because it's a black box that's sitting in a black building that you don't have access too?

Disclaimer: I'm a n00b when it comes to web stuff.

You know when it breaks (built in monitoring) and there are SLAs. If it is broken Amazon will fix it. I can work around it, using caching proxies for S3 for example. There are other approaches to be more resilient against cloud outages. The most important difference between self hosted Kubernetes vs cloud native services is that who will fix it.

If there's a problem with an aws service then aws will fix it. Of course there's always this weird bug that you will run into even in their services, but at the least, if there's an API that's documented, it works as documented for the documented scenario.

An autoscaling group in AWS might have issues if you complicate it a bit and run into edge case bugs, but otherwise it's most definitely going to scale your instances up and down (because they bill you to do so)

What AWS does is easy in the small scale but hard on a large scale. The core tech is about giving you a seemingly unlimited supply of object storage, disks, virtual machines and networks to connect and isolate them. This is something a hundred companies have been doing for years but AWS is in the lead thanks to their level of tech that has made the buying of computer resources fast and easy.

Simply said: buying basic VM/dedicated machines has been around long enough that it is not a black box for professionals.

I feel mostly convinced that your point here is the sane one.

One nitpick though:

> do autoscaling (using AWS)

But that would mean that you're partially locked in on AWS? Only when it comes to auto scaling bit still...

Yeah I am willingly be locked in to AWS which is a stable, proven, compliant solution with sophisticated SLAs and even paid support. I can create reliable distributed highly available performant services on top of it. That is all I need. As far as locking in on Kubernetes goes I am not sure.

Someone has to have physical servers somewhere right, even with kubernetes?

You're either locked into a provider for that or locked into the team that runs your own datacenters.

Sure but if all your infrastructure scripts are built with kubernetes in mind switching from one provider to another becomes much less labor intensive than if they are built with Azure or Amazon in mind. At least in theory.

> Why dont people get the basics of the parts of the tool

not saying that you are incorrect, but "basic" is relative.

To understand Linux networking should we also understand basic linux kernel ? or basic chemistry to understand what happens inside the cpu ?

We should all stand on the (stable) shoulders of giants. I would call that good (also relative indeed) documentation that abstract us from the level below/above.

If you are working on fabs, yes you should understand basic chemistry. If you are working on distributed stateless cloud-agnostic applications, yes you should understand both the networking and kernel of your OS on which said applications run.

Even if there is an abstraction layer with nice boundaries and well documented, you can still not ignore the layer below and pretend its raining.

When you are making a web app (for advertising purposes since this is HN), can you ignore understanding HTTP and TCP and IP? Would you hire a web-application developer who didnt know how to setup a web-server or load-balance his app?

> Would you hire a web-application developer who didnt know how to setup a web-server or load-balance his app?

My company does this all the time.

In fact, in the absence of our step-by-step guides, I would estimate that maybe 5% of the development team could successfully configure their local web server on their own.

Understanding the fundamentals is indeed very important. Not that you need to be an expert in it, but knowing basic concepts is extremely helpful for troubleshooting, and I would argue is the thing that makes the difference between a junior and senior person.

I don’t use most of the fundamentals I learned in school directly on a daily basis, but I do use them almost every day to inform the decisions I make about higher level things.

To bake a pie, you must first invent the universe.

The challenge with Kubernetes is the number of layers that are being created. Whilst each individual layer can be understood, it takes time.

Additionally, these layers are prone to rapid change. To take one example Cilium and other players in the container world are looking to replace iptables with eBPF. So learning iptables becomes obsolete.

For me, Kubernetes is cool and if you have enough scale to need it, very useful. The problem is (like most IT hype cycles) it's getting used in inappropriate places, where simpler more basic solutions could work just fine.

Because Kubernetes is the new NoSQL, there are consulting services, conference talks and books to be sold.

And SREs to resist. :) I refuse to put Kubernetes into our infra.

I wanted to, then I read about it.