Live data from Hacker News

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

techcrunch.com

51–60 of 83 posts

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

#52
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]…

Precisely, the dependency we're talking about here is "just" leveraging Kubernetes as a generic extensible control plane which makes it quite convenient to plug into for management of resources.

+1 we really wanted to leverage the ecosystem and have something that is immediately familiar when we decided to use kube-apiserver (and etcd) for crossplane. I think the K8S resource model [1] goes well beyond container orchestration

[1] https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRf...

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

#53

Earlier quoted context omitted.

Yea absolutely. Check out the hellohelm bundle for a simple example: https://github.com/deislabs/bundles/tree/master/hellohelm and the Bitnami Wordpress + Amazon RDS bundle for one with multiple components: https://github.com/bitnami/cnab-bundles/tree/master/wordpres...

What would be the advantage over just using helm directly? (not a criticism, I'm not a big helm user for now, just kubectl but would like to know the difference for future project). Do you plan to integrate CNAB into kubernetes directly so we can bypass helm in the future?

If you're only using Kubernetes, straight Helm might be a better fit.

But imagine you need to run your Helm chart on Kubernetes environment that doesn't have access to your container images. You could build a thick bundle from your Helm chart, put it on USB stick, sneaker-net it over to a disconnected Kubernetes cluster, hydrate a container registry and run the Helm chart with full fidelity in the new environment.

This is just one thing CNAB enables..

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

#54
post #35
post #4

Gabe from Microsoft here. Happy to answer any questions. A few links to help you explore the spec and tooling: - https://cnab.io - https://duffle.sh/ - https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...

Thank you for being here and answering questions. Is there any way you can (internally) push to remove roadblocks for the insanity of Windows Home vs Pro for Docker/Hyper-V? I know this isn't possible in the short run but I think it prevents a lot of children from getting started with Docker. Based on what Scott Guttrie's team has been able to accomplish, I am cautiously optimistic that this is possible if there is e…

If you want to play the "think of the children" card, then let's start by discouraging development on Windows.

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

#56
post #54
post #35

Earlier quoted context omitted.

Thank you for being here and answering questions. Is there any way you can (internally) push to remove roadblocks for the insanity of Windows Home vs Pro for Docker/Hyper-V? I know this isn't possible in the short run but I think it prevents a lot of children from getting started with Docker. Based on what Scott Guttrie's team has been able to accomplish, I am cautiously optimistic that this is possible if there is e…

If you want to play the "think of the children" card, then let's start by discouraging development on Windows.

[deleted]

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

#57
post #43
post #4

Gabe from Microsoft here. Happy to answer any questions. A few links to help you explore the spec and tooling: - https://cnab.io - https://duffle.sh/ - https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...

How is this not just an alternative to normal Docker tools? Does it run on Linux?

> How is this not just an alternative to normal Docker tools?

From my understanding, you've got Docker for defining your app's services, you've got Kubernetes for orchestrating them, you've got Terraform et al. for defining/configuring your infrastructure, and now you've got CNAB/Duffle to bring all these tools and configs together under one umbrella.

> Does it run on Linux?

From the article[1] posted above:

> By design, it is cloud agnostic. It works with everything from Azure to on-prem OpenStack, from Kubernetes to Swarm, and from Ansible to Terraform. It can execute on a workstation, a public cloud, an air-gapped network, or a constrained IoT environment.

[1] https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...

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

#58
NOTE: THIS HEADLINE DOES NOT MEAN THAT DOCKER WORKS IN WINDOWS

I have spent all day today trying to switch from running Docker in a Vagrant to running Docker for windows and can say without question that Docker and Windows are incompatible as of today.

Specific issues are numerous, but primarily it is slow, and has stupid defaults, volumes will drive you nuts, don't use with cygwin or Ubuntu for Windows either (volumes won't work) and expect everything to crash your terminals.

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

#59
post #54
post #35

Earlier quoted context omitted.

Thank you for being here and answering questions. Is there any way you can (internally) push to remove roadblocks for the insanity of Windows Home vs Pro for Docker/Hyper-V? I know this isn't possible in the short run but I think it prevents a lot of children from getting started with Docker. Based on what Scott Guttrie's team has been able to accomplish, I am cautiously optimistic that this is possible if there is e…

If you want to play the "think of the children" card, then let's start by discouraging development on Windows.

I would discourage development for Windows but not necessarily on Windows. I develop on Windows and deploy to Linux all of the time. I also have started using the Linux subsystem for Windows.

I’ve been developing for and on Windows for over 20 years. The “Windows Tax” didn’t become a concern of mine until I started using cloud providers. The cost of Microsoft’s licenses was someone else’s problem.

But, when every resource you use is tagged and it’s very clear how much you’re spending on an implementation, the double hit of Windows becomes real. First you pay more for Windows VMs than the same size Linux VMs and then you need more resources.

I can do a lot with a 256Mb-512Mb RAM Linux VM. I at least need 4GB of RAM for Windows and that’s stretching it.

On the other hand, I still love .Net Core but it’s not getting the uptake that Node is or even Java - yes that makes me sad.

Post reply on HN