4 ms·

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 giv

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)
- StreamBright 7y ago
  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.
- originalvichy 7y ago
  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.
jsjohnst 7y ago
> 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.

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)
StreamBright 7y ago
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.
originalvichy 7y ago
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.

jsjohnst 7y ago

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