Replacement update strategy

[laardee]

Modification of specific parameters of the resources requires replacement. In that case, the resource has to be removed and then created again with a new configuration. These resources might also have dependencies which need to be recreated after that. One example is VPC and subnets.

If VPC CIDR is changed, it requires a recreation of the resource, but if it has associated subnets, the VPC cannot be removed before subnets. Some other resources, like route table association, etc. can have a dependency on subnets. At the same time, there can be a security group which also depends on VPC and needs to be replaced with a new one on VPC change.

In this case, the update flow would be

1. Create a new VPC with updated CIDR
2. Create new subnets and security group
3. Create a new route table association
4. Remove the old route table association and security group
5. Remove the old subnets
6. Remove the old VPC

Because of this kind of dependency, the components cannot handle the replacement by themselves.

Each component should have a function that returns a boolean value that can be used to calculate the replacement order. In the type-system branch, it was called shouldDeploy.

Own addition to this brings the named resources. Most of the named AWS resources cannot be created with the same name as ones that are already deployed (ARNs may use the name as the last part), which means that the resource should be removed before creating a new one with the same name. That is not an optimal solution with production resources :grimacing: This is probably one reason why CloudFormation adds random hash postfix to some resources.

Here, in the PR description, are the initial findings that I had about this on last autumn https://github.com/serverless/components/pull/285

[laardee]

@pmuens this is what I was talking about earlier @eahefnawy @ac360 I think this is somewhat an important feature that should be implemented

[eahefnawy]

@laardee that makes sense. Is this issue only present when using components declaratively? What if you're using those components you mentioned programmatically, then you'd have more control over the ordering, no?

[laardee]

@eahefnawy sorry for the delayed response. Programmatically, I think the handling removal order might be easier. The update is still complicated as the new components should be deployed before the removal of the old ones.

Do you think users would mind if the defined named would have postfix in this kind of cases? At least I would rather have my resources named with postfix than have a production downtime.