aws-cdk-rfcs
aws-cdk-rfcs copied to clipboard
aws
RFC 419: CDK Launchpads
This is a request for comments about "CDK environment setup for platform/system administrators" (a.k.a. CDK Launchpads). See #419 for additional details.
APIs are signed off by @rix0rrr.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license
Apologies for possibly very early questions but:
-
Is Launchpads something that's provisioned via CloudFormation as a first class resource? Both the cmd and the integration into AWS Organizations make it kind of vague how Launchpads are actually implemented (thought it looks like thats an open question mentioned in the RFC)
-
I would echo the concern here, but from the consumer side in there's a worry that Launchpad may lag behind the CDK project itself (bootstrap) or slow CDK's velocity
Integrating with AWS Organizations, and having a presence in the AWS Console, will require owning server-side components. Maintaining them will put additional strain on the CDK team.
- For this part: https://github.com/aws/aws-cdk-rfcs/blob/cdk-launchpads/text/0419-cdk-launchpads.md#importing-the-launchpad-in-cdk-code. Out of curiosity, why is getting the environmental launchpad an import and not a lookup?
Wanted to say I'm extremely bullish about this! Centrally bootstrapping as well as allowing multiple team/persona specific "launchpads" would/will be amazing for easing team dev and setting up gaurdrails
Apologies for possibly very early questions but:
No worries - this is exactly the time to ask those questions!
- Is Launchpads something that's provisioned via CloudFormation as a first class resource? Both the cmd and the integration into AWS Organizations make it kind of vague how Launchpads are actually implemented (thought it looks like thats an open question mentioned in the RFC)
No. A Launchpad would be represented as a CloudFormation Stack (and possibly some extra data, like the Compliance rules, stored in something like S3, most likely using simple JSON/YAML files).
- I would echo the concern here, but from the consumer side in there's a worry that Launchpad may lag behind the CDK project itself (bootstrap) or slow CDK's velocity
I wouldn't be concerned about lagging behind bootstrap (we would share the code, so that it wouldn't be duplicated), but the second concern is definitely valid.
Integrating with AWS Organizations, and having a presence in the AWS Console, will require owning server-side components. Maintaining them will put additional strain on the CDK team.
- For this part: https://github.com/aws/aws-cdk-rfcs/blob/cdk-launchpads/text/0419-cdk-launchpads.md#importing-the-launchpad-in-cdk-code. Out of curiosity, why is getting the environmental launchpad an import and not a lookup?
Because we want to generate code based on the Launchpad, not force the CDK application users of the Launchpad to import things directly (you could do that of course, it would just be a worse experience).
Wanted to say I'm extremely bullish about this! Centrally bootstrapping as well as allowing multiple team/persona specific "launchpads" would/will be amazing for easing team dev and setting up gaurdrails
Glad you like it, that's what we're hoping for 🙂.
Thank you for the great answers!
Because we want to generate code based on the Launchpad, not force the CDK application users of the Launchpad to import things directly (you could do that of course, it would just be a worse experience).
For this, is the intent that each application would generate it's own binding code? Or is something that could be generated and shared via, say, an NPM library? I just worry about adding extra steps or something that can easily get out of sync for consuming devs.
Edit: I guess you sort of cover the out of sync bit here
Additionally, importing the Launchpad in that way will produce a warning during cdk deploy if the version of the Launchpad in your environment is older than the current latest version of the Launchpad, and will ask you to update.
but I still worry about it being an extra concern for devs (albiet a small one for it's value add)
You definitely could generate it once, and then publish as an NPM library. The complicated part is that you most likely want to make it company-private, as it will be very specific to the way your environment operates. It won't be useful to the entire open-source community. That complicates things a little bit, but there are ways of handling that (like using npmjs.com's private registries, or something like CodeArtifact).
You definitely could generate it once, and then publish as an NPM library. The complicated part is that you most likely want to make it company-private, as it will be very specific to the way your environment operates. It won't be useful to the entire open-source community. That complicates things a little bit, but there are ways of handling that (like using npmjs.com's private registries, or something like CodeArtifact).
Ah, to be clear we do this today to share opinionated constructs and company specific helpers today via a private NPM registry. So not to worried about that, just that it'd be feasible.
@eladb thanks a lot for the review! I've included most of your comments, let me know if this makes sense!
Hey There, just as a extra perspective I would like to emphasize on the custom bootstrapping points. We as a team kinda built this ourselves with tranforming the bootstrapping template to cdk and having a permission boundary aspect. We would love to have this natively in cdk!
