When it comes to working with Serverless and AWS Lambda there are many different tools and approaches to choose from. You may have heard about a few already and might be wondering about the differences. To be quite frank with you—there were some aspects I wasn’t event totally sure of myself.
Working with Serverless requires overcoming a few obstacles: How to run your functions locally? How to create your infrastructure? How to deploy your applications? Today we’ll take a look at five main serverless approaches that attempt to help with these obstacles: manually configuring, using Serverless Framework, Terraform, CloudFormation, and SAM.
By the end of this article you should understand what the main approaches to Serverless are and when to consider using them.
Which Serverless Approach? The Short & Quick Answer
If you’re in a rush then let me skip straight to the main takeaway of the article about which Serverless approach you should use…
Manually configure Lambda if you’re looking to just hack around. Use Serverless Framework or SAM to get started quickly. Consider Terraform or CloudFormation in larger, more complex contexts.
But—of course—the tl;dr; isn’t very in depth!
Let’s now go one-by-one through each of these different approaches, explore what functionalities and benefits we get from them, and discuss the situations where we might want to invest in them.
1. Manually Configure Your Lambda
AWS Lambda Console
We’ll start by looking at the most straight-forward option for getting a Lambda configured and running: “manual configuration”.
But what do I mean by “manual configuration”? Manual configuration is when you’re in the AWS console manually pushing buttons to make things work. Many tutorials opt for this approach as it’s simple and requires no other technologies.
However, the manual approach is only suited to example and demo projects, because after a while you’re going to run into some problems. Let’s take a look at these problems…
- Tracking the changes you make is hard (and also hard to replicate)
- Undoing changes is difficult as you have to remember what you’ve done
- You cannot easily explain to others what you’ve done
- It’s hard to clean up and delete resources after
So what’s a better approach?
A better approach is to use some form of infrastructure as code. By writing your AWS Lambda in infrastructure in code you can mitigate all of the above problems as you’l be able to easily track, modify and document your changes.
But… there are many different flavours of infrastructure as code, especially when it comes to building on Lambda. So let’s take a look into each one, starting with the most popular option, Serverless Framework.
2. Serverless Framework
Serverless Framework is a stand-alone, yet free to use, opinionated tool to make working with Serverless applications quicker and easier. It’s not tied to any Cloud provider, so you can use Serverless framework to build Serverless applications on GCP, Azure and AWS.
Serverless Framework works by providing an abstraction over a cloud providers infrastructure as code services to make them simpler to use in a Serverless world. In AWS, the abstraction is built on top of CloudFormation.
In simple terms: With Serverless Framework two lines of configuration could equal hundreds of lines of CloudFormation. But it’s not just infrastructure as code abstractions, you also get some other out-of-the-box goodies.
Benefits of Serverless Framework
In a few lines of configuration you create many underlying infrastructure resources which can save the effort of manually understanding and writing them. Alongside the infrastructure, you also get nice features like local and remove invocation of functions, and easy logs access.
An important benefit of Serverless Framework is the community of plugins. Plugins allow you to quickly extend or modify your Serverless Framework configuration. The plugin community (as we will soon see) makes the Serverless Framework quite unique and powerful.
Everything is sounding good so far with Serverless Framework, right? So what are some of the drawbacks to using Serverless Framework?
Drawbacks of Serverless Framework
Whilst Serverless Framework has many plugins, my experience has been hit-and-miss. Some plugins are quite poor quality, and you might need to do some experimenting to try and find the right ones for your use case.
Another con is with Serverless framework you have to learn yet another abstraction layer. As a result you won’t learn much of what is being provisioned under the hood. Which is a blessing at first, but the benefits start to erode the more you create your own custom configurations.
Lastly, Serverless functions usually operate in a broader architectural context, requiring access to databases, queues, etc. As your architecture increases in complexity managing these additional resources in Serverless Framework doesn’t make too much sense (more on why later).
So all things considered, when should you use Serverless framework?
Should You Use Serverless Framework?
Simply put, Serverless framework is best if you need to start your Serverless project quickly. You can get up and running the fastest and you get all the out-of-the-box niceties such as local development and invocation.
But as your architecture matures you may want to investigate dedicated infrastructure as code tools to compliment your stack. We’ll explore these other tools, like Terraform and CloudFormation, in more detail later.
3. AWS SAM (Serverless Application Model)
AWS SAM is AWS’s response to Serverless Framework. Serverless Framework and SAM have quite similar philosophies (they both work on top of CloudFormation) and have similar functionalities (both Serverless Framework and SAM allow local deployment, for instance).
SAM works by grouping together several CloudFormation resources into one, such as the AWS::Serverless::Api resource which gives you a bunch of API Gateway resources grouped together in a lambda specific setup.
Benefits of SAM
AWS SAM YAML
If you’re already familiar with CloudFormation then the SAM syntax will make a lot of sense to you and you’ll feel at home. Not only will it feel familiar, but your CloudFormation skills might come in handy if the SAM framework doesn’t work exactly as you need and you want to extend or modify its behaviour.
Drawbacks of SAM
Whilst SAM has similar features as Serverless Framework, such as abstracting away complexities in your infrastructure as code and local development SAM doesn’t have a rich community of plugin creators like Serverless Framework.
SAM is (yet again) an abstraction on top of CloudFormation. However, in SAM’s defensive, it’s not as extremely abstracted as Serverless Framework since SAM only intends to work with AWS whereas Serverless Framework’s abstraction is attempting to work across all cloud providers simultaneously.
4. Terraform
Terraform is a stand-alone Infrastructure As Code tool. Terraform works from a CLI, which means it can be installed on any computer or CI tool. Terraform is Cloud provider agnostic and can provision infrastructure just as comfortably in GCP, AWS and Azure.
Terraform is not a Serverless specific tool, so Serverless specific tooling like local development, and log tailing will have to be built by hand, or Terraform can be used in combination with Serverless Framework or SAM.
Benefits of Terraform
Terraform is great for infrastructure provisioning. Unlike Serverless Framework, Terraform is good for provisioning all of your infrastructure needs without needing another tool other resources such as databases, VPC’s work well with Terraform easily.
If you’re using Serverless Framework or SAM alongside Terraform, you can share your resource configurations via AWS SSM Parameter Store to get the best of both worlds.
Drawbacks of Terraform
The downside with using Terraform for your Serverless setup is that you won’t get much for free. Anything you need will have to be written as a Terraform resource, and you’ll have to first figure out how things fit together. Unlike Serverless framework and SAM you won’t get log tailing, or local invocations out-of-the-box.
Using Terraform can be a blessing and a curse. When you use Terraform you’ll have a greater understanding of what you’re provisioning under the hood, but at the expense of the added cost and time to gain that understanding.
Setting up Terraform can also take some time. You’ll probably want to setup things like remote state and will probably need a CI pipeline to execute your Terraform also. This setup will take time, but at least you can re-use it later for other infrastructure needs.
To mitigate some of the issues of lacking functionality like local development, you can of course look into rolling your own options like docker-lambda for local development, and apilogs and awslogs for live viewing logs.
Should You Use Terraform?
Terraform is a good choice for your Serverless infrastructure if you already have a good Terraform setup and feel comfortable using Terraform. Learning Terraform could take some time. But that said, given the popularity of Terraform your time wouldn’t be wasted.
If you choose to use Terraform, you should still consider using Serverless Framework or SAM in conjunction. Using Serverless Framework or SAM for your application parts and Terraform for the shared infrastructure resources such as databases and networks.
5. CloudFormation
AWS Logo
Last up in our list of approaches is CloudFormation.
CloudFormation is the AWS custom solution for infrastructure as code. So you can think of CloudFormation as the AWS specific alternative to Terraform.
The major difference between Terraform and CloudFormation is that CloudFormation is a hosted service inside AWS rather than a stand-alone CLI.
Benefits of CloudFormation
CloudFormation YAML
CloudFormation is well known by many developers, and they’ll be familiar with the syntax and tools. If you’ve already got skills with CloudFormation then using it for your Lambda functions might make sense.
Drawbacks of CloudFormation
Terraform has arguably nicer syntax and functionality than CloudFormation. Terraform tends to be written in HCL, Hashicorps proprietary language, whereas CloudFormation is written in either JSON or YAML which can at times get quite fiddly.
Another drawback of CloudFormation is that it’s coupled to AWS. With Serverless Framework or Terraform you’re learning an agnostic tool that can be used across cloud providers whereas CloudFormation is designed to be used mainly with AWS.
Should you use CloudFormation?
Use CloudFormation if you’re already familiar with the technology. But also be sure to check out SAM for the Serverless specific parts of your application, and consider building your periphery services in CloudFormation.
Which Tech To Use & When?
Okay, that covers all of the different approaches you’ve got to building Serverless applications in AWS. Let’s quickly recap on the approaches you should look into given your specific situation.
Just want to hack about? Manual or Serverless Framework.
Creating a PoC or learning Serverless? Serverless Framework or SAM.
Already comfortable with Terraform? Terraform.
Already comfortable with CloudFormation? CloudFormation or SAM.
Conclusion!
I can already hear the screams from those who thought we couldn’t compare these technologies “But they’re so different!? How can you compare them?”. But the reality is that I’ve worked with teams that have used purely Terraform, and others who have heavily used Serverless framework.
Each of these Serverless approaches have different benefits, but also trade-off’s in terms of the abstractions they use or how they’re vendor specific in nature. So experiment with each that make sense, and don’t forget to use your existing knowledge and skills to your advantage.
I hope todays comparison helped you understand a bit more about the differences between these Serverless approaches and will inform your decision-making process on which to use. And good luck—whichever approach you choose!
Speak soon Cloud Native friends!
What approaches have you used for Serverless? How was your experience?
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022