This article is part of a series:

• Part One — review your existing application
• Part Two — break apart your application
• Part Three — lift-and-shift
• Part Four — choose a deployment framework
• Part Five — build a strong foundation

In this series, we take a look at what areas you need to think about when making a “serverless migration”. First, we will touch on what you should review about your existing application, move into breaking your application apart, talk about lift-and-shift, choose a cloud provider, choose a deployment framework, and how to build a strong foundation.

In this article, we are going to talk about choosing the right deployment framework. It’s an important decision because it’s the foundation that your entire development team will work from.

If you’re not familiar with what a deployment framework is exactly, let’s start from the top.

What is a deployment framework?

When we talk about deployment frameworks we are talking about the way in which developers can make changes locally and have those changes reflected on a cloud provider.

Two key areas:

1. Infrastructure as Code (IAC)
2. Code Updates

Infrastructure as Code (IAC)

IAC is a way to automate your application architecture allowing you spin up exact mirror environments without any manual changes. Meaning you can easily recover from disaster, deploy test environments for specific features, and avoid having all the infrastructure knowledge locked away in a single persons head.

Code Updates

Deployment frameworks typically help you package your cloud functions and deploy your cloud functions alongside the IAC automation. Meaning one part of the deployment framework is handling the creation of cloud resources and another part is focused on code changes.

Now that we have some idea for what a deployment framework is, let’s take a look at how deployment frameworks can be used.

Case Study Example — MagicLamp

In this example, we are talking about a company named MagicLamp. They are widely known for helping people online make wishes come true through their web application. MagicLamp is currently using AWS, however they set up their application manually in the AWS console.

MagicLamp has the following application architecture:

• AWS DynamoDB for their NoSQL database
• AWS Cognito for their authentication
• AWS Lambda for their cloud functions
• AWS API Gateway for their APIs
• AWS S3 static hosting for hosting their website
• AWS CloudFront for API caching and website caching

With this simple web application, MagicLamp is able to serve their users from around the globe.

Now where does the deployment framework come in?

The deployment framework would allow a developer to take each one of those AWS services mentioned above and create a stack. A Stack is a common way to refer to logical groupings of IAC resources.

How do we break apart our resources into stacks?

1. Web Stack — AWS S3, AWS CloudFront
2. API Stack — AWS API Gateway, AWS Lambda
3. Database Stack — AWS DynamoDB
4. Authentication Stack — AWS Cognito

IAC Best Practices

You may be wondering why we choose to break apart the API Stack from the Database Stack and the Authentication Stack. We did this because a common problem when creating IAC is gracefully handling teardown scenarios.

Breaking apart stacks by their ephemeral nature

At Serverless Guru, we will typically isolate any resources which hold data such as MagicLamp’s Database Stack and their Authentication Stack. We do this to ensure that we prevent any accidental IAC changes which could have an effect on these non-ephemeral resources.

When it comes to AWS S3, AWS CloudFront, AWS API Gateway, and AWS Lambda it doesn’t matter if these are deleted. Our IAC will be able to re-deploy them from scratch just fine. Aside from having around 15–20 minutes of downtime for AWS CloudFront. Every other resource listed should be easily able to spin back up with no impact.

Protecting our Stacks from accidental deletion

If you accidentally delete your database resource or your authentication resource. You’re going to lose something and while it becomes really easy to create infrastructure it also becomes really easy to destroy infrastructure. There are safeguards which you can put up to prevent this from happening and we’ve talked about them in various blogs on our Medium so take time upfront to create a good foundation to grow from. Here’s a few:

• Create an AWS IAM policy for AWS CloudFormation deployments to limit what can and can’t be deleted
• Lock the AWS CloudFormation stack down with termination protection, Serverless Guru built a Serverless Framework plugin to help with this
• Attach a DeletionPolicy to your IAC resource equal to Retain, allowing your critical resources to be retained while every other resource in the stack is deleted

Now MagicLamp has what they need to break apart their application architecture into multiple stacks and make sure that accidental deletions become much more difficult.

Deployment Framework Options

Now that we have some more background. Let’s talk about different deployment framework options.

• AWS CDK
• Serverless Framework
• Terraform
• AWS SAM
• Stackery

AWS CDK

The AWS CDK (Cloud Development Kit) is the new kid on the block, released in 2018. AWS CDK allows developers to write IAC without the constraints of AWS CloudFormation. Now developers can write JavaScript to define their infrastructure which does a couple of things.

Such as lowering the knowledge required to work effectively with IAC on AWS, allows for unit testing of infrastructure like any other part of your companies applications, and allows developers to use all the capabilities of JavaScript.

Serverless Framework

The Serverless Framework makes it easy for developers to create serverless applications and the supporting IAC for all their cloud resources. The Serverless Framework is a multi-cloud deployment framework and now supports monitoring as well with a new product called Serverless Framework Enterprise.

“Everything you need, at any scale.” — Serverless Framework

The Serverless Framework also now offers something called components. Components are similar to the AWS CDK. Meaning your infrastructure is no longer being compiled into AWS CloudFormation. Instead, your infrastructure is defined with JavaScript and able to be shared with the community. Take a look at this website component below.

Inside this component would be everything needed to create a ReactJS web application including AWS S3 static hosting, AWS CloudFront, and AWS Route53 DNS all with only a few lines of code. There is even a hook which allows you to execute custom build commands for your frontend framework.

Terraform

Terraform has been around longer than the Serverless Framework and also supports mutli-cloud deployments of cloud resources. Similar to the Serverless Framework, Terraform allows developers to write IAC to define cloud resources.

As you’ll notice above the snippet says “google_compute” and that’s because the structure of Terraform was designed specifically with the intention of being portable to other cloud providers. With the goal to avoid vendor lock-in.

Terraform also has a CLI which developers can use to make deployments for their IAC and Terraform also offers Terraform Enterprise for companies looking for a full suite of tools.

AWS SAM

AWS SAM is similar to writing raw AWS CloudFormation with a mix of the functionality provided by the Serverless Framework. AWS SAM was built to make serverless application development easier and has slightly better syntax than the AWS CloudFormation alternative.

The biggest value adds AWS SAM offers are also present in the Serverless Framework and Terraform. However, that being said. If you’re already working with AWS CloudFormation and building serverless applications than I would give AWS SAM a try as it will give you clear advantages. Additionally, AWS SAM will compile to AWS CloudFormation.

Stackery

Now that we’ve covered the most popular deployment frameworks. I would also be remissed to not mention a company called Stackery. Stackery allows developers to skip over writing the IAC by hand and instead gives a visual GUI which you can leverage to create complex architecture with even less work.

Above you can see a view into the type of IAC that can be created within a couple of minutes. Something that, speaking from experience, would take days and in some cases weeks to replicate.

Awhile back, Serverless Guru, wrote a blog article about “How to build a REST API with Stackery” if you’re looking for a tutorial. If you’re looking for a good comparison between Stackery and the Serverless Framework checkout this article by Masoud Abdipublished on Servian Marketing.

Conclusion

There are a lot of different options and they depend heavily on what your organization is hoping to achieve, what cloud providers you need to support, what level of tooling you need, what level of control you’re shooting at, general preferences, and in-house expertise.

All that being said, if you’re looking for serverless consulting to help evaluate these type of decisions, reviewing your serverless application architecture, or helping work with your team during a serverless migration. Serverless Guru specializes in every one of those categories and we would be happy to help.

‍