5 ms·

This is yet another one of those "introductory" articles. The whole field it seems everywhere is filled with "introductory" "gentle" books/articles, and then "

by antocv 7y ago

This is yet another one of those "introductory" articles. The whole field it seems everywhere is filled with "introductory" "gentle" books/articles, and then "this is how you do reusable rocket science with x". Pro tip: to understand kubernetes in between, go read the manual pages of Linux networking and get a really good grip on iptables. Go read the manual pages for linux namespaces, cgroups and containers with lxc. Why dont people get the basics of the parts of the tool they are going to use, first, instead of trying to "understand a tool"? You wont succeed doing anything with kubernetes, if you come from say macosx or windows envrionment, and have no clue how/what kubernetes is built on.

pjmlp 7y ago
Because Kubernetes is the new NoSQL, there are consulting services, conference talks and books to be sold.
- StreamBright 7y ago
  And SREs to resist. :) I refuse to put Kubernetes into our infra.
  - baq 7y ago
    I wanted to, then I read about it.
StreamBright 7y ago
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.
- worldsayshi 7y ago
  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...
  - StreamBright 7y ago
    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.
  - jrumbut 7y ago
    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.
    - worldsayshi 7y ago
      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.
- MrGman 7y ago
  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.
  - ramraj07 7y ago
    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)
lucasverra 7y ago
> 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.
- jgust 7y ago
  To bake a pie, you must first invent the universe.
- antocv 7y ago
  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?
  - Rychard 7y ago
    > 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.
- orev 7y ago
  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.
raesene9 7y ago
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.

by antocv 7y ago

pjmlp 7y ago

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

StreamBright 7y ago
And SREs to resist. :) I refuse to put Kubernetes into our infra.
- baq 7y ago
  I wanted to, then I read about it.

StreamBright 7y ago

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.

worldsayshi 7y ago
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...
- StreamBright 7y ago
  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.
- jrumbut 7y ago
  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.
  - worldsayshi 7y ago
    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.
MrGman 7y ago
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.
- ramraj07 7y ago
  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)

lucasverra 7y ago

> 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.

jgust 7y ago
To bake a pie, you must first invent the universe.
antocv 7y ago
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?
- Rychard 7y ago
  > 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.
orev 7y ago
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.

raesene9 7y ago

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.