Configuration

Note: Examples of this section are under the configuration-example directory of the example git repository.

A great downside of Lambda comes in form of delivering configuration properly.

A simple solution would be to merge a .properties file into your build, and loading it on execution for instance. Here's one example of how to load and show it:

private final Properties configuration;

@LambadaFunction(name="lb_showConfiguration")
public void handleSNSEvent(InputStream is, OutputStream os, Context ctx) throws Exception {

}

public ExampleConfigurationHandler() throws Exception {
  Properties p = new Properties();

  p.load(getClass().getResourceAsStream("config.properties"));

  this.configuration = p;
}

The properties themselves could be interpolating. This trick is known as resource filtering:

<properties>
    <foo>bar</foo>
</properties>

<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <targetPath>${project.build.outputDirectory}</targetPath>
            <filtering>true</filtering>
        </resource>
    </resources>
</build>

However, it introduces a problem: Each new reconfiguration requires a deployment. Remember that while lambda caches subsequent instances of your function, it might introduce delays if you change a configuration while a rush of new invocations comes up.

Relying on a Configuration Server

Lambda now relies on VPC (it was its most-requested feature), so hosting a service like etcd on a server on your network (or even redis/memcache, perhaps using ElastiCache) could be an alternative.

In the configuration-example, we're relying on CoreOS (and etcd) using cloudformation. Plus, you need your EC2 Public Key uploaded into EC2. Once you do this, deploy the cloudformation template:

$ mvn -f configuration-example/pom.xml cloudformation:push-stack \
  -Dcloudformation.parameters=EC2KeyName=

Now track its evolution on the CloudFormation console. Once finished, also track on EC2 and once finished, log on as core@<publicIpAddress> on the CoreOS Instance.

Then set a few keys:

$ etcdctl mkdir /config
$ etcdctl set /config/foo bar
$ etcdctl set /config/whatever abc

Now, deploy as usual:

$ mvn -f configuration-example/pom.xml -Pdeploy deploy

Notice that this also adds an overhead, depending on several factors (steal time between both nodes, network factors, tenancy).

Also, caching the configuration value would be a great idea, as well as making your lambda clients specify a given root key/version in order to cache the results.

CloudFormation makes it nice to wrap dependent resources around, but it can lead to high bills. Once you're finished with this sample, remove the EC2 Network Interface used by AWS Lambda from the EC2 Console, and then destroy the CloudFormation stack:

$ mvn -f configuration-example/pom.xml cloudformation:delete-stack

API Gateway Tricks

API Gateway also allows a trick, by way of Stage Variables. By employing one, you can simply dismiss using Configuration at all, single updates are propagated into the InputStream payload.