You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see many places where splitting your application into multiple stacks (e.g service-oriented) is a recommended pattern. The main reason for me being faster deployment times for development and the stack limit of 500 resources (which, granted, could be solved partially with nested stacks).
Naturally, cross-stack references is then also a recommended pattern. I see some people arguing for strong references using stack outputs and people using weak references
How are you avoiding downtime at deployment when changing resources in a multi-stack application? Three cases that concern me are:
(R is some resource (e.g lambda function) owned by the producing stack and consumed by the consuming_ stack)
1) Remove R from the producing stack (e.g no longer used) Weak reference: If the producing stack is deployed first the resource consuming R would have downtime until the consuming stack is updated Strong reference: You'd be forced to remove references to R from the consuming stack first (i.e a 2-step-deployment).
2) Rename R in the producing stack (Refactor) Weak reference: Assuming R is not retained, any resource consuming R will have downtime until the consuming stack is deployed? Strong reference: Not sure if this is allowed?
3) Change the definition of R (e.g non backwards compatible code changes) Weak reference: Downtime for any consuming resource Strong reference: Downtime for any consuming resource
If an application has many stacks, the time from the producing stack has deployed and until the consuming stack is deployed is easily too significant for an application in production.
My hope is that someone has better suggestions than my own ideas of writing backwards compatible lambdas, duplicating resources and removing again in a two-step deployment process etc. And even if those are the best options, how are you even governing what kind of application changes puts you in such a situation?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I see many places where splitting your application into multiple stacks (e.g service-oriented) is a recommended pattern. The main reason for me being faster deployment times for development and the stack limit of 500 resources (which, granted, could be solved partially with nested stacks).
Naturally, cross-stack references is then also a recommended pattern. I see some people arguing for
strong references
using stack outputs and people usingweak references
How are you avoiding downtime at deployment when changing resources in a multi-stack application? Three cases that concern me are:
(
R
is some resource (e.glambda function
) owned by theproducing stack
and consumed by theconsuming_ stack
)1) Remove
R
from the producing stack (e.g no longer used)Weak reference
: If the producing stack is deployed first the resource consumingR
would have downtime until the consuming stack is updatedStrong reference
: You'd be forced to remove references toR
from the consuming stack first (i.e a 2-step-deployment).2) Rename
R
in the producing stack (Refactor)Weak reference
: Assuming R is not retained, any resource consuming R will have downtime until the consuming stack is deployed?Strong reference
: Not sure if this is allowed?3) Change the definition of R (e.g non backwards compatible code changes)
Weak reference
: Downtime for any consuming resourceStrong reference
: Downtime for any consuming resourceIf an application has many stacks, the time from the producing stack has deployed and until the consuming stack is deployed is easily too significant for an application in production.
My hope is that someone has better suggestions than my own ideas of writing backwards compatible lambdas, duplicating resources and removing again in a two-step deployment process etc. And even if those are the best options, how are you even governing what kind of application changes puts you in such a situation?
Beta Was this translation helpful? Give feedback.
All reactions