The Serverless Stack

AWS Lambda, API Gateway, S3, Event-Driven Tasks

What is serverless?

Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”), the best known vendor host of which currently is AWS Lambda. Credit Martin Fowler

What is a stack?

A stack is a collection of AWS resources that you can manage as a single unit. In other words, you can create, update, or delete a collection of resources by creating, updating, or deleting stacks. All the resources in a stack are defined by the stack’s AWS CloudFormation template.

What is the Serverless Stack?

The serverless stack is just one example of how an application can be built using serverless technologies. In this case we are building a web application with a UI, API, and async tasks. We use the CIM cli utility to create and update the stack and to deploy the Lambda code.

This stack consists of 3 smaller stacks. All pre-built as CIM templates.

• UI — Static S3 Website, CloudFront, SSL
• API — API Gateway, Lambda, SSL
• Async Tasks — SNS, Lambda

Why use CloudFormation when building Serverless apps?

The nature of our applications, has changed.

Application code modules have been getting smaller and smaller (monolithic -> microservices -> functions). And at the same time cloud providers have been adding more and more services. The result is an application that is a combination of small code modules mixed with cloud services.

The benefits are?

• applications that can scale to meet huge demand
• applications that have code that is easily managed
• applications that don’t cost a lot of money

The catch is that the architecture of these applications has increased in complexity. The importance of infrastructure as code (IaC) has gone way up.

I think that infrastructure as Code is just as important as the actual code. Implementing IaC at the onset of a new project is a must, especially with a new serverless app.

Monolithic vs. Serverless app

What is CIM?

Writing CloudFormation templates is a must for serverless, event-driven, apps. CloudFormation had a few pain points. That’s why I built CIM.

CIM is a simple command line utility that bootstraps your CloudFormation CRUD operations, making them easier to execute, repeatable, and less error-prone.

If you want to learn more about CIM, and why I built it, you can read my article, Meet CIM — Cloud Infrastructure Manager.

The Serverless Stack

Now lets learn more about the serverless stack. Maybe this should have been called the serverless web app stack. There are an infinite number of serverless stacks. This is just an example of one serverless web app stack.

This stack is all about the stack and less about the code. Once you deploy this stack you can start writing your own front-end code, api code, and async task code.

Serverless UI

The UI is a static web application hosted by AWS S3. The web requests are proxied through CloudFront, Amazon’s Content Delivery Network (CDN). CloudFront not only caches your web assets like image, stylesheet, and javascript files, it also enables your custom domain and SSL certificate. This means that your web application will be fast and secure.

The great thing about a static S3 website is the unlimited scaling and the lack of DevOps required. Your site could handle huge traffic spikes and there are no servers to monitor.

The UI also supports Continuous Integration and Continuous Deployment (CI/CD). When enabled all commits to GitHub will trigger CodePipeline to build, test, and deploy your site. You just have to push your changes to GitHub and your site will be built, tested, and deployed. This is especially important when you have multiple team members working on the app.

What can I do with a static website? The idea here is to use a front-end framework like Angular or React that then makes requests to your backend serverless api.

What if I need a dynamic website? You can use our services stack to create an, always on, web application. Or, you could also continue to use a static website but generate all the static pages in advance. Storage in S3 is cheap so even if you have tons of files, it’s no big deal. Maybe some of the page could be dynamically loaded via JavaScript.

Serverless API

The API consists of AWS API Gateway proxying calls to an AWS Lambda backend function. The API Gateway uses a custom domain name and SSL certificate so your api endpoint can be something readable like api.yourdomain.com/v1.

The great thing about this architecture is that it lends itself well to very little traffic, i.e. low cost, and to very high traffic, i.e. worry free auto scaling by AWS. Lambda does have a concurrency limit that you might hit if your traffic is really high. If you’re concerned about that then add an alarm. Then, if needed, ask AWS to increase your concurrency limit.

Event-Driven Tasks

The event-driven tasks stack is really just an example of one way to push long running asynchronous tasks out of the web request and into background tasks. For example, lets say we have an api endpoint that needs to format and send out an email. This task should be done asynchronously. Our HTTP api shouldn’t be blocking while we’re sending out an email. In our example stack the api endpoint would publish the task to SNS. SNS would then trigger a Lambda function. The Lambda function would format and send out the email.

This is just one way to handle asynchronous event-driven tasks. AWS Lambda has many different event triggers. Check out our serverless-demo for some Lambda event trigger examples.

Another popular event trigger is S3 updates. Lets say you need to take action once a new image or asset has been uploaded to S3. You can trigger a Lambda function on every new item added to a S3 bucket.

Scheduled updates (cron) can also be achieved through the CloudWatch Events event trigger. For example you can trigger a Lambda to execute every 10 minutes.

Usage Guide

To use this stack simply install CIM, fork the Serverless Stack repo, add your custom domain, and execute cim stack-up.

• Install CIM (npm install -g cim)
• Register your domain with Route53
• Configure admin@yourdomain.com to receive the SSL verification email
• Replace example.com in ui/_cim.yml and api/_cim.yml with your domain name
• Run cim stack-up --recursive=true to install the stack

Thanks for reading about the Serverless Stack. Please let me know if you find it helpful.