
Crossplane – Open Source Multicloud Control Plane - sytse
https://blog.upbound.io/introducing-crossplane-open-source-multicloud-control-plane/
======
sytse
At GitLab we're really excited about the vision of Crossplane. Multi-cloud
seems to be the future [0]. This is the missing technology to make that
convenient. Our first step is to work with Bassam to become the first complex
application deployed in this way. We already have a popular helm chart. But
that doesn't set you up with things like object storage and a cloud managed
databases (PostgreSQL and Redis).

After we make that work we will integrate Crossplane in Auto DevOps [1] so you
achieve application portability for the apps you make in GitLab.

The most interesting thing to me is that Crossplane works outside Kubernetes
since k8s is another service it will provision. Bassam his plan is to make
crossplane + Kube-api more tightly integrated, maybe even a crossplaned at
somepoint.

0\. [https://medium.com/gitlab-magazine/multi-cloud-maturity-
mode...](https://medium.com/gitlab-magazine/multi-cloud-maturity-
model-2de185c01dd7)

1\.
[https://docs.gitlab.com/ee/topics/autodevops/](https://docs.gitlab.com/ee/topics/autodevops/)

~~~
drieddust
What is the business model of upbound/Crossplane? Product seems to be free.

~~~
bassamtabbara
hi bassam here (CEO @ Upbound). Our business model is still firming up, but
we're thinking we would be hosting crossplanes among other things. We want the
crossplane project to be community driven (and not vendor driven) and welcome
other contributors (see our governance model).

~~~
drieddust
Thanks but aren't you worried about someone else hosting your product and
competing with you.

~~~
paulsutter
Crossplane could be one package that customers would not want to use directly
from a major cloud provider. You'd never trust AWS/Google/etc to really give
equal footing to a competitor. Separately, I'd prefer to trust the company
behind the open source software as opposed to some other upstart. So this
model may really work.

One observation: Crossplane and Upbound seem a little too unrelated of names.
Github has benefitted from being almost synonymous with git (admittedly,
Github also created the opening for Gitlab at the same time).

~~~
bassamtabbara
Great response! Regarding naming we did not want to tie the company to a
single project, not did we want the project to _feel_ like a vendor driven
project. So we went with different names completely :-)

------
jrudolph
This looks really exciting and congratulations on launching! We will
definitely be taking a look at this as it looks like a great fit to recommend
to our customers.

My startup Meshcloud [0] is helping companies manage the "organizational" side
of multi-cloud like integrating account provisioning, SSO, policies,
chargeback, quotas etc. using a declarative orchestration approach we call
"org as code" (basically infrastructure as code but for org stuff). Our
product is e.g. used by a large german car manufacturer to orchestrate
hundreds of tenants across AWS, Azure and a mix of private Clouds based on
OpenStack, Kubernetes and Cloud Foundry. Workload orchestration is obviously
the next challenge down the road for these customers, so we're currently
looking at providing good integration to tools like Open Service Broker API,
Terraform, Bosh, Spinnaker etc. Each of those solves a slightly different set
of problems but at the scale our customers are operating at they all have
their place.

0\.
[https://www.meshcloud.io/en/meshcloud/](https://www.meshcloud.io/en/meshcloud/)

~~~
whalesalad
Your comment here did a better job explaining your product than the website.

------
mfer
This looks fairly similar to the new Kuberentes KEP for portable service
definitions....
[https://github.com/kubernetes/enhancements/blob/master/keps/...](https://github.com/kubernetes/enhancements/blob/master/keps/sig-
apps/0032-portable-service-definitions.md)

~~~
dylanz
Very similar. Can someone more familiar with Crossplane/KEP comment?

~~~
ichekrygin
Hi, this is ichekrygin (crossplane maintainer). Yes, indeed. There appears to
be an overlap in general principles (even in use-case example). From what it
appears, KEP sig was "published/released" (not sure what is the right term
here) on the GitHub 3 days ago, we did not see this. However, now since it out
there, we will definitely reach out to discuss.

------
scarejunba
I thought it was going to be a cross-cloud Terraform, but it looks like it's a
bunch of presets operating on k8s? So when he asks for the DB, is he getting
an RDS/CloudSQL/whatever or is it spinning up a DB on an EKS/GKE/whatever?

I really don't like the latter in comparison to the former, tbh.

~~~
bassamtabbara
scarejunba, this bassam (one of the maintainers on crossplane).

when you ask for a DB you get an instance of RDS/CloudSQL/etc., in other words
you are using the managed services of your cloud provider.

we're just getting started with cross-cloud scenarios. would love your
feedback on
[https://github.com/crossplaneio/crossplane](https://github.com/crossplaneio/crossplane)

~~~
scarejunba
Oh, I get it. Reading the design document[0] helped greatly. Should've done
more than skim the blogpost. The definition of what you want is specified as a
custom resource that is cloud-agnostic. Then a set of cloud-specific custom
controllers are installed on a K8s instance and they control which cloud is
affected by your `kubectl apply`.

You have to set up your own k8s manually (there's no way to bootstrap), but
then it's all fun and games.

Nice. Very clever.

0:
[https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9...](https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9xdK29Er45NJeoemxebo/edit#heading=h.annq8ww6da48)

------
andrewstuart
It's a missed opportunity to link your blog back to blog.upboundio instead of
to www.upbound.io

Blog posts often lead me to wonder what the product is, so it should be
convenient to find out.

------
delf
What are the benefits of using Crossplane as opposed to Terraform?

~~~
regnerba
It seems like you would still use both. Terraform to provision your Kubernetes
cluster and other non-application specific infrastructure.

It seems like, and I have only briefly read the article, Crossplane is meant
to bring all that application specific cloud infrastructure into the same
configuration files you would use for defining you Kubernetes application.

So along with defining your ingress you define your mysql database and it gets
provisioned. This keeps all your application specific provisioning together
instead of having to use Terraform to provision your database ahead of time
and keep it in sync with the application.

------
tybit
I really like idea of separating a service’s infra requirements from it’s
infra implementation details.

> Crossplane supports a clean separation of concerns between developers and
> administrators.

If I’ve understood correctly im not sure this is the best way to sell the idea
though.

How does this work in a world where developers administer their own services?

~~~
bassamtabbara
> How does this work in a world where developer administer their own services?

in that world the developer plays admin too, and can configure crossplane as
an admin.

------
sigi45
Why do i need to configure a mysql database for a wordpress if that wordpress
always needs a mysql database?

While i really like the idea, i'm looking forward to see if we moved our
problems down to the operator code or if those configuration problems are
gone.

~~~
merlincorey
Wordpress supports MySQL or MariahDB.

Other software supports multiple database systems.

There are opinionated packages of the sort you are looking for, I think,
perhaps you would be interested in sandstorm.io?

------
mozey
So I could use this to setup a local dev env? Instead of using something like
[https://github.com/localstack/localstack](https://github.com/localstack/localstack)

------
robeastham
Anyone care to comment on whether this complements or competes with Rancher
2.0?

~~~
Aeolun
Seems to me you would run this on a Rancher 2.0 cluster, and then get
automagically provisioned databases. It extends the default kube system, and
Rancher just provides an interface to that.

------
kubletizer
So how is this different from AWS Operator?

~~~
mfer
The AWS operator targets AWS resources. You can't take them, in a general
sense, to minikube, Azure, or elsewhere. It's declarative to AWS services.

Some would call the AWS operator as a form of vendor lock-in.

I think the idea here is about using services with portable apps across cloud
provider.

