Feedback from working on AWS Deployment #14789
Description
I recently released publish/deployment support for AWS. The feature is in preview and there are still some rough spots but I thought I would provide some feedback on the experience.
For background the deployment support is based on using AWS CDK. At a high level during the publish phase a CDK stack which is a .NET object that has a collection of constructs representing AWS resources is created and then synthesized into a JSON CloudFormation template. During deployment the CDK cli is executed pointing to the location of the synthesized output to create or update a CloudFormation stack where all of the AWS resources will be provisioned.
Aspire Parameters
Ideally I would like users to be able use Aspire parameters to provide ids of existing AWS resources. For example have an Aspire parameter to say what VPC to use. For CDK I need the parameters to be resolved at the time of synthesizing the CDK stack being done in publish. It is a restriction of CDK that all parameters have to be know at that time. But Aspire doesn't resolve parameters until deployment. Only way around this I can see is if I move all of my logic I do in publishing into deployment which I really don't want to do.
Running AppHost directly
I haven't found any documentation of running steps like publishing directly through the AppHost without the aspire CLI. I have basically do my best to reverse engineer it. I do this for some of unit/integ tests. Seems like when I do this it wants to go all the way through deployment and I only want to run up to the publishing step. I'm hoping I'm missing something with the command line parameters.
Presenting Changes
Curious if you all have thought of the UX for showing users what would change if your do an update. Sort of a dry run experience? Using the CloudFormation APIs I can generate a change list given the generated template and an existing name. I would be great to offer this information to the user somehow maybe as a separate do step but I hadn't settle on a way to present the information to the user. Wonder if the Aspire team had already had thoughts on this.
Default ProjectResource Build Step
When I added support for AWS Lambda it was tricky in that my LambdaProjectResource subclass of ProjectResource inherited the build step defined in ProjectResource. That didn't work for me because for Lambda I don't want a container I need a zip file. In that case my subclass essentially orphans the default build step and then I add my own build step that uses our Lambda packaging tool. I suspect I will have more challenges with this especially when I don't have my subclass as the hook to replace the logic. For example if/when I add support for deploying a ProjectResource to AWS Elastic Beanstalk I need a zip of the dotnet publish not a container but I won't have the subclass to replace the logic.
Multiple Compute Environments and Assignment
More of general comment because I still don't have this right yet and still learning but this APIs for figure out what resources are tied to what compute environments are confusing. At the start of publishing I look at all resources defined in the AppHost and try to apply the correct AWS publishing annotation if one wasn't already set by the user. Currently I'm just going through all of the resources in the AppHost but I know I should be excluding those that explicitly have an environment that is not the current AWS environment. But when I was looking at this last month it was really confusing how to get this list dealing with the fact that a resource may or may not have an environment set on it. I'll hopefully get back to his soon and be able to give more concrete examples.