Make easy to migrate from existing CRDs to ACK

[anoop2811]

As we evaluate possibilities and as ACK becomes full featured, I would like a easier path to migrate from other CRDs easily. This could include the following:

1. Take over existing aws assets created by custom or other generic CRDs
2. Support composed apis created from the aws resource level CRDs.
3. Support for OAM

[jaypipes]

Hi @anoop2811! I want to make it clear that it is not a goal of ACK to siphon users away from Crossplane.

ACK's mission is to facilitate the most Kubernetes-native way for users to interact with AWS managed services via the Kubernetes API and configuration language. While Crossplane does enable Kubernetes users to create infrastructure resources using the Kubernetes API/language, Crossplane has a much broader mission of enabling cross-cloud-provider workflows and multi-provider infrastructure needs.

Crossplane and ACK contributors are actually collaborating with each other, as we view the two projects as complementary, not competitive. In fact, I've been noodling around some ideas of using the ack-generate CLI tool to output Go code that follows the Crossplane object model/interfaces -- something that would eventually allow Crossplane's AWS cloud provider code to be replaced with code generated from ACK.

[anoop2811]

@jaypipes sorry meant no disrespect to crossplane, and was not intending to siphone users away from crossplane. It was more meant as a possibility to support easy migration. I will remove the mention of cross plane and make the issue generic

[jaypipes]

@jaypipes sorry meant no disrespect to crossplane, and was not intending to siphone users away from crossplane. It was more meant as a possibility to support easy migration. I will remove the mention of cross plane and make the issue generic

No need to remove the mention of Crossplane, Anoop! :) It's an important question that we've been asked a few times and figured I'd expand on the question in my answer here. I will put together a document that specifically discusses Crossplane and ACK plans.

[prasek]

(disclosure: I'm a crossplane contributor)

@jaypipes agree, the community benefits from a converged effort here (ACK + Crossplane) with ACK owning the generated Crossplane k8s resources for AWS, so you can use Crossplane to compose and publish your own infrastructure abstractions to the k8s API without writing code.

A similar question came up for Azure ASO and @frodopwns points out:
Azure/azure-service-operator#1190 (comment) Value prop over Crossplane (closed)

Your confusion is understandable!

We aren't claiming a value proposition over Crossplane but we do think the service management should be the cloud provider's responsibility and Crossplane should remain the abstraction layer. For this reason we will be looking at ways to shim ASO into Crossplane to allow them to shift this responsibility to us.

The Azure ASO team is also adapting their codegen pipeline to generate Crossplane k8s resources:
Azure/k8s-infra#253 Generating a Crossplane Provider
/cc @davefellows @matthchr @babbageclunk @theunrepentantgeek @Porges

To accelerate support for cloud providers that don't have an open source codegen pipeline, we're generating Crossplane Providers on top of the stateless Terraform providers: crossplane/crossplane#262.

With all cloud service primitives bridged into the k8s API in a consistent way, the community gets a consistent UX for managed resources across cloud providers and the ability to compose and publish their own infrastructure abstractions with Crossplane - a vendor neutral CNCF project that makes it easy to abstract, compose, and consume the cloud resources you need from the k8s API.

Looking forward to working together on this! 🚀

[resouer]

For OAM support, it already built-in with such flexibility. So as long as you can provide a CRD to represent your cloud resource, that CRD could then be referenced as workload of your OAM Component and leverage Crossplane's OAM k8s runtime to run it.

Feel free to reach us in crossplane#oam slack channel when your app is ready!

[ack-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via /~https://github.com/aws-controllers-k8s/community.
/lifecycle stale

[RedbackThomson]

For taking over existing AWS resources, I recommend reading our discussion on resource adoption. Otherwise, closing this issue.