4 ms·

How many of your customers actually NEEDED kubernetes ?

k__ 7y ago
That was my first tought. Microsoft, Amazon, Google, IBM, Alibaba and maybe the rest of the small cloud providers.
antics 7y ago
Ha! I co-lead these efforts, and what I will say is that we try not to "lead the witness" here. :) So customers choose Kubernetes, and then we help them, but we don't help them to choose Kubernetes, so to speak.
MadWombat 7y ago
shrug If you have a bunch of services that you need to reliably run in containers you are going to need an orchestration of some sort. You can attempt to reinvent the wheel by doing your own or you can use an existing solution. If you are not in the mood for wheel reinventing, your choice becomes somewhat limited. You have Kubernetes, Docker Swarm, Mesos, Nomad, a few platform specific solutions like Elastic Beanstalk and maybe some more obscure candidates. If you don't like vendor lock-in, don't like living on the cutting edge and don't want to write too much code, your choices are down to Kubernetes, Swarm and Mesos.
- antics 7y ago
  [Pulumi kube co-lead here] I agree with most of this, but would go further. My experience (here and at Heptio) is that no one _chooses_ Kubernetes. They choose Docker, and then they (i.e., the infra team) effectively have to choose ECS or Kubernetes. In contrast, what most app developers want is a better `docker run`. I don't know how controversial that is, so I should say this is my conclusion from ~50 intensive customer qualification conversations in my 1.5 years at Pulumi and 1 year at Heptio. In each of these conversations I ask why the customer is moving to Kubernetes. In mid- or large-sized companies (i.e., 500+ employees) the answer is completely unwavering: Docker makes it easy to ship software without worrying too much about the host, and once you have that, having a way to schedule containers to run _somewhere_ is very useful. And that's effectively how the decision is made IME.
  - 7532yahoogmail 7y ago
    I am very much hunting for a cli, automatable method to do: - app installs - orchestration of same across multiple boxes in a cluster - cluster monitoring: detect when a task or box goes down running the service(s) elsewhere in the cluster It seems like kubernetes is incomplete with respect to these needs. Kubernetes depends on docker but neither does orchestration. In the context of this HN post what do I need. I am doing golang on 100pct Linux. Other than toolng I need for app installs the boxes themselves are provisioned by others. Here I am focused on app installs only. Any help much, much appreciated.
    - dankohn1 7y ago
      Take a look at Kubernetes, Helm, and the Cluster API.
      - Terretta 7y ago
        Can’t tell if grandparent post wants to manage apps on a cluster (see below) or apps that are a cluster (see https://cluster-api.sigs.k8s.io/ https://cluster-api.sigs.k8s.io/) If it’s letting a dev manage apps on a cluster someone else let them put apps on, while staying in dev mode, maybe devs could appreciate the cluster provisioning SREs enabling app devs with so-called GitOps or AutoDevOps approaches, prescriptivist ways of leveraging Docker, K8s, and Helm, such as: https://www.weave.works/blog/what-is-gitops-really https://www.weave.works/blog/what-is-gitops-really https://docs.gitlab.com/ee/topics/autodevops/index.html https://docs.gitlab.com/ee/topics/autodevops/index.html
    - MadWombat 7y ago
      Kubernetes is pretty feature complete, but its focus is on containers, not naked apps. If you are willing to pack your apps into docker, kubernetes will solve the orchestration and monitoring problems. If you are not, you might want to look for something else. In particular, take a look at Nomad (https://www.nomadproject.io/ https://www.nomadproject.io/). I am not affiliated with the project in any way and at my workplace we went the kube route, but Nomad does provide an ability to orchestrate arbitrary processes across multiple hosts.
lukehoban 7y ago
We've had customers and users of Pulumi at many different sizes and stages looking at or migrating to Kubernetes - and I'd say there are a few consistent reasons we hear for making the choice to adopt Kubernetes. First, Kubernetes offers a rich, standards-based API for compute. For teams who want to deliver containerized applications, using Kubernetes allows targeting a standards API instead of a cloud-provider specific API. This up-levels the same benefit folks get with cloud IaaS solutions where they can write standard Linux applications. Now the standardized and "portable" part of their applications extends to some key parts of the compute infrastructure as well. Second, we see a ton of Cloud + Kubernetes - teams who are still taking advantage of a lot of managed services and operational benefits from AWS/Azure/GCP/etc., but want to combine that with the container orchestration and rich API of Kubernetes. This means leaving stateful workloads in managed services like Aurora or Cloud SQL, delegating auth to managed IAM services, etc. Pulumi happens to be a really nice fit for doing these together. And lastly, there's just a really active ecosystem that's building a lot of value around Kubernetes. Some of those pieces aren't yet fully mature, but directionally many teams are betting on this being where the next wave of mature cloud platform services will become available.
reilly3000 7y ago
We are going w/ Fargate for now, but the similarity in syntax may help us make the leap to k8s when we're ready.

k__ 7y ago

That was my first tought. Microsoft, Amazon, Google, IBM, Alibaba and maybe the rest of the small cloud providers.

Ha! I co-lead these efforts, and what I will say is that we try not to "lead the witness" here. :) So customers choose Kubernetes, and then we help them, but we don't help them to choose Kubernetes, so to speak.

MadWombat 7y ago

shrug If you have a bunch of services that you need to reliably run in containers you are going to need an orchestration of some sort. You can attempt to reinvent the wheel by doing your own or you can use an existing solution. If you are not in the mood for wheel reinventing, your choice becomes somewhat limited. You have Kubernetes, Docker Swarm, Mesos, Nomad, a few platform specific solutions like Elastic Beanstalk and maybe some more obscure candidates. If you don't like vendor lock-in, don't like living on the cutting edge and don't want to write too much code, your choices are down to Kubernetes, Swarm and Mesos.

antics 7y ago
[Pulumi kube co-lead here] I agree with most of this, but would go further. My experience (here and at Heptio) is that no one _chooses_ Kubernetes. They choose Docker, and then they (i.e., the infra team) effectively have to choose ECS or Kubernetes. In contrast, what most app developers want is a better `docker run`. I don't know how controversial that is, so I should say this is my conclusion from ~50 intensive customer qualification conversations in my 1.5 years at Pulumi and 1 year at Heptio. In each of these conversations I ask why the customer is moving to Kubernetes. In mid- or large-sized companies (i.e., 500+ employees) the answer is completely unwavering: Docker makes it easy to ship software without worrying too much about the host, and once you have that, having a way to schedule containers to run _somewhere_ is very useful. And that's effectively how the decision is made IME.
- 7532yahoogmail 7y ago
  I am very much hunting for a cli, automatable method to do: - app installs - orchestration of same across multiple boxes in a cluster - cluster monitoring: detect when a task or box goes down running the service(s) elsewhere in the cluster It seems like kubernetes is incomplete with respect to these needs. Kubernetes depends on docker but neither does orchestration. In the context of this HN post what do I need. I am doing golang on 100pct Linux. Other than toolng I need for app installs the boxes themselves are provisioned by others. Here I am focused on app installs only. Any help much, much appreciated.
  - dankohn1 7y ago
    Take a look at Kubernetes, Helm, and the Cluster API.
    - Terretta 7y ago
      Can’t tell if grandparent post wants to manage apps on a cluster (see below) or apps that are a cluster (see https://cluster-api.sigs.k8s.io/ https://cluster-api.sigs.k8s.io/) If it’s letting a dev manage apps on a cluster someone else let them put apps on, while staying in dev mode, maybe devs could appreciate the cluster provisioning SREs enabling app devs with so-called GitOps or AutoDevOps approaches, prescriptivist ways of leveraging Docker, K8s, and Helm, such as: https://www.weave.works/blog/what-is-gitops-really https://www.weave.works/blog/what-is-gitops-really https://docs.gitlab.com/ee/topics/autodevops/index.html https://docs.gitlab.com/ee/topics/autodevops/index.html
  - MadWombat 7y ago
    Kubernetes is pretty feature complete, but its focus is on containers, not naked apps. If you are willing to pack your apps into docker, kubernetes will solve the orchestration and monitoring problems. If you are not, you might want to look for something else. In particular, take a look at Nomad (https://www.nomadproject.io/ https://www.nomadproject.io/). I am not affiliated with the project in any way and at my workplace we went the kube route, but Nomad does provide an ability to orchestrate arbitrary processes across multiple hosts.

lukehoban 7y ago

We've had customers and users of Pulumi at many different sizes and stages looking at or migrating to Kubernetes - and I'd say there are a few consistent reasons we hear for making the choice to adopt Kubernetes. First, Kubernetes offers a rich, standards-based API for compute. For teams who want to deliver containerized applications, using Kubernetes allows targeting a standards API instead of a cloud-provider specific API. This up-levels the same benefit folks get with cloud IaaS solutions where they can write standard Linux applications. Now the standardized and "portable" part of their applications extends to some key parts of the compute infrastructure as well. Second, we see a ton of Cloud + Kubernetes - teams who are still taking advantage of a lot of managed services and operational benefits from AWS/Azure/GCP/etc., but want to combine that with the container orchestration and rich API of Kubernetes. This means leaving stateful workloads in managed services like Aurora or Cloud SQL, delegating auth to managed IAM services, etc. Pulumi happens to be a really nice fit for doing these together. And lastly, there's just a really active ecosystem that's building a lot of value around Kubernetes. Some of those pieces aren't yet fully mature, but directionally many teams are betting on this being where the next wave of mature cloud platform services will become available.

reilly3000 7y ago

We are going w/ Fargate for now, but the similarity in syntax may help us make the leap to k8s when we're ready.