kapilt
commented
2 years ago This sounds great.
There’s a lot of code in the built in deployer that feels like dead weight when adding new capabilities. One additional, the experience on the built in deployer is subpar when handling updates (it can’t do differential/partial). I’d hazard a guess this allows to drop 20-30% of the extant code in chalice.
The cdk deployment here also feels more like lip service, to say it integrates rather than providing utility. I’d suggest that facility be moved to a separate extensions/example repo as a demonstration or perhaps even reduced to documentation.
jamesls
devangmehta123
(NOTE: This is part of a set of proposals for Chalice 2.0. This proposes a backwards incompatible change that will require a major version bump.)
This is a proposal to remove the built-in (SDK based) deployer and to use either CloudFormation or Terraform (user configurable) when users run "chalice deploy".
Motivation
One of Chalice's key features is decoupling Chalice applications from how they're deployed. This allows you to choose the deployment tooling you prefer, or in some cases, the deployment tooling that your team/org has already adopted. To that end, Chalice supports these deployment backends:
So while there’s four ways of deploying your app, internally there’s really 3 because the CDK integration relies on the SAM packager.
Issues
The downside to this approach is that to implement a new feature, you have to update three deployment backends which requires knowledge of CloudFormation templates, Terraform templates, and Chalice's built-in deployer which has its own intermediate language and op codes that aren't documented. This makes contributions challenging and adds unnecessary friction to adding new features to Chalice. We often see PRs stall because of changes needed to one of the backends. Also, the built-in deployer requires the most effort by far due to it needing to manually handle all the lifecycle updates to CRUD a resource whereas that logic is handled internally by CloudFormation and Terraform.
Additionally, the built-in SDK based deployer was written years ago, and the original motivating forces for the design are not as relevant today. Consider that when Chalice was first released:
We didn't really have any choice but to write our own deployment system, there was nothing else available at the time. Fast forward to today and that doesn't make sense anymore. CFN/CDK/Terraform can handle everything we need. A deployment system is a full time, separate project in its own right and takes away dev time from Chalice framework features.
And the last issue we've run into is that the deployer has prevented us from adding certain features. Not only does the built-in deployer have to manage the lifecycle of every resource we support, but we'd need to do the same thing for every resource the user would want to create outside resources used directly by Chalice. See https://github.com/aws/chalice/issues/516 for an example of this. This proposal becomes more tenable if we only need to provide the appropriate Cfn/Terraform snippet to create resources, or potentially just let users provide their own templates to merge in.
To summarize, with this proposal we gain these benefits:
Specification
I should mention up front that this has to be done in a major version, so I’m proposing a Chalice 2.0.
deployment_bucketconfig option, Chalice will use this instead of creating a bucket in (4).The end result is that "chalice deploy" will now internally generate a template and then kick off the deployment with either CFN/terraform.
Feel free to share any thoughts/feedback you have on this. This is still in the early stages so nothing's finalized yet.