6 ms·

This looks to be the beginning of the "extinguish" step from Google. They've executed the embrace, extend, extinguish playbook to a T with Docker.

bryanlarsen 8y ago
The top contributors to containerd are all from Docker.
jrs95 8y ago
Google is just one of many organizations involved in Kubernetes. If this has anything to do with embrace, extend, extinguish, it's to prevent Docker as a company from attempting to do anything like that to Kubernetes. Edit: I take that last part back. This seems to ensure that neither party can easily fuck each other over, and that's a good thing.
- stingraycharles 8y ago
  To be fair, Kubernetes was a big competitor to Docker Swarm and Docker’s own Cloud, which kind of lost the battle. One has to wonder what would have happened if Google did not build Kubernetes, which heavily embraced Docker. Sometimes it’s not all that black and white, Google seems to mainly be afraid of one competitor becoming too powerful and losing control. Android vs iPhone being another example.
  - bboreham 8y ago
    Google’s competitor here is AWS. AWS’ comparable product is ECS. ECS also lost. Roll on EKS.
    - justicezyx 8y ago
      You missed the point. It should have been the battle of Docker to take on incubate VM-based compute providers.
      - bboreham 8y ago
        Apparently I also miss your point, because I cannot parse it. Did you mean “incumbent”?
    - jimmy1 8y ago
      And the biggest reason ECS lost imo because of the poor load balancing and service discovery options. They just now released Route 53 service discovery via DNS but it might be too little too late.
      - Rapzid 8y ago
        I believe those are just symptoms of the underlying issue; AWS's closed off and slow roll development practices simply could not keep up. They tried to rectify the situation with Blox; I'm honestly not sure how that is going. When you ask about attaching EFS or EBS to services in fargate and they ask what your use case for that is... In the words of Drake; "...we gonna see."
        geerlingguy 8y ago
        Yeah, no EFS in Fargate is a deal-breaker; we manage our own nodes in ECS right now, just because we want EFS support. It was kind of too-little-too-late, same thing with Route53 DNS-based service discovery—it's annoying when you feel nickel-and-dimed into adding an (relatively expensive, IMHO) ELB/ALB per service to be able to direct requests to the backend. I'm hoping EKS will evolve a lot more quickly and stay up to date with the upstream; it would be awesome if AWS has full and stable support for all the major bits like persistent volumes (on EFS or EBS), LoadBalancers (ELBs/ALBs, hopefully more configurable someday), etc. It sounds like the beta period is over and AWS is ramping up for EKS' GA soon.
    - linkmotif 8y ago
      Huh? Why would you want one of these to win?
      - bboreham 8y ago
        I did not intend to state a wish that any of Google, ECS, AWS or EKS would “win”. I do believe EKS is a good choice for many people. As is GKS, and many similar offerings. BTW I work for a company selling Kubernetes tools and support.
    - ironjunkie 8y ago
      Hmm, Did you forget that most of Kubernetes clusters are actually deployed in AWS? Google probably got the best "managed" solution with GKE, (a close call with Azure IMO) but most people still use AWS and way more deployment happen in AWS
      - zaat 8y ago
        Close call? Seriously? GKE is a GA, production, supported platform, Azure is still far behind at the moment, in Preview with no declared planned GA date on the roadmap. https://azure.microsoft.com/en-us/roadmap/?query=container+service/ https://azure.microsoft.com/en-us/roadmap/?query=container+s...
    - verst 8y ago
      I realize that Azure isn't as popular in the US startup crowd (and certainly not on HN), but you really cannot mention EKS without also mentioning AKS which is much more mature IMHO. And ACI (Azure Container Instances) is a serverless container offering that was launched before Fargate. Beyond the Azure offering, Microsoft has also shown tremendous commitment to the Kubernetes ecosystem at large. Take a look at the many Kubernetes open source tools created by Microsoft that work with Kubernetes anywhere (!!!): [1] Helm (initially created by Deis, acquired by Microsoft) [2] Virtual Kubelet [3] Draft [4] Brigade [5] VSCode: Kubernetes Tools And more... [1]: helm.sh [2]: https://github.com/virtual-kubelet/virtual-kubelet [3]: https://github.com/azure/draft [4]: https://github.com/azure/brigade [5]: https://github.com/Azure/vscode-kubernetes-tools Disclaimer: I'm a developer advocate for Kubernetes / Linux at Azure (but a member of the community first and foremost). I've never run a Windows Container, and I don't have a single Windows VM in Azure ;) I encourage you to take a close look at the Azure offering. It's actually very awesome!
      - zaat 8y ago
        >without also mentioning AKS which is much more mature IMHO. AKS is anything but mature.It's barely working. Last month I was at Microsoft event and everyone was suppose to launch an environment. By the fifth or six environment, provisioning died and no one could provision an environment. And I mean it died globally, regardless of the region you tried to run it at. Provision time is awful even when no one is "stress testing" the provisioning engine. This is all good and acceptable, relatively, when the service state is labeled as preview, which is how it is labeled officially. Mature isn't a word to use in regards to AKS currently. The hype Microsoft advocates try to build around AKS gives the impression a highly puffed CV of a junior dev, and IMHO it is unfortunate and a wrong way to build trust. It is fine that Azure haven't yet developed state of the art kubernetes cloud service, no one except Google have, just don't claim you did if you want us to believe you when it labeled GA that we can use it for real workloads.
        verst 8y ago
        You are correct. The provisioning sucked. I will be fully transparent about that. In fact, I had the same problems myself. You can see the list of issues here [1]. That provisioning madness is actually unrelated to AKS, but it's being addressed by the team. This is one of the reasons why the service isn't GA yet. I'd say give it a try in the EastUS region, or some time after GA. Once you do have an AKS cluster up it all works well. [1]: https://github.com/Azure/AKS/issues https://github.com/Azure/AKS/issues
    - auslander 8y ago
      > ECS also lost Hmm ... Could you back this up ?
      - bboreham 8y ago
        Evidence: EKS.
  - jrs95 8y ago
    Even if there was no Kubernetes, both Mesos and Nomad seem better than Docker Swarm depending on your use case. I don't know if Docker really would have been very successful even if Kubernetes didn't exist.
  - numbsafari 8y ago
    Docker Swarm was announced ~6 mos. after Kubernetes was announced. Similarly, Kubernetes 1.0 release was 6 mos. before Swarm's 1.0 release. Personally, Docker's big mistake was killing off dotCloud so quickly instead of gradually migrating it to Docker.
  - tannhaeuser 8y ago
    I have no stake in this, and am in no position to make any judgement at all, but I'm still hesitant to conclude that K8s has "won" or something. There was a story here two weeks ago about the absurd complexity of it. All I know is that it's heavily promoted left and right, and like for most tech products this decade, big media has won the attention grab, and has been successful in creating the perception that k8s is the orchestration software most people are using or look forward to using. Not saying it isn't, but I've yet to see any figures supporting that statement. What Google is up to here is pretty clear IMHO: they want to be perceived as the go-to provider for k8s based clouds. It's not like the iPhone-vs-Android situation at all where Google's goal is to maintain influence over advertising channels rather than push Android sales per se.
    - ironjunkie 8y ago
      What google wants to do is to make their complement cheap. ie, they want to make Kubernetes an open-source de-facto solution so that people can spend more money on cloud providers.
      - raducu 8y ago
        I have a very limited experience with kubernetes, and to me it is indeed very complex (as a user). I can only imagine how complicated it would be to offer a kubernetes solution as a cloud provider. So all of the complexity works in favor of google, but as long as users actually use it, it's a fair game.
    - bonesss 8y ago
      If Google wants to be the go-to provider of clouds their open source Kubernetes strategy is pretty backwards. As it stands, though, they've got their competitors reselling their orchestration platform technology giving them platform control moreso than a selling point for their cloud. > I'm still hesitant to conclude that K8s has "won" or something Take a look at Azures container offerings (kubernetes itself or kubernetes compatible), along with the AWS equivalents. All three major cloud platforms have managed kubernetes solutions now. That doesn't mean competing orchestrators are dead, but they're hiding in their bunkers hoping that the worst is over... > There was a story here two weeks ago about the absurd complexity of it. Yeah it's absurdly complex, except when compared to the absurd rats-nest of almost-there not-quite-compatible technologies it has replaced ;) There are lighter weight solutions for lighter weight problems, but map the DevOps cycle from A to Z and Kubernetes is head-and-shoulders simpler than competing solutions. Simpler, more comprehensive, standardized, and better documented. Add in cross-cloud portability and you've got something hard to compete with.
organsnyder 8y ago
? Per the announcement, Docker Engine is also built on containerd.
- jrs95 8y ago
  Seems like more of the usual FUD that shows up on literally every post about Kubernetes regardless of the context.
waffle_ss 8y ago
But Docker created containerd to begin with...? https://www.docker.com/docker-news-and-press/docker-extracts-and-donates-containerd-its-core-container-runtime-accelerate https://www.docker.com/docker-news-and-press/docker-extracts...
- wmf 8y ago
  It sure looks like there was a plan to completely eliminate Docker and replace it with CRI-O and it looks like Docker Inc. responded to that plan by creating containerd so they could maintain some level of relevance. So yes, Docker can stay involved as long as they deliver what k8s wants, but k8s is clearly in the driver's seat now.
auslander 8y ago
> This looks to be the beginning of the "extinguish" step from Google. They've executed the embrace, extend, extinguish playbook to a T with Docker. True. Also: - email. Keeping your own server unblocked by Gmail is a loosing battle. - Web. Google AMP. Use it or get lost in search results. - Android. Try make a phone with open source Android without Google apps and licensing.

bryanlarsen 8y ago

The top contributors to containerd are all from Docker.

jrs95 8y ago

Google is just one of many organizations involved in Kubernetes. If this has anything to do with embrace, extend, extinguish, it's to prevent Docker as a company from attempting to do anything like that to Kubernetes. Edit: I take that last part back. This seems to ensure that neither party can easily fuck each other over, and that's a good thing.

stingraycharles 8y ago
To be fair, Kubernetes was a big competitor to Docker Swarm and Docker’s own Cloud, which kind of lost the battle. One has to wonder what would have happened if Google did not build Kubernetes, which heavily embraced Docker. Sometimes it’s not all that black and white, Google seems to mainly be afraid of one competitor becoming too powerful and losing control. Android vs iPhone being another example.
- bboreham 8y ago
  Google’s competitor here is AWS. AWS’ comparable product is ECS. ECS also lost. Roll on EKS.
  - justicezyx 8y ago
    You missed the point. It should have been the battle of Docker to take on incubate VM-based compute providers.
    - bboreham 8y ago
      Apparently I also miss your point, because I cannot parse it. Did you mean “incumbent”?
  - jimmy1 8y ago
    And the biggest reason ECS lost imo because of the poor load balancing and service discovery options. They just now released Route 53 service discovery via DNS but it might be too little too late.
    - Rapzid 8y ago
      I believe those are just symptoms of the underlying issue; AWS's closed off and slow roll development practices simply could not keep up. They tried to rectify the situation with Blox; I'm honestly not sure how that is going. When you ask about attaching EFS or EBS to services in fargate and they ask what your use case for that is... In the words of Drake; "...we gonna see."
      - geerlingguy 8y ago
        Yeah, no EFS in Fargate is a deal-breaker; we manage our own nodes in ECS right now, just because we want EFS support. It was kind of too-little-too-late, same thing with Route53 DNS-based service discovery—it's annoying when you feel nickel-and-dimed into adding an (relatively expensive, IMHO) ELB/ALB per service to be able to direct requests to the backend. I'm hoping EKS will evolve a lot more quickly and stay up to date with the upstream; it would be awesome if AWS has full and stable support for all the major bits like persistent volumes (on EFS or EBS), LoadBalancers (ELBs/ALBs, hopefully more configurable someday), etc. It sounds like the beta period is over and AWS is ramping up for EKS' GA soon.
  - linkmotif 8y ago
    Huh? Why would you want one of these to win?
    - bboreham 8y ago
      I did not intend to state a wish that any of Google, ECS, AWS or EKS would “win”. I do believe EKS is a good choice for many people. As is GKS, and many similar offerings. BTW I work for a company selling Kubernetes tools and support.
  - ironjunkie 8y ago
    Hmm, Did you forget that most of Kubernetes clusters are actually deployed in AWS? Google probably got the best "managed" solution with GKE, (a close call with Azure IMO) but most people still use AWS and way more deployment happen in AWS
    - zaat 8y ago
      Close call? Seriously? GKE is a GA, production, supported platform, Azure is still far behind at the moment, in Preview with no declared planned GA date on the roadmap. https://azure.microsoft.com/en-us/roadmap/?query=container+service/ https://azure.microsoft.com/en-us/roadmap/?query=container+s...
  - verst 8y ago
    I realize that Azure isn't as popular in the US startup crowd (and certainly not on HN), but you really cannot mention EKS without also mentioning AKS which is much more mature IMHO. And ACI (Azure Container Instances) is a serverless container offering that was launched before Fargate. Beyond the Azure offering, Microsoft has also shown tremendous commitment to the Kubernetes ecosystem at large. Take a look at the many Kubernetes open source tools created by Microsoft that work with Kubernetes anywhere (!!!): [1] Helm (initially created by Deis, acquired by Microsoft) [2] Virtual Kubelet [3] Draft [4] Brigade [5] VSCode: Kubernetes Tools And more... [1]: helm.sh [2]: https://github.com/virtual-kubelet/virtual-kubelet [3]: https://github.com/azure/draft [4]: https://github.com/azure/brigade [5]: https://github.com/Azure/vscode-kubernetes-tools Disclaimer: I'm a developer advocate for Kubernetes / Linux at Azure (but a member of the community first and foremost). I've never run a Windows Container, and I don't have a single Windows VM in Azure ;) I encourage you to take a close look at the Azure offering. It's actually very awesome!
    - zaat 8y ago
      >without also mentioning AKS which is much more mature IMHO. AKS is anything but mature.It's barely working. Last month I was at Microsoft event and everyone was suppose to launch an environment. By the fifth or six environment, provisioning died and no one could provision an environment. And I mean it died globally, regardless of the region you tried to run it at. Provision time is awful even when no one is "stress testing" the provisioning engine. This is all good and acceptable, relatively, when the service state is labeled as preview, which is how it is labeled officially. Mature isn't a word to use in regards to AKS currently. The hype Microsoft advocates try to build around AKS gives the impression a highly puffed CV of a junior dev, and IMHO it is unfortunate and a wrong way to build trust. It is fine that Azure haven't yet developed state of the art kubernetes cloud service, no one except Google have, just don't claim you did if you want us to believe you when it labeled GA that we can use it for real workloads.
      - verst 8y ago
        You are correct. The provisioning sucked. I will be fully transparent about that. In fact, I had the same problems myself. You can see the list of issues here [1]. That provisioning madness is actually unrelated to AKS, but it's being addressed by the team. This is one of the reasons why the service isn't GA yet. I'd say give it a try in the EastUS region, or some time after GA. Once you do have an AKS cluster up it all works well. [1]: https://github.com/Azure/AKS/issues https://github.com/Azure/AKS/issues
  - auslander 8y ago
    > ECS also lost Hmm ... Could you back this up ?
    - bboreham 8y ago
      Evidence: EKS.
- jrs95 8y ago
  Even if there was no Kubernetes, both Mesos and Nomad seem better than Docker Swarm depending on your use case. I don't know if Docker really would have been very successful even if Kubernetes didn't exist.
- numbsafari 8y ago
  Docker Swarm was announced ~6 mos. after Kubernetes was announced. Similarly, Kubernetes 1.0 release was 6 mos. before Swarm's 1.0 release. Personally, Docker's big mistake was killing off dotCloud so quickly instead of gradually migrating it to Docker.
- tannhaeuser 8y ago
  I have no stake in this, and am in no position to make any judgement at all, but I'm still hesitant to conclude that K8s has "won" or something. There was a story here two weeks ago about the absurd complexity of it. All I know is that it's heavily promoted left and right, and like for most tech products this decade, big media has won the attention grab, and has been successful in creating the perception that k8s is the orchestration software most people are using or look forward to using. Not saying it isn't, but I've yet to see any figures supporting that statement. What Google is up to here is pretty clear IMHO: they want to be perceived as the go-to provider for k8s based clouds. It's not like the iPhone-vs-Android situation at all where Google's goal is to maintain influence over advertising channels rather than push Android sales per se.
  - ironjunkie 8y ago
    What google wants to do is to make their complement cheap. ie, they want to make Kubernetes an open-source de-facto solution so that people can spend more money on cloud providers.
    - raducu 8y ago
      I have a very limited experience with kubernetes, and to me it is indeed very complex (as a user). I can only imagine how complicated it would be to offer a kubernetes solution as a cloud provider. So all of the complexity works in favor of google, but as long as users actually use it, it's a fair game.
  - bonesss 8y ago
    If Google wants to be the go-to provider of clouds their open source Kubernetes strategy is pretty backwards. As it stands, though, they've got their competitors reselling their orchestration platform technology giving them platform control moreso than a selling point for their cloud. > I'm still hesitant to conclude that K8s has "won" or something Take a look at Azures container offerings (kubernetes itself or kubernetes compatible), along with the AWS equivalents. All three major cloud platforms have managed kubernetes solutions now. That doesn't mean competing orchestrators are dead, but they're hiding in their bunkers hoping that the worst is over... > There was a story here two weeks ago about the absurd complexity of it. Yeah it's absurdly complex, except when compared to the absurd rats-nest of almost-there not-quite-compatible technologies it has replaced ;) There are lighter weight solutions for lighter weight problems, but map the DevOps cycle from A to Z and Kubernetes is head-and-shoulders simpler than competing solutions. Simpler, more comprehensive, standardized, and better documented. Add in cross-cloud portability and you've got something hard to compete with.

organsnyder 8y ago

? Per the announcement, Docker Engine is also built on containerd.

jrs95 8y ago
Seems like more of the usual FUD that shows up on literally every post about Kubernetes regardless of the context.

waffle_ss 8y ago

But Docker created containerd to begin with...? https://www.docker.com/docker-news-and-press/docker-extracts-and-donates-containerd-its-core-container-runtime-accelerate https://www.docker.com/docker-news-and-press/docker-extracts...

wmf 8y ago
It sure looks like there was a plan to completely eliminate Docker and replace it with CRI-O and it looks like Docker Inc. responded to that plan by creating containerd so they could maintain some level of relevance. So yes, Docker can stay involved as long as they deliver what k8s wants, but k8s is clearly in the driver's seat now.

auslander 8y ago

> This looks to be the beginning of the "extinguish" step from Google. They've executed the embrace, extend, extinguish playbook to a T with Docker. True. Also: - email. Keeping your own server unblocked by Gmail is a loosing battle. - Web. Google AMP. Use it or get lost in search results. - Android. Try make a phone with open source Android without Google apps and licensing.