AWS Serverless Cooking with Lard (Part 1)
Update 2017–12–05: AWS made several major feature announcements during re:Invent 2017 last week which have partially deprecated the approach described in the article below. The most impactful are the changes to SAM in support of alias deployments. I will be evaluating the new features over the coming days and hope to write up some new examples using them.
What a time it is to be alive as a solo software architect or small team building API services! In the past, “one-man band” engineers grudgingly accepted the necessity of dividing their attention between application and infrastructure, often acutely when it came to server maintenance. Over the last few years, cloud products have revolutionized the landscape of development and deployment, ushering in the dubiously named “serverless” computing era. This new model allows us to focus on our own service logic without spending so much mental energy on the platform. In the world of Amazon Web Services (AWS), the keystone of the serverless approach is AWS Lambda, supported by a wide array of additional products which enable us to whip up a new REST API and corresponding web application in no time flat.
Author’s note: Delving into the full history of deployment approaches — specifically, the popular transition from bare-metal servers to virtual machines to containers — would be beyond the scope of this article series. My purpose here is to provide practical discussion and code examples to help any curious developer dive directly into the serverless end of the Amazon Web Services pool. Enjoy.
The End Product
Let’s begin at the end, setting our sights on the product we want to build and the goals we hope to accomplish along the way. For the sake of simplicity, we’ll develop a simple note storage web application which allows users to log in to create, retrieve, update, and delete notes (CRUD). Each note will consist of a title and body text. Here’s what we’ll aim for with our REST API:
- Notes CRUD, accessible only by authenticated users
- Note data stored in a scalable, persistent database
- No servers or containers to provision or manage
- Application code stored in a hosted source control repository (GitHub)
- Automatic build and multi-stage deployment from any commit or merge on the repository’s master branch, a.k.a. continuous delivery
- Serverless infrastructure configuration stored in the same repository
- Minimal manual configuration to get up and running
- Stick to native AWS as much as possible; avoid cross-platform frameworks
And of course we’ll also need to build a web application to speak to this API.
Next let’s enumerate the various services and technologies that we’ll choose to interact with, either directly or indirectly, to reach our goals. This list will touch briefly on what each provides. Fear not if you are unfamiliar with any of these products, as we’ll examine them in more detail later in the article series:
- GitHub will store the application code repository
- AWS API Gateway will host the REST API and provide validation
- AWS Cognito User Pools will handle application user authentication
- AWS DynamoDB will store persistent application data
- AWS Lambda will host functions which implement the API logic
- AWS CodePipeline will watch GitHub to trigger builds/deployments
- AWS CodeBuild will build Lambda packages
- AWS S3 will store Lambda packages and other pipeline artifacts
- AWS IAM will store service roles for accessing the other services
- AWS CloudFormation will deploy Lambda functions and infrastructure
- AWS CloudWatch will store logs from Lambda and API Gateway
- AWS SNS will send deployment approval notifications
- We’ll use the Angular framework to build the web app
- We’ll define the API specification using Swagger
- AWS SAM will simplify some of our CloudFormation elements
- Lard will augment our CodePipeline in support of continuous delivery
As this series continues, we will explore the individual pieces, configurations, and reasoning behind their use. In the meantime, those who are confident, brave, foolhardy, or just enjoy getting their hands dirty may wish to plunge forward into these example projects without further guidance:
- lard-example-crud-api: the CRUD API that we will build
- lard-example-crud-web: a web application that accesses the API
It can be a lot to take in at once if you are completely new to these services, but you’ll quickly see that each has its place, and they fit together nicely to make a whole. Embrace the serverless approach, and before you know it, that time you used to spend on upgrading libopenssl on your VMs or wrangling container auto-scaling will be a distant memory.
Author’s note: In the spirit of full disclosure, I have no idea yet when part 2 will be published. I work on these repositories and write in my spare time, which fluctuates and is always in contention. I will be attending AWS re:Invent 2017 at the end of November and had originally hoped to have the entire series done by then, which is now unlikely. If you will be attending the conference and would like to discuss these topics in person, feel free to reach out.
Update 2017–12–05: This article series will not continue as originally planned. Please see the update note at the beginning of the article for more details.