DEV Community

Cover image for AWS Provisioning Three Ways
Zach A. Thomas for AWS Community Builders

Posted on

AWS Provisioning Three Ways

I just read the news about AWS Function URls and I wanted to try it out ASAP. In a nutshell, this allows you to instantly have a public HTTP endpoint for any lambda you've got. This was always possible by configuring an API Gateway, but that is quite complex and provides features that could be overkill if you just want a webhook or something simple.

Most AWS tutorials I find show you how to do things step-by-step in the console. While that's helpful for starting out, what you want in the long run is infrastructure-as-code, which means all the resources in your application should be described in files that can be checked into version control.

I stood up a quick demo in this GitHub repo that shows setting up a simple serverless application (with Function URL!) in three different ways:

  1. pure AWS CLI commands. In this method, you create a shell script to create resources, using commands such as aws iam create-role and aws lambda create-function. This is the "no frills method."
  2. Serverless framework. There's a lot to like about Serverless framework. It provides commands for deploying to different stages (think dev/test/prod) as well as invoking locally for test purposes. This method uses is a front-end for AWS CloudFormation, which was a pioneer in infrastructure-as-code wave. One downside is that provisioning takes a bit longer, so the feedback loop when making code updates is not as quick as I like.
  3. Terraform. Terraform from Hashicorp is a big deal. They have pulled off an amazing feat: to unify all the clouds and over 1,000 different providers into a single provisioning language. One of my favorite things about Terraform is that it helps you see differences between your application as configured and how it really is in the real world. Configuration drift really exists, and it is important to stay on top of it.

So far, I haven't even mentioned that the demo code I wrote is in Clojure, my favorite language. Usually, it's quite a bit of effort to deploy clojure, because you need a compiler and build pipeline to get your artifacts ready to run. Thanks to a lightweight interpreter called nbb, you can interpret Clojure in a lambda as easily as you can interpret JavaScript. If you're not into Clojure, it's not a problem. These three forms of provisioning lambdas work with any of the lambda runtimes (node, python, java, go, ruby, and .NET).

Top comments (0)