4 ms·

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

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-multicloud-control-plane/ https://blog.upbound.io/introducing-crossplane-open-source-m... [2] https://coreos.com/operators/ https://coreos.com/operators/

gabrtv 8y ago
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 8y ago
  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
  - tjfontaine 8y ago
    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.
    - bassamtabbara 8y ago
      +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_AtnnowaRfGejw-qlKQIuLKQWlwzs/edit https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRf...
  - gabrtv 8y ago
    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 8y ago
      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.md https://github.com/deislabs/cnab-spec/blob/master/100-CNAB.m...
      - gabrtv 8y ago
jjm 8y ago
Completely agree that with cross plane one can actually build upon and move the needle forward. Not replace it.

gabrtv 8y ago

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 8y ago
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
- tjfontaine 8y ago
  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.
  - bassamtabbara 8y ago
    +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_AtnnowaRfGejw-qlKQIuLKQWlwzs/edit https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRf...
- gabrtv 8y ago
  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 8y ago
    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.md https://github.com/deislabs/cnab-spec/blob/master/100-CNAB.m...
    - gabrtv 8y ago

jjm 8y ago

Completely agree that with cross plane one can actually build upon and move the needle forward. Not replace it.