
Microsoft and Docker team up to make packaging cloud-native applications easier - kaboro
https://techcrunch.com/2018/12/04/microsoft-and-docker-team-up-to-make-packaging-and-running-cloud-native-applications-easier/
======
gabrtv
Gabe from Microsoft here. Happy to answer any questions. A few links to help
you explore the spec and tooling:

\- [https://cnab.io](https://cnab.io)

\- [https://duffle.sh/](https://duffle.sh/)

\- [https://open.microsoft.com/2018/12/04/announcing-cnab-
cloud-...](https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-
agnostic-format-packaging-running-distributed-applications/)

~~~
mcny
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 enough push for it
from within Microsoft. Thank you once again for your support!

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

~~~
scarface74
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.

~~~
nikanj
Why do you need 8x more memory for Windows? The NT kernel isn’t 8x worse than
Linux, not even close.

~~~
tialaramex
It's a philosophical difference. NT doesn't do overcommit. In theory
overcommit is dangerous (and if you decide that matters you can tell Linux not
to do it) but in practice it's usually a huge RAM saving.

If your apparent virtual size is 2.6GB but there's actually only 240MB of
resident memory, Linux will run on 256MB of RAM. NT requires enough RAM for
the entire 2.6GB plus overheads.

This is especially frustrating if you have orchestration services that would
have recovered from the unlikely event of OOM since avoiding OOM is literally
the only reason for NT's choice.

------
tjfontaine
Both crossplane[1] and CNAB are attempting to play in similar spaces,
understanding that deploying an application for the cloud (public or private)
is more than just dumping your software into an image and giving it to a
provider (be it K8s or some other IaaS/PaaS stack). There's more associated
with the application, specifically what it means to orchestrate IaaS/PaaS/SaaS
to realize your application.

But I see CNAB falling into the same trap as Helm, and many of the package
managers before them (including newer variants with things like charm/juju),
an archive with some notion of lifecycle events is not enough. Even though
it's cute that lifecycle events are encapsulated in containers making it
easier to manage their runtime dependencies.

What I think makes Crossplane's model more attractive is the notion of
building on top of Kubernetes design and leveraging things like the operator
pattern[2]. Now application stacks can do more interesting actions during
their lifecycle, which can work to preserve availability during an event (like
upgrading your application stack). Crossplane is about expanding the
management of resources beyond just containers running in your cluster, but to
any resource you can model in the K8s control plane and writing software that
can react to events related to those resources.

[1] [https://blog.upbound.io/introducing-crossplane-open-
source-m...](https://blog.upbound.io/introducing-crossplane-open-source-
multicloud-control-plane/) [2]
[https://coreos.com/operators/](https://coreos.com/operators/)

~~~
gabrtv
We are big fans of Kubernetes operators. However, taking a dependency on
Kubernetes to solve this problem is not something our customers want. CNAB
design acknowledges this, and leans on the concept of invocation images to
perform lifecycle management.

Take the example of deploying serverless functions and a cloud based datastore
(like CosmosDB) with a 3rd-party DNS service. Kubernetes operators are a poor
fit for this, as they presume the existence of a Kubernetes cluster.

~~~
philips
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]
illustrates that.

So, I guess I am confused. You have users that want to package their app in
containers, and run those containers. However, those users don't want to use
Kubernetes APIs to do it? Why?

[1] [https://github.com/virtual-kubelet/virtual-
kubelet](https://github.com/virtual-kubelet/virtual-kubelet)

~~~
gabrtv
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 CNAB is tackling.

~~~
philips
From reading the spec though it looks like everything uses containers built
from a Dockerfile:

"A bundle is comprised of a bundle definition and at least one invocation
image. The invocation image's job is to install zero or more components into
the host environment. Such components MAY include (but are not limited to)
containers, functions, VMs, IaaS and PaaS layers, and service frameworks."

So, the very first step of CNAB is to run a container. And CNAB invents a new
way of configuring, lifecycling, etc, this container image.

[1] [https://github.com/deislabs/cnab-
spec/blob/master/100-CNAB.m...](https://github.com/deislabs/cnab-
spec/blob/master/100-CNAB.md)

~~~
gabrtv
Right. We took a dependency on a container runtime and not on a container
orchestrator.

One of the examples we show is an electron app that provides a desktop
installer experience for a cloud-based distributed application. We presume a
container runtime for this.

We expect CNAB to play nicely with Kubernetes lifecycle management, but taking
a hard dependency on Kubernetes was not deemed advantageous to CNAB's design
goals.

------
busser
I was at DockerCon EU today when Matt Butcher announced this. I wondered how
CNAB would relate to existing cloud native package managers like Helm,
especially since a big part of Helm comes from Matt himself.

He told me that he and his team saw the need for something like CNAB after
finishing their work on Helm 2, but that they would keep working on Helm 3. He
also explained that Helm could be used to install some or all components of an
application bundled in CNAB format, which makes sense.

------
zapita
I’m an avid user of both docker compose and kubernetes/helm, and have been
very frustrated by the lack of interoperability between them. This looks like
it might get us there, which makes me very happy. Nice work Microsoft and
Docker.

~~~
gabrtv
Thanks! We're excited about the opportunity to align Compose and Helm with a
standard packaging/distribution/management model. Same is true for other
tooling like Terraform, Ansible, and cloud provider declarative APIs (Azure
Resource Manager, etc).

------
amirhirsch
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.

~~~
ttty
I'm using docker right now on my win 10 64bit pro

~~~
amirhirsch
Yea me too finally. Switched from running in vagrant today and it shouldn't
have felt like an achievement. It should work in cygwin and ubuntu for windows
sanely, but it doesn't and it's pretty slow and temperamental so I'm not sure
how many re-installs or restarts will be required tomorrow. We had issues with
our redis dataset being too large for the default memory allocation settings.
Here's a relevant ticket if it's running slowly for you you might get some
pointers: [https://github.com/docker/for-
win/issues/1936](https://github.com/docker/for-win/issues/1936)

------
yarrel
It's 2023. You develop on Windows, store your code on GitHub, and deploy to
Azure with Docker.

You are able to develop and deploy your code only because Microsoft allow you
to.

But it's OK, Microsoft love "Open Source".

------
AlexB138
This strikes me as possibly being somewhat similar to Habitat from Chef but,
like Habitat at launch, I'm having a hard time understanding exactly what this
does.

~~~
codereflection
I had the same thought. Seems very similar to Habitat, but I'm still fairly
confused as to where CNAB fits and what it's solving.

------
skboosh
I've been working on something similar with sugarkube[1]. It looks like it
takes a different approach and aims to solve more of the toolchain. I'd be
interested in feedback if anyone has the time...

[1][https://github.com/sugarkube/sugarkube](https://github.com/sugarkube/sugarkube)

~~~
nprateem
Can you elaborate? It's not completely clear from the README.

~~~
skboosh
Imagine you're running Wordpress on K8s. It actually needs ingress, Cert
Manager for SSL certs and a DB. Locally you might want to use MariaDB for
convenience, but in the cloud you want to use RDS.

Sugarkube lets you install everything in a single pass. In this example you'd
create several different bundles (MS call them CNABs, I call them kapps to
disambiguate them from apps which is an overloaded term). You'd create one for
nginx ingress, one for cert manager, and one for wordpress. But the wordpress
one is parameterised differently per environment to either create a MariaDB
when running locally or RDS when running in the cloud. These bundles are just
stored in a git repo.

Under the hood, Sugarkube calls Make with some predefined targets - right now
just install, but in future also destroy - and passes a bunch of environment
variables that the kapp declares that it needs. These can be loaded from a
hierarchical YAML configuration which Sugarkube reads (kind of like
hiera/puppet does). Oh, and it can template files as well.

'Make' just calls whatever you've implemented - Helm, terraform, any non-k8s
stuff you need (there's no dependency on K8s in the architecture). You can
easily drop down and ignore Sugarkube and just work directly with tools you
already know.

Sugarkube also lets you control which versions of which bundles to release to
your environments. It can support multiple live environments.

A final thing is it can also spin up clusters on a variety of backends -
minikube, kops, and in future EKS/AKS/GKE, etc.

So altogether Sugarkube gives you a complete solution for launching clusters
(ephemeral if you like), and installing your dependencies into them (all as a
single golang binary).

Check out the example project ([https://github.com/sugarkube/sample-
project](https://github.com/sugarkube/sample-project)) which launches a
minikube cluster, installs nginx-ingress, cert manager and 2 wordpress
instances backed by MariaDB, and then loads different sample data into both
databases.

It's still in preview but it can solve a real pain point around working with
K8s and deploying applications.

------
CyanLite4
How long before Microsoft buys Docker?

------
the_common_man
Is this targeted at IT or devops or developers? Also, how does this compare to
[https://cloudron.io](https://cloudron.io) ?

------
john_moscow
I smell like acquisition.

------
crsv
How do these solutions compare to something like
[https://containership.io](https://containership.io)?

~~~
bacongobbler
I'm a bit confused by your question. Would you mind expanding a bit on that
thought?

------
holografix
Is this Microsoft’s Docker compose but with packaged Docker images that get
deployed to Azure?

Ie: K8s for humans?

------
webwanderings
First thought: Helm. Second, unappealing brand name.

Is it Helm?

~~~
bacongobbler
No, it is unrelated to Helm, though the engineers working on the spec
(including myself) are Helm core maintainers.

------
013a
Does this directly compete with Helm?

~~~
gabrtv
No, in fact we view CNAB as enabling broader adoption of Helm. Some of the
first bundles we built use Helm and Kubernetes. See:
[https://github.com/deislabs/bundles/tree/master/hellohelm](https://github.com/deislabs/bundles/tree/master/hellohelm)

