Gabe from Microsoft here. Happy to answer any questions. A few links to help you explore the spec and tooling:
- https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...
- https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...
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!
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.
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.
Windows has a lot of ways to develop for Linux/Unix now. It sure isn't FOSS, but let's not discourage a promising way to get more people into software, even if it's on Windows.
Hint- no circular arguments allowed. For example- UNIX line endings are '\n' so they are better so look UNIX is better. I mention this because I've heard this from my friends none of whom have ever programmed a raw terminal.
We actually chose not to use Docker for a group project in undergrad because some group members didn't have Windows Pro.
I'm not very familiar with Ansible, etc., so maybe tools like that have strategies for building deterministic environments, but I can see a lot of people putting `apt-get` or `yum` commands in an install script.
For example, see how you can build a CNAB using a Terraform base image: https://github.com/deislabs/bundles/tree/master/terraform
Currently, we provide developers with lab environments that wire together a small subset of containers under Docker compose for local development because running the full system is impractical. However, most of our lab environments may have important external dependencies (i.e. Slack, SMTP gateways, etc) that require configuration and often secrets.
One challenge of maintaining these lab environments is keeping these external configuration details up to date, so it would be helpful if the CNAB spec allowed configuration of this sort to be provided by an external provider similar to how Docker images themselves are expected to be provided by a container registry.
Have you anticipated this use case? If so, does CNAB have this type of support?
https://github.com/deislabs/cnab-spec/blob/master/802-creden...
EDIT: As a cloud systems architect, I view participation in CNCF as a positive signal.
I'm asking because in the Ansible example in https://github.com/deislabs/bundles/blob/master/ansiblebase/... I see AZURE_TENANT AZURE_CLIENT_ID AZURE_SECRET AZURE_SUBSCRIPTION_ID but nothing for other clouds.
Would you have to add configuration for every cloud you have to support?
It seems that in this context cloud agnostic means any cloud can be supported.
I'm interested in application portability [0]. To do this with CNAB you need to add every cloud to the bundle. This is contrast to something like Crossplane [1] that intents to support multi-cloud with a single specification.
0. https://medium.com/gitlab-magazine/multi-cloud-maturity-mode...
I get the specification is cloud agnostic. But it looks like the developer needs to write the underlying code to provision and maintain the application on the various clouds. It feels like a too thin abstraction. And it seems pretty leaky currently; the examples all have hard and specific requirements e.g. Azure, k8s etc.
What am I missing? Is the idea that we will create tooling to automatically create the provisioning and maintenance code?
Does it run on Linux?
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-...
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..