When microservices applications are packaged and deployed in a cluster, they are designed with tenets to be separate services, scaled independently to run multiple instances, deployed repeatedly in various environments. The services need configuration data that are typically defined as property attributes such as environment-specific, secrets, external URLs, parametrized attributes, etc., that can undergo change.
When the services are packaged and deployed with configuration files, it introduces tight coupling, limits the possibility of sharing, editing, managing, versioning, auditing, and may often require deployment downtimes.
Externalized Configuration Store Pattern suggests the approach to move the configuration out of the services, maintain them in an external, centralized data store that offers the flexibility to version, scale, configure various formatted properties, secure and can provide fine-grained access control mechanisms. The services may load the configuration from the Externalized Configuration Store during start up or dynamically access the parameters on-demand, without the need to redeploy and restart.
How can AWS Parameter Store help?
Microservices applications that are deployed in AWS workloads can easily implement Externalized Configuration Store Pattern by leveraging the Parameter Store that is part of the Systems Manager Service. AWS Parameter Store provides secure, hierarchical storage for configuration data management, secrets management through integration with Secrets Manager, has granular access controls, can be version controlled with labels, is highly available, scalable and no servers to manage. We can also set up event notifications to be triggered when the parameters and policies are updated.
More on parameters…
A Parameter can be stored in various formats such as a String representing key-value pair, a StringList representing comma-separated values and SecureString for sensitive data that are typically encrypted and stored as secrets.
Working with the Parameter Store
- A parameter store needs to be setup with desired IAM policies for user, groups, and access permissions. The IAM policies can be defined at a fine-grained level that defines policy actions for various access patterns on the parameters that are stored. The default free-tier quota has a limitation on the size (4 KB) and total number of the parameters (10000). Advanced settings can be leveraged for increased quota of size and count of parameters.
- Notifications can be configured to trigger events based on various actions on the parameters, using integrations with Amazon EventBridge and Amazon Simple Notification Service (Amazon SNS). Time and status-based notifications can also be set up based on the parameter policies that indicate the validity/expiry of the parameters
- Parameter hierarchies can be used to organize and manage parameters, when there are multiple parameters using the same configuration data
- Parameters can be labelled for easier maintenance and the labels can be moved between versions. They also offer the flexibility to query the parameters by their labels.
- Every parameter is versioned by default and all modifications increment the version, thus facilitating the ability to view the details, including the values, of all versions in a parameter’s history
- All activities on Parameter Store can be audited by checking the AWS CloudTrail logs
- Parameter Store has integration with Secrets Manager. Secrets can be retrieved from Secrets Manager when using other AWS services that already support references to Parameter Store parameters.
How does it compare with Environment Variables?
One common approach to externalize configurations is to use environment variables that are accessed from the runtime context. Since the environment variables are exclusive to its runtime, it is not feasible to share config values across services, cannot implement fine-grained access to sensitive data and they are not encrypted at rest. Most practical scenarios would have the need to share the configurations in a decoupled way, thus allowing other services to leverage them, and be able to update them centrally, without the need to redeploy and restart the services.
In summary, if you have microservice applications deployed in AWS workloads that can benefit from an Externalized/Centralized Configuration Store that can be managed outside of the application lifecycle, you should explore the rich feature set that Parameter Store provides to developers, operations, and security teams.
Looking forward to your comments.
