Crossplane – Open Source Multicloud Control Plane
blog.upbound.io
Crossplane – Open Source Multicloud Control Plane
1–10 of 39 posts
Re: Crossplane – Open Source Multicloud Control Plane
#2So how is this different from AWS Operator?
Re: Crossplane – Open Source Multicloud Control Plane
#3I 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.
Re: Crossplane – Open Source Multicloud Control Plane
#4So how is this different from AWS Operator?
Hi, this bassam (one of the maintainers on crossplane). We describe the relationship in our arch doc here https://docs.google.com/document/d/1whncqdUeU2cATGEJhHvzXWC9.... The following snippet is from that doc:
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.
Re: Crossplane – Open Source Multicloud Control Plane
#5I 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.
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
Re: Crossplane – Open Source Multicloud Control Plane
#6So how is this different from AWS Operator?
This looks to work similarly to the Persistent Volumes in Kubernetes. To put it into OOP language Kubernetes persistent storage is modeled as an abstract class and a set of concrete types that implement a class.
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.
Re: Crossplane – Open Source Multicloud Control Plane
#7I 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.
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
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...
Re: Crossplane – Open Source Multicloud Control Plane
#8This looks fairly similar to the new Kuberentes KEP for portable service definitions.... https://github.com/kubernetes/enhancements/blob/master/keps/...
Re: Crossplane – Open Source Multicloud Control Plane
#9So how is this different from AWS Operator?
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.
Re: Crossplane – Open Source Multicloud Control Plane
#10At 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...