gabrtv

> If Azure comes out with an implementation of OAM that uses their VSIs, I'll get interested.

Gabe from the Azure team.

VSIs? I'd love to understand this better.

> But I do know that on our much smaller team the back end engineers have become thoroughly comfortable with performing those tasks for their own applications with a little assist here and there from devops.

The challenge I'm wrestling with is the smaller teams you're referencing -- the ones who can write the Kubernetes YAML for Ingress, HPAs -- they aren't representative of mainstream enterprise developers. More importantly, they're not representative of the millions of new developers who we need to empower with simpler code-to-cloud solutions that are also build on a layered, industry-standard foundation (e.g. Kubernetes).

How do we empower these new developers without separating concerns and reducing cognitive overhead around ops?

Gabe from the Azure team here. I’m also the guy who founded Deis ;)

Glad you like what you see. The original Deis team worked on much of it. I’m happy to say we have a lot more innovation coming in the PaaS space.

Well said, Jacques.

Gabe from the Azure team here.

Yes that is what Mark meant. At Microsoft we care deeply about empowering ISVs — we always have. OAM is designed to allow components from an ISV to be bound to a runtime environment by a separate consumer, where the concept of traits can provide configurability for things like ingress, autoscaling, secrets management, etc.

Gabe from the Azure team here.

The sidecar pattern is shared by a service mesh, so I understand the comparison. However Dapr is focused on enabling in-IDE experiences versus intercepting and proxying networking traffic like a service mesh.

Gabe from the Azure team here.

You nailed it. We think that microservices building blocks enabled by extensible side-cars has a lot of potential. We’d love you to take it for a spin and provide some feedback on GitHub. :)

Gabe from the Azure team here.

We built OAM for you, and for your counterparts in ops who want to help you innovate faster. :)

Gabe from the Azure team here.

If you’re talking about orgs where software is tossed over the wall from dev to ops, then I agree. The goal here is to empower the internal ops function to build self-service platforms with clean interfaces so developers can do what they do best, which is write code and business logic.

Gabe from the Azure team.

+1 on YAML having its fair share of problems. I like to think of them as our collective problems, since nothing has emerged to replace YAML yet. If something does I’m certain OAM could be adapted to it.

I’ve personally seen some promising exploration of config through Turing-complete languages like TypeScript. See Pulumi.

Gabe from the Azure team here. The goal of OAM is to promote better layering of the development and operations functions inside any org. This is modeled from what we’ve learned about high-functioning teams operating Kubernetes at scale, plus what we’ve learned running services inside Microsoft.

The desire to have software engineers focus only on business logic is strong. This tends to result in the creation of an internal “platform team” that provides services to dev teams. Effectively an internal PaaS.

OAM helps enable this pattern.

Gabe from the Azure team here. We do want to promote more separation between dev and ops. Taking on too much conceptual overhead is hard for any engineer. By having developers focus on business logic and operators focus on platform concerns, both can be more productive.

Gabe here from the Azure team. Happy to answer questions about Dapr and OAM.

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

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.

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.

CNAB makes reproducibility possible by providing unified lifecycle management, packaging, and distribution. Of course if bundle authors don't take care to work around problems with imperative logic, that's a risk. In practice, we see declarative models for building bundles offer more reproducibility.

For example, see how you can build a CNAB using a Terraform base image: https://github.com/deislabs/bundles/tree/master/terraform

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.

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

Yes. See credential sets in the specification.

https://github.com/deislabs/cnab-spec/blob/master/802-creden...

Yes. The intention has always been to put CNAB and related tooling into a foundation that offers vendor-neutral IP ownership. That could be CNCF, OCI, or something else.

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

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

Helm v3. https://helm.sh/

Gabe from the Azure team here, happy to answer questions about the AKS GA. :)

Gabe here from the Azure Containers team. Happy to answer any questions about AKS and what Microsoft is doing with Kubernetes more generally!

Serverless tends to be a conflation of 3 features:

1. Invisible infrastructure

2. Microbilling

3. Event-based programming model

ACI offers 1 and 2 without forcing 3, thanks to containers.

If you need service discovery, replicas, rolling deploys, etc. ACI probably isn't for you. Check some of the experimental work we released today connecting ACI with Kubernetes: https://github.com/Azure/aci-connector-k8s

Congrats to Mies and co. on behalf of the Deis team. Always enjoyed working with you!

Best to think of Deis as a Kubernetes company. We are much more than the PaaS solution many folks know us for.