6 ms·

Amazon is extremely data driven. If their attitude is lukewarm at best then you might consider the market is lukewarm at best. People take for granted that th

Amazon is extremely data driven. If their attitude is lukewarm at best then you might consider the market is lukewarm at best. People take for granted that the value of k8s has been proven. It has not. The value of containerizing your application is clear and has been realized over and over again. The jury is still out on k8s.

jrs95 8y ago
Do you have any actual data related to this claim or am I just supposed to assume that it's true by inferring things from Amazon's cloud offerings? Edit: Sorry for the aggressive tone, I overreacted a bit because it seems like every single day there's someone pushing an anti-Kubernetes agenda on HN. Often they don't even use it, they just glanced at the docs and said "it's too complicated", or something. Clearly, this isn’t you since you’re the cofounder of Rancher.
- darren0 8y ago
  I don't mean to push an anti-k8s agenda. What I'm pointing out is that people have conflated the value of containers with the value of orchestration and clustering. They don't need to go hand in hand. Containers without orchestration has been proven to save money. It's hard at the moment to prove the real value of k8s. It's too early and there isn't enough adoption. When you look at most success cases of k8s they often can achieve the same benefits using an plain old docker and some auto scaling groups.
  - jrs95 8y ago
    Makes sense. I suppose in my case it’s ease of service to service communication + deployment that’s the primary benefit. Consul could easily handle the first, but deployment could be a bit trickier. Ultimately I think if GKE didn’t exist I very likely would have ended up using Nomad and Consul for simplicity’s sake. To me it seems some sort of scheduler is necessary if you want to have an easy way to control the horizontal scalability and availability of your individual containers and not just your hosts. Unfortunately setting that up isn’t nearly as well documented as setting up a k8s cluster right now, but IMO the end result is a lot easier to comprehend. The lack of end to end documentation is really what kept me away from adopting Hashicorp’s tools instead, so hopefully that will improve and k8s can have some real competition. All of this is in the context of a microservices architecture, though. Something I generally wouldn’t choose to do unless there were good reasons for it. Defaulting to a monolith is still the safer choice IMO, and if you are deploying existing monoliths, or a small number of services, then it’s very possible that you don’t have a need for an orchestrator at all.
user5994461 8y ago
>>> The value of containerizing your application is clear and has been realized over and over again. The jury is still out on k8s. The value of containerizing applications is negligible if there isn't the orchestration to go with it.
- darren0 8y ago
  Not really, the value of containers that most people have seen is that it's just a more portable package. It's easier to move between environments in a consistent way. If I do that with fancy orchestration, shell scripts, or configuration management largely doesn't matter. I can get most of the advantages with shell scripts.
  - thockingoog 8y ago
    Deploying containers is shell-script-easy as long as nothing goes wrong. Ever. I know you know this. I'm a little confused why you'd make a claim like this.
    - darren0 8y ago
      It's really true for most users. I've seen it over and over again. Working in SV we lose sight of just how simple many peoples applications are. But I'm not saying just start a server and call it good. Use auto scaling groups, and some monitoring from your cloud provider. It's typically sufficient. Some of the most successful container deployments I've seen just use terraform + AWS services (EBS, ELB, ASGs). Its simple and gets the job done, not a lot of moving parts.
      - user5994461 8y ago
        Auto scaling groups and ELB are world class orchestration. I can understand that you take it for granted if you already got that. Containers are mostly useless without orchestration. A fancy zip file that can't distribute itself. Outside of SV, the fight has never been to package applications, but to find some available servers where it can run and run it.
manigandham 8y ago
> The jury is still out on k8s Not really. There aren't any real alternatives other than the dying Docker Swarm and some overlap with Nomad and Mesos. The "war" is over, Kubernetes has come out on top and is rapidly developing both as a platform and as offerings from Google's GKE and Azure AKS. Almost all Kubernetes deployments are using a managed solution of some sort, including OpenShift and the rest, so AWS is falling behind here badly with their current offerings.
markbnj 8y ago
It's kind of a cynical position, actually, because embedded in it is the underlying contention that all of the attention the platform has gotten since 2015, the startups it has spawned, the resources being put into it by every major systems tech vendor, the doubling in size of kubecon every year for the last three years, the hundreds of how-to and in-depth articles that have been written, have all resulted from some sort of hype and anticipation of future benefits. There are thousands of nodes running production workloads right now. I've been running it in production since 2016. The value is certainly apparent to our team. Yes you can stitch a lot of it together with shell scripts and systemd or swarm or whatever. But why would you?
charles_f 8y ago
> The jury is still out on k8s. At least a jury you should trust is not - https://www.thoughtworks.com/radar/platforms/kubernetes https://www.thoughtworks.com/radar/platforms/kubernetes

jrs95 8y ago

Do you have any actual data related to this claim or am I just supposed to assume that it's true by inferring things from Amazon's cloud offerings? Edit: Sorry for the aggressive tone, I overreacted a bit because it seems like every single day there's someone pushing an anti-Kubernetes agenda on HN. Often they don't even use it, they just glanced at the docs and said "it's too complicated", or something. Clearly, this isn’t you since you’re the cofounder of Rancher.

darren0 8y ago
I don't mean to push an anti-k8s agenda. What I'm pointing out is that people have conflated the value of containers with the value of orchestration and clustering. They don't need to go hand in hand. Containers without orchestration has been proven to save money. It's hard at the moment to prove the real value of k8s. It's too early and there isn't enough adoption. When you look at most success cases of k8s they often can achieve the same benefits using an plain old docker and some auto scaling groups.
- jrs95 8y ago
  Makes sense. I suppose in my case it’s ease of service to service communication + deployment that’s the primary benefit. Consul could easily handle the first, but deployment could be a bit trickier. Ultimately I think if GKE didn’t exist I very likely would have ended up using Nomad and Consul for simplicity’s sake. To me it seems some sort of scheduler is necessary if you want to have an easy way to control the horizontal scalability and availability of your individual containers and not just your hosts. Unfortunately setting that up isn’t nearly as well documented as setting up a k8s cluster right now, but IMO the end result is a lot easier to comprehend. The lack of end to end documentation is really what kept me away from adopting Hashicorp’s tools instead, so hopefully that will improve and k8s can have some real competition. All of this is in the context of a microservices architecture, though. Something I generally wouldn’t choose to do unless there were good reasons for it. Defaulting to a monolith is still the safer choice IMO, and if you are deploying existing monoliths, or a small number of services, then it’s very possible that you don’t have a need for an orchestrator at all.

user5994461 8y ago

>>> The value of containerizing your application is clear and has been realized over and over again. The jury is still out on k8s. The value of containerizing applications is negligible if there isn't the orchestration to go with it.

darren0 8y ago
Not really, the value of containers that most people have seen is that it's just a more portable package. It's easier to move between environments in a consistent way. If I do that with fancy orchestration, shell scripts, or configuration management largely doesn't matter. I can get most of the advantages with shell scripts.
- thockingoog 8y ago
  Deploying containers is shell-script-easy as long as nothing goes wrong. Ever. I know you know this. I'm a little confused why you'd make a claim like this.
  - darren0 8y ago
    It's really true for most users. I've seen it over and over again. Working in SV we lose sight of just how simple many peoples applications are. But I'm not saying just start a server and call it good. Use auto scaling groups, and some monitoring from your cloud provider. It's typically sufficient. Some of the most successful container deployments I've seen just use terraform + AWS services (EBS, ELB, ASGs). Its simple and gets the job done, not a lot of moving parts.
    - user5994461 8y ago
      Auto scaling groups and ELB are world class orchestration. I can understand that you take it for granted if you already got that. Containers are mostly useless without orchestration. A fancy zip file that can't distribute itself. Outside of SV, the fight has never been to package applications, but to find some available servers where it can run and run it.

manigandham 8y ago

> The jury is still out on k8s Not really. There aren't any real alternatives other than the dying Docker Swarm and some overlap with Nomad and Mesos. The "war" is over, Kubernetes has come out on top and is rapidly developing both as a platform and as offerings from Google's GKE and Azure AKS. Almost all Kubernetes deployments are using a managed solution of some sort, including OpenShift and the rest, so AWS is falling behind here badly with their current offerings.

markbnj 8y ago

It's kind of a cynical position, actually, because embedded in it is the underlying contention that all of the attention the platform has gotten since 2015, the startups it has spawned, the resources being put into it by every major systems tech vendor, the doubling in size of kubecon every year for the last three years, the hundreds of how-to and in-depth articles that have been written, have all resulted from some sort of hype and anticipation of future benefits. There are thousands of nodes running production workloads right now. I've been running it in production since 2016. The value is certainly apparent to our team. Yes you can stitch a lot of it together with shell scripts and systemd or swarm or whatever. But why would you?

charles_f 8y ago

> The jury is still out on k8s. At least a jury you should trust is not - https://www.thoughtworks.com/radar/platforms/kubernetes https://www.thoughtworks.com/radar/platforms/kubernetes