With services like S3, Lambda, API Gateway, and AppSync, building cloud backends is now easier than ever before. Serverless technology has freed developers from most of the work that provisioning and maintaining infrastructure once required.
But now, after using serverless for many years, I’ve come to realize they aren’t as easy to use as some serverless proponents might suggest.
In AWS, in particular, the core services require other support services. For example, allowing a Lambda function to access an S3 bucket requires setting up appropriate IAM roles. You should also keep in mind that as AWS resources, the events flowing between these services must be defined beforehand.
Considering how your system might grow, scalability is an important factor to consider. Sure, Lambda functions are simpler to manage as EC2 instances, but handling hundreds of them may require appropriate tooling to manage your infrastructure.
With so many infrastructure-as-code (IaC) tools available, the choice can be overwhelming. AWS alone offers at least four that I know of. In this article, I present eight IaC tools to consider. (I chose to focus on these particular tools because they’re a. either directly related to AWS, b. popular, or c. my prefered ones based on my personal experience having worked with them in the past.)
AWS Configuration Management Tools
AWS-owned IaC tools have the obvious advantage of being created by an internal AWS team with direct access to other AWS teams that can inform them about future releases and AWS service changes and updates so they can include them in their roadmaps early on.
AWS CloudFormation
AWS CloudFormation (CFN) is the standard tool and service for managing your AWS infrastructure with code. CFN is the target tool for most of the other IaC tools out there, as they all go through some form of conversion before deploying with CFN. CFN takes declarative resource definitions, which are YAML based. CFN comes with some tooling and a web console that offers insights into your deployment.
CFN allows you to:
- Determine whether the deployment worked as expected.
- Determine whether someone manually changed the resources later.
- Tear down a deployment in one go.
JavaScript has been called the “assembler of the web,” due to the fact that many languages have tooling to compile to JavaScript. Similarly, CFN templates could be seen as the “assembler” of AWS IaC. Since some of the other tools mentioned in this article create CFN templates, you may need to read the template in order in order to know what’s really going on and thus gain maximum control over your infrastructure.
The downside of CFN is that it’s rather chatty. I often have to write huge amounts of boilerplate when defining my infrastructure with CFN templates. Plus, some people don’t like YAML, because they see it as too sensitive and unstructured.
CFN is a general-purpose IaC tool as opposed to a serverless-only tool, so I wouldn’t encourage using it directly. When deploying serverless systems with CFN, just bear in mind that you’ll have to provision many supporting services on your own, which can become pretty cumbersome.
We know tech blogging.
AWS Serverless Application Model
The next tool is the Serverless Application Model (SAM). As an extension of CFN, it lets you define AWS resources declaratively with YAML templates.
If you like the basic concept of CFN, but are looking for more concise code, SAM is the way to go. It bundles AWS serverless resources into logical entities that go hand in hand. For example, defining an API requires an API gateway, Lambda functions, and IAM roles. This can be done with just a few lines in a SAM template.
SAM also comes with a handy CLI tool that can help tackle one of the greatest challenges with serverless infrastructure: local debugging.
AWS Cloud Development Kit
The Cloud Development Kit (CDK) shares some similarities with SAM. While it also bundles AWS resources together—so you don’t forget the IAM roles for your Lambdas—it doesn’t use YAML for its templates.
The CDK allows you to define your IaC with your preferred general-purpose language. Currently, those supported include Python, TypeScript, JavaScript, Java, and .Net.
CFN resources are abstracted to constructs, which are implemented as classes of the programming language you’re using. When you stick these constructs together, the CDK compiles a CFN YAML template.
Some constructs are directly related to an AWS resource; some are bundled resources that are built with AWS best practices in mind.
Like CFN, the CDK is a general-purpose IaC tool, but it tries to hide most of the historical baggage CFN templates bring with them. If you’re well versed in one of its supported general-purpose languages, you should feel right at home.
AWS Amplify
Amplify is my personal favorite here. It’s IaC for frontend developers—the position I’ve served in for most of my career.
Amplify aims to be the Ruby on Rails for the serverless world. As such, it offers a convenient CLI capable of generating all that’s needed for getting up and running with serverless AWS.
In addition, Amplify comes with a set of frontend libraries and a CLI. It generates code for your frontend and IaC for the AWS resources you need.
Creating an app that has an automatically synchronized GraphQL API with offline capabilities and AI features? With Amplify, it’ll only take you a few CLI commands and lines of glue code to get there.
I’ve also written a guide on authentication with Amplify, if you want to see some practical examples.
Third-Party Configuration Management Tools
Then there are the third-party tools, some of which were created before the equivalent AWS tools were available, and others out of the need to work with multiple cloud providers.
Serverless Framework
As companies struggled with CFN, finding all the boilerplate too cumbersome, the Serverless Framework (SLS) was created to fill the need for a simpler configuration management tool. It first launched under the name JAWS, but was later renamed the Serverless Framework, which spun out to its own company. It can be used with AWS, but also works with Azure, Google Cloud Platform, and even Kubernetes.
As the name implies, SLS aims to serve as the IaC tool for all serverless deployments. It is also YAML based. Like SAM, it’s also far simpler than using CFN directly and comes with local debugging features built in to their CLI.
Architect
Architect (ARC) tries to achieve the goals of the other frameworks by going in another direction. It doesn’t use YAML or a general-purpose programming language; rather it uses its own concise declarative configuration language.
What sets ARC apart from the many available IaC tools is that instead of centering around multiple AWS services like Amazon API Gateway, IAM roles, and Lambda functions, it just lets you define APIs without having to think about what AWS services are involved in realizing those APIs. While initially it used AWS API Gateway’s REST APIs to implement its API resources, it switched to HTTP APIs after their release to deliver better performance to its users.
If you’re focused on value more than technology and are simply looking to build performant serverless APIs as quickly as possible, ARC is the logical choice.
Claudia.js
Claudia.js (CJS) is a JavaScript-based IaC framework. It’s kind of like Express.js but for serverless. CJS is very close to the development workflow that JavaScript— especially Node.js—developers already know. Like other tools mentioned here, it also helps with testing your serverless systems locally.
Pulumi
Pulumi (PLM) is basically a third-party CDK. It uses general-purpose programming languages instead of YAML and is used to deploy a range of AWS resources—not just serverless ones. PLM supports JavaScript, Python, Go, and .Net. If you’re not interested in Java and prefer Go development, Pulumi is therefore a good choice.
As noted above, multi-cloud support was one of the main reasons behind the creation of many of these third-party frameworks. PLM—unlike the CDK—therefore supports Kubernetes, Azure, and Google Cloud Platform as well.
As with the other tools mentioned, it eliminates—for the most part—all the boilerplate you’d have to deal with when using CFN directly.
Which IaC Tool Is Right for You?
In this blog post, I’ve presented some of the more popular IaC tools for AWS serverless deployments—some created by AWS, some by third parties. All these tools strive to deliver value without the need to manage containers or backends.
I wouldn’t recommend using CFN directly in today’s serverless world. If you’re a fan of CFN, however, consider using SAM instead. It’s basically CFN with some add-ons to make working with CFN less of a pain.
If you want to be rid of YAML templates, then CDK, PLM, and ARC are your saviors.
For those of you who already have a non-serverless infrastructure, you’d probably be better off with the general-purpose tools mentioned here. SAM, CDK, and PLM are all good choices. If you’re into Java, go with the CDK; if you’re into Go, then PLM it is.
The third-party solutions mentioned here may be a better fit if you need to manage resources of other cloud providers. Tools like Pulumi can even help with your Kubernetes deployments, allowing you to deploy a cluster in your own data center.
Finally, for frontend and mobile developers, I strongly recommend AWS Amplify—its code generation features are just magical.
Serverless is still a new domain, but having basically been founded by AWS, there are already plenty of IaC tools available that deal with its specifics. Whatever your use case or preferred programming languages may be, you’re sure to find a solution that fits your needs.
