Crossplane Support

[Cliftonz]

Use Case

As infrastructure as code (IaC) continues to transform how organizations deploy and manage their infrastructure, there is a significant push towards more integrated and developer-friendly environments. Currently, developers managing Kubernetes infrastructure, especially those constructing entire control planes with Crossplane, must often work with multiple tools and languages, including YAML, Go, JSON, Helm, ytt, kustomize, thema, and cuelang. This can be cumbersome and detracts from the development experience, particularly for those who are not familiar with these formats or who prefer more concise and expressive programming languages.

By enabling Winglang to compile directly to Crossplane-compatible code, developers can leverage a single, more comfortable language to define entire control planes on Kubernetes. This capability dramatically simplifies the management of complex cloud resources and multi-cloud environments by abstracting the underlying implementation details and allowing developers to focus more on the business logic and less on the intricacies of Kubernetes resource definitions.

Winglang's expressive syntax and type-safe characteristics make it an ideal candidate for this role. It enables developers to:

• Define and manage complex resource dependencies: Developers can easily specify and handle the dependencies between various infrastructure components, ensuring that resources are deployed and managed in a reliable and predictable manner.
• Streamline the development process: By using Winglang across the board, teams can maintain consistency in their codebases, reducing the cognitive load and minimizing context switching between different languages and tools.
• Improve readability and maintenance: Winglang's cleaner syntax compared to verbose YAML or JSON significantly enhances the readability and maintainability of the code, making it easier for new team members to understand and for existing members to manage.

This enhancement not only makes Winglang a more versatile tool within the Kubernetes ecosystem but also promotes its adoption among developers who prefer its user-friendly syntax and robust features. The ability to define full control planes without leaving a comfortable and familiar programming environment is a powerful incentive for adopting Winglang in cloud-native development projects.

Proposed Solution

The proposed solution involves the following key steps:

Type Conversion:

• Develop a converter to translate Go Kubernetes and Crossplane types into TypeScript definitions. This will ensure that Winglang can interact with Kubernetes APIs and Crossplane resources accurately.
• Utilize existing tools like c2ts or develop a custom parser that can handle the specifics of Kubernetes and Crossplane APIs to generate TypeScript types and interfaces.

Compiler Extension:

• Extend the Winglang compiler to include a backend that targets the TypeScript transpiler, enabling the conversion of Winglang syntax into TypeScript code that interacts with Kubernetes and Crossplane.
• Implement additional syntactic constructs in Winglang if needed, to support declarations and management of Kubernetes resources and Crossplane custom resources (CRDs).

Integration Testing:

• Set up a testing framework to ensure that the compiled TypeScript code correctly interfaces with Kubernetes and Crossplane APIs.
• Include end-to-end tests that deploy resources on a Kubernetes cluster to verify the functionality and correctness of the compiled outputs.

Documentation and Examples:

• Provide comprehensive documentation on how to use Winglang to manage Kubernetes and Crossplane resources.
• Create a repository of example projects and code snippets that demonstrate the use of Winglang in various scenarios involving Kubernetes and Crossplane.

Implementation Notes

Implementation Notes:

• Dependency Management: Careful management of dependencies will be crucial, especially concerning the specific versions of Kubernetes and Crossplane APIs that are supported. This will require analyzing providers on the upbound marketplace.

• Handling Eventual Consistency: Crossplane operates on an eventual consistency model, where the state of the system is not immediately reflected after a command is issued. This requires careful handling in Winglang's compilation strategy. The compiler must be designed to effectively manage and track the state changes that occur over time within the Kubernetes environment. Implementing logic in Winglang to poll and verify the status of resources after they are deployed will be critical to ensure that the desired state is achieved and maintained.

• State Interpretation and Feedback: Since Crossplane does not provide execution plans like some other infrastructure as code tools, Winglang will need to incorporate its own mechanisms to predict and interpret the outcomes of deployments on Kubernetes clusters. This might involve generating logs or other outputs that provide users with detailed feedback on the deployment process, potential discrepancies, and how they are resolved over time.

• Resource Status Tracking: Enhancing Winglang to include features that can interpret and manage the lifecycle of Kubernetes and Crossplane resources will be essential. This could involve integrating with Kubernetes APIs to fetch resource statuses or subscribing to event streams that notify the system of changes in resource states. Winglang could then provide users with real-time feedback on the status of their deployments, helping them manage their infrastructure more effectively.

• Error Handling and Rollbacks: Given the asynchronous nature of resource management in Kubernetes and Crossplane, robust error handling mechanisms will need to be implemented. This includes providing strategies for rollback or remediation when deployments do not proceed as expected. Winglang could offer built-in support for rollback strategies that automatically revert changes in the event of failures, based on predefined policies or user input.

• Continuous Monitoring and Adjustment: Winglang should include capabilities for continuous monitoring of resource states to ensure that the infrastructure remains in the desired state over time. This includes detecting drift from the desired state and automatically applying necessary adjustments. Implementing these features will help ensure that the infrastructure managed by Winglang remains robust and stable even as underlying conditions change.

Component

Compiler

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.
• If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out on the #dev channel in the Wing Slack.

[eladb]

@Cliftonz I ❤️ this idea! It came up a few times in the past and we really appreciate the write up!

Curious if this is something you'd be interested to help out with? We don't have much experience with Crossplane and we would love to help out get this off the ground, especially if there's a concrete use case in mind.

Technically, I think this won't be too difficult to support and might not require as much heavy lifting as you might think. I think Wing can simply synthesize K8S YAML that includes Crossplane resources, and we should be able to reuse the logic we have in our cloud library to produce AWS/GCP/Azure resources for the cloud APIs.

So basically adding a new platform for cp-aws, cp-gcp and cp-azure! Exciting times!

[Cliftonz]

I can help with getting you guys getting off of the ground and giving advise but I do not have the space to actually implement anything.

I would recommend reaching out to upbound.io they should be able to help and may be willing to help further and provide better resources.

[github-actions]

Hi,

This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days.
Feel free to re-open this issue when there's an update or relevant information to be added.
Thanks!

[Cliftonz]

Keep open