Cloud Assembly Specification

In order to confidently design a CI/CD deployment experience that supports assets and multiple stack ordering constraints, the Cloud Assembly document format needs to be defined, at least in an initial version.

Use-cases

1. An arbitrary number of stacks, some of which may be related
   • Nested stacks, too
2. Embedded support files (for example: Runtime code for Lambda; Static assets to be loaded to S3; Docker Images; CloudFormation documents for nested stacks; AMI baking instructions; …)
   • Some of the support files may be too large to “bundle in”, so support for external storage (S3, …) may be relevant
   • Managed build steps (specific build steps for specific asset types (e.g: Python lambda bundle, NodeJS lambda bundle, Docker image, …).
     • Need to consider CodePipeline limits (can be raised, but defaults are quite low & would come in the way of un-capped step count) as well as CodeBuild billing model (aka cost implications of many fast builds versus one slower build).
   • Self-contained means it can be digitally signed, and provisioning mechanisms can be configured to refuse handling un-signed or tampered with assemblies.
3. Phasing of deployments to honor dependencies between stacks & support files
   • Through use of the CDK CLI tools
   • Using a CI/CD pipeline
4. Re-use of the exact same artifacts in several stacks (in a CI/CD environment, deploy to QA environment, run integration tests, roll forward to production environment)
5. Interaction with context (in particular, when doing CI/CD, need to handle missing context correctly).
6. Workflows similar to:
   1. Build assembly, send to QA
   2. QA tests assembly, signs it if it passes, send to release management
   3. Release management verifies assembly is signed by QA key, deploys it to production

Remarks

• Phases: build then synthesize then package then deploy.
• The output of a CDK App execution is not the Cloud Assembly, but would describe instructions on how to piece it together.

[eladb]

@hjander we are still thinking what is the best approach. At the moment, the protocol between CDK apps and the CDK CLI is a proprietary (and ugly) protocol we call the cx-api. It will serve in the short term, but we have a desire to standardize this interface and the cloud assembly was an attempt.

From our conversations with the CNAB folks, it seems like there might be an opportunity to collaborate and define a higher level standard on top of CNAB that will address the requirements of the cloud assembly.

Bottom line: at the moment, we are putting this work on hold, and we will get back to it later, most probably when we do some work on the CLI to clean it up and modularize it.

[eladb]

@hjander asks:

What will be the future direction regarding the Cloudlet/CNAB topic ?