Cloudformation provides several techniques to modularize your stacks such as nested stacks or exporting and importing parameters. These practices work in nearly all the cases but fail when you need to selectively delete or create specific services within your complete system, which are "tightly" coupled with stacks inter-dependencies. One of the reasons you'd want to selectively delete or create specific components to save compute cost in lower environments. A classic example can be when you want to shutdown your elasticsearch/cache services in dev/test environment esp when you are a startup and running otherwise a serverless stack.
NOTE: At the time of writing, I acknowledge that serverless elasticsearch is already released. But it still costs many times more than running a small single node ES cluster. The cost model is still not startup friendly (In dev/test).
While working with our app Dumpick, we had this exact situation. This is our architecture at a high level:
Our intention was to create a deployment in such a way where:
- Anyone can be given a "deployer" role and the person should be able to deploy the entire stack in any of our environments (Which is account level separation).
- The deployer should be able to deploy a specific set of components without impacting overall system. Thankfully SSM was for the rescue! With use of SSM it was easy to create input parameters (Instead of being tightly dependent on exporting from another stack) from SSM variable. Cloudformation stack supports SSM parameter types, such as:
AWS::SSM::Parameter::Name
AWS::SSM::Parameter::Value
AWS::SSM::Parameter::Value>
AWS::SSM::Parameter::Value
Once a upstream stack runs and creates a SSM param, another downstream stack(s) can easily make use of those params. Those downstream/upstream stacks could easily be deleted independently as well and to us, it was a huge win!
Here is one example from our scenario: Appsync makes a direct call to elasticsearch service. Not only the appsync have to have the information on the endpoint, indexes for defining relevant service role but also elasticsearch needs to know (For resource permission) about appsync/client ID etc. Before creating any of the two services, the deployment script checks if the parameters relevant to the services are available in the SSM. If not, it first creates the dependable service (by executing individual stack deployment) so the parameters are available for the dependent service(s). Deleting any of the above services (via their individual stacks) will not be an issue either.
In the next post I am looking forward to share our deployment methods and modules in as much details as possible.
References:
https://aws.amazon.com/blogs/mt/integrating-aws-cloudformation-with-aws-systems-manager-parameter-store/
https://medium.com/nordcloud-engineering/decoupling-iac-with-ssm-parameter-store-8f38feae3936
Dumpick offers a great digital platform to community to get household items for free and help improving environment. Download today, use it and let us know what you think of it.
Top comments (0)