Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource Type Providers #170

Closed
wants to merge 1 commit into from
+75 −0
Closed

Resource Type Providers #170

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions text/0158-resource-type-providers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
---
feature name: resource-type-providers
start date: 2020-06-07
rfc pr: [#170](https://github.com/aws/aws-cdk-rfcs/issues/170)
related issue: [#158](https://github.com/aws/aws-cdk-rfcs/issues/158)
---

# Summary

With the AWS CloudFormation registry being publicly available (news [here](https://aws.amazon.com/about-aws/whats-new/2019/11/now-extend-aws-cloudformation-to-model-provision-and-manage-third-party-resources/)), we now have an alternative to CloudFormation custom resources. The main benefit being how they can be easily packaged and shared while the compute is being fully managed by AWS CloudFormation.

# Background

A few reference documentation to help with the discussion:
* CloudFormation custom resources: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html
* CloudFormation resource types: https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/resource-types.html
* Explanation of difference between custom resource and resource types: https://aws.amazon.com/blogs/mt/managing-resources-using-aws-cloudformation-resource-types/

# Motivation

The motivation behind this RFC are:

## Reduce Footprint

As describe in CDK documentation [here](https://docs.aws.amazon.com/cdk/api/latest/docs/core-readme.html#custom-resource-providers), the resources implemented using the custom resource provider framework will have a large footprint. This means that provider framework itself will deploy many AWS resources to the customer account.

By moving those resources (lambdas, etc) to the AWS CloudFormation service itself, we will simplify the management for the customer by hidding the complexity.


## Separate Providers Source Code from CDK

Right now the custom resource providers source code is somewhat coupled with the @aws-cdk itself. It means that the whole CI/CD pipeline for CDK project will be triggered whenever you make any change to the provider's source code.

With the resource types approach, their source code will have their own development lifecycle. They could/should even be moved away from the main @aws-cdk libray folder so they can be separately versioned and packaged. Another important point is that the provider framework will also not be managed by the CDK community anymore, but by the support library provided by the CloudFormation team (more information [here](https://github.com/aws-cloudformation/cloudformation-cli#supported-plugins)).


## Share CloudFormation native resource

Because of the nature of the custom resources developed within the CDK project, they are not easily shared among CloudFormation natively.

On the other hand, the main purpose of resource type is to be native to CloudFormation. So other people will be able to consume the resource types even if they are not currently using CDK.


# Basic Example



# Design Summary



# Detailed Design



# Drawbacks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main drawback as far as I see it is that if we release those custom resources to the registry it means their APIs become public APIs that we must maintain with backwards compatibility, versioning and assurances we are not set out to provide.

The benefit of embedded custom resources is that they can be treated as an "implementation detail" of the construct, and the API stability can only be managed at the construct level.

In a sense every public registry resource is a fully fledged service that must be maintained from an API perspective, and I doubt that we have the bandwidth to do that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed and I thought of pointing out that this should initially be implemented for single versioned services in mind. So services somewhat "static" (like IAM OIDC provider, DNS certificate validation, etc) can be easily migrated, but not for "dynamic" services (like EKS cluster creation, etc).


* Resource types are not widely adopted yet
* TypeScript (Node.js) plugin is not being supported by AWS

# Rationale and Alternatives



# Adoption Strategy



# Unresolved questions



# Future Possibilities

With the possibility of making the CDK resource types public (probably in the future), the way the versions of the multiples resources will be managed by the CDK team. Therefore, the customer would not even have to worry about registering them, but just consume it. Possibly, they would be able to consume different resource versions in a single account.