Live data from Hacker News

Microsoft and Docker team up to make packaging cloud-native applications easier

techcrunch.com

81–83 of 83 posts

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#81

Earlier quoted context omitted.

Absolutely! You can find some example bundles here: https://aka.ms/example-bundles

Here is also a video of us running through some examples to give you a high level walkthrough of CNAB https://www.youtube.com/watch?v=26e5-UK4YRA

You can find some preview binaries of docker-app with CNAB support as well as a few simple examples at https://github.com/docker/app#cnab-support-preview

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#82
post #26
post #24

Earlier quoted context omitted.

I see it a bit differently. To me it looks like CNAB invents a new way of describing and deploying an application that looks nothing like a Kubernetes API while Crossplane is trying to use the existing Kubernetes API tooling to interoperate with and leverage that ecosystem. Just because you are using a Kubernetes API doesn't mean you are presuming a Kubernetes cluster IMHO. The work being done with virtual kubelet[1]…

As I said, we have lots of customers who need a packaging format that targets clouds APIs which in some cases don't have any containers (hence no need for Kubernetes). Functions + datastore + service bus being a good example. I know there's lots of love for Kubernetes, containers, and operators -- with me too. Still we can't and shouldn't presume the existence of Kubernetes or Kubernetes APIs to solve the problems CN…

[deleted]

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#83
post #26
post #24

Earlier quoted context omitted.

I see it a bit differently. To me it looks like CNAB invents a new way of describing and deploying an application that looks nothing like a Kubernetes API while Crossplane is trying to use the existing Kubernetes API tooling to interoperate with and leverage that ecosystem. Just because you are using a Kubernetes API doesn't mean you are presuming a Kubernetes cluster IMHO. The work being done with virtual kubelet[1]…

As I said, we have lots of customers who need a packaging format that targets clouds APIs which in some cases don't have any containers (hence no need for Kubernetes). Functions + datastore + service bus being a good example. I know there's lots of love for Kubernetes, containers, and operators -- with me too. Still we can't and shouldn't presume the existence of Kubernetes or Kubernetes APIs to solve the problems CN…

"Functions + datastore + service bus" - that can be easily expressed in an ARM template. Why the need for CNAB..?
Post reply on HN