MicroServerlessLamba.NET Series – Configuration Management

This post continues my series covering the design and development of our latest server-less micro-service architecture written in .NET Core and hosted in AWS Lambda.  In this particular post we will cover how we are managing configuration data.

Configuration management is a core capability in cloud native applications and one of the 12 factors as defined by The Twelve-Factor App.

Traditional apps often stored application configuration in the source code which generally causes issues when those values need to change in various environments (local, CI, QA, PROD, etc).  These configuration values might include database names, random application settings or secrets.

AWS Systems Manager – SSM Parameter Store

Considering our services are being hosted by ASP.NET Core in AWS Lambda and AWS is our primary cloud, we wanted to leverage an AWS service instead of a building something custom or hosting a third party option.

Thankfully, the community (shout out to @KenHundley) and the .NET team at AWS has us covered with the aws-dotnet-extensions-configuration library.  The Parameter Store in AWS System Manager (SSM) is a name/value store with various features for storing parameters and configuration data.

We have used the String and SecureString types but haven’t needed to utilize the Advanced tier.  We also locked a portion of our secure string in our production environment via IAM policies to protect our most sensitive values.

We also leverage the parameter path to create a hierarchy of parameters at different levels (account, environment, app, etc.), as well as make shift service registry (more to come in a future post).  We have found SSM parameters to be quite flexible for our needs.

Other Settings

After creating several hundred parameters and using them across many microservices with great success, we started see errors sporadic which indicated we were getting parameters to often.  After some research we found we needed to remove the throughput limit.  There is a charge for this but its minimal.

.NET Integration

The integration library is a .NET configuration extension so from your .NET code you access the parameter values just like you would from the appsettings.json.  Here is an example of the startup setup:

public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .ConfigureAppConfiguration(builder =>
            {
                builder.AddSystemsManager("/my-application/");
            })
            .UseStartup<Startup>();
}

The extension also supports customizing the reloading of configuration.

DevOps Release

We also leverage SSM parameters from our Azure DevOps Releases with the AWS Tools for Windows Power Shell Script task and AWSPowerShell module.  This allows us to read parameters from AWS that are useful for deployment purposes.  In addition, we can also store values is SSM from the pipeline.

Here is a small PowerShell code sample for getting and writing SSM parameters:

$params = Get-SSMParametersByPath -Path “/root” -MaxResult 1000

Write-SSMParameter -Name $parameterPath -Type “String” –Value ‘myValue’ -Overwrite $true

Hopefully you enjoyed a quick look at how we configure our serverless apps using SSM Parameters.  If you did or have any questions, please leave a comment below.

Happy Configuring!