After we make that work we will integrate Crossplane in Auto DevOps  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.
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).
My startup Meshcloud  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.
I really don't like the latter in comparison to the former, tbh.
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
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.
Isn't Terraform already cross-cloud?
Terraform is a popular tool for provisioning infrastructure across cloud providers. It offers a declarative configuration language with support for templating, composability, referential integrity and dependency management. Terraform can dynamically provision infrastructure and perform changes when the tool is run by a human. Unlike Crossplane, Terraform does not support workload portability across cloud providers, and does not have any active controllers that can react to failures, or make changes to running infrastructure without human intervention. Terraform attempts to solve multicloud at the tool level, while Crossplane is at the API and control plane level. Terraform is open source under a MPL license, and follows an open core business model, with a number of its features closed source. We are evaluating whether we can use Terraform to accelerate the development of resource controllers in Crossplane.
Blog posts often lead me to wonder what the product is, so it should be convenient to find out.
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.
> 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?
in that world the developer plays admin too, and can configure crossplane as an admin.
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.
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?
The AWS Service Operator is a recent project that implements a set of Kubernetes controllers that are able to provision managed services in AWS. It defines a set of CRDs for managed services like DynamoDB, and controllers that can provision them via AWS CloudFormation. It is similar to Crossplane in that it can provision managed services in AWS. Crossplane goes a lot further by offering workload portability across cloud multiple cloud providers, separation of concern, and a scheduler for workload and resources.
The advantage of this model is that an application requests the "Large and Slow Disk Class" not knowing how it works on each environment and a cluster owner then describes how to configure a spinning disk EC2 Storage to fulfill this class.
So, the AWS Operator lets people use the Kubernetes APIs to configure AWS resources. But, if you use those APIs directly in say your Helm chart then your app won't be able to be configured and deployed on other cloud providers without editing those objects.
Is it important to your application to be loosely coupled to the cloud provider? Then you need this sort of abstraction to enable portability. It sort of continues the Kubernetes vision beyond computer/network/storage into other cloud services like databases/serverless/AI/etc.
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.