Separation of Duties: IaC vs AppCode

Stop writing code directly in your Lambda functions!

I see this pattern a lot in AWS based environments that employ Lambda functions to create serverless environments and wanted to touch on something. I suppose this could be applied to GCP and Azure as well.

In this post, I'm going to convey a concept you can take with you and apply in your organization to help with a separation of duties. I often take this for granted because I've been doing this pattern for so long that it's almost a no-brainer to me.

IaC: Infrastructure as Code

Often times, folks employ tools like AWS CDK, Terraform, SaltStack, Ansible, Puppet or Chef to manage infrastructure as code to describe how they want their environment to look or describe how they want to deploy the infrastructure. There's nothing wrong with this except when you have to embed code itself into the IaC or configuration.

So the idea is to use your IaC to describe the infrastructure itself and not include code artifacts as much as you can help it.

Leveraging a Framework

Typically, what I do is a separation of duties so this doesn't have to happen. In my previous video on Anatomy of a Framework and post, I break down the basic concepts of writing up a framework. The idea is to have a central codebase to contain the scripts and code you would otherwise embed in your Lambda functions or on your servers.

This is often preferred for folks that are not familiar with a framework like ZendFramework for PHP, Django for Python, RubyOnRails for Ruby, Spring for Java, you get the point. It's a small and lightweight codebase that gets the job done, imports dependencies and has a relatively small footprint.

Most software languages these days support the concept of:

• packaging/package management
• builder/build runner/compiling
• versioning
• repository/artifact management & storage

So, let's take advantage of these concepts.

Import and Run Entrypoint

The result is you no longer write code directly in your lambda functions. Instead, consider writing up a small framework or library you can just import and execute the entrypoint. The great thing about this is you can de-couple the installation of the infrastructure using your fancy-dancy IaC from the software that needs to execute in dynamic serverless environments as well.

AWS Lambda also supports running docker containers! An added bonus is you can containerize your code into an executable container and AWS Lambda will handle the rest!

This allows a separation of concerns between infrastructure and software that should execute in a serverless environment.

Try this in your next implementation and let me know how you get along in the comments!