Summary

Most AWS microservice articles only show you the tip of the iceberg. We certainly can’t blame the article authors. For starters, the SAM squirrel mascot is so darned cute!
But more importantly, we all know that standing up a production web service involves far more considerations than you could ever cover in a single article. We are talking about considerations like automated testing, CI/CD, authentication, security, telemetry, resiliency, monitoring and management.

Our aim with this series of articles is to guide you through these considerations and share with you the why and how of each. We are going to walk though each step of setting up a production-ready RESTful service on AWS. We will start with continuous integration and unit testing, cover building and deploying a reliable service, securing that service and monitoring it. Along the way, we will explain our reasoning on why we are making the choices we are making. This allows you to ask the same questions of your technology stack in order to determine not only what the “best practice” is but what problem (if any) that practice actually solves. Our opinions are driven by a few simple principles:

• Keeping it simple: Simplicity allows for smaller code that is easier to read, maintain and modify.
• Leverage the community: We prefer to leverage libraries and standards to help us focus on building the functionality that delivers the most value to our business, rather than handling boilerplate and technical concerns.
• Craftsmanship: It is important to ensure the highest quality in everything we do. That is why we use Test Driven Development and a Codified Infrastructure to ensure that our application is reliable and consistent. Even our build environment is codified.

This series is for you if you have ever:

• Been energized by a web service how-to article, but when you set out to do it yourself, you realized a lot was left out, or
• Designed, built, deployed and managed your own production web service and are looking to benchmark against our other industry best practices, or
• Have been accustomed to working in existing traditional applications and are interested in how to build an entire application from bottom to top in the Cloud.

We will be demonstrating these concepts by building a RESTful microservice that manages “Products” for a hypothetical e-commerce platform. An example product in JSON format looks like this:

{
    "id": "f7dr35",
    "name": "Widget",
    "imageURL": "https://example.com/widget.png"
}

This application only exposes HTTP endpoints to manage this data. It is up to other applications within the organization to provide a UI on top of that data. This provides a decoupling from the data and the business rules that govern how that data behaves from the way in which data from several services is combined together into the most effective presentation. While only one application may modify products, dozens may have the need to look up product information.

While you may not be building the next Amazon.com, these concepts will be directly translatable into a service in any business domain that needs to reliably manage data.

To support these goals, we will be deploying our application using NodeJS within a Docker container on AWS.

Javascript, via the NodeJS project, is becoming a common platform for cloud services due to its lightweight runtime, familiar language and extensive ecosystem. However, most of the concepts outlined here apply equally to any modern language.

Docker provides a mechanism for repeatable deployments by creating a bundle that contains all of our source code with a known version of the underlying NodeJS runtime. We go into a more detailed explanation of these advantages later in the series.

AWS provides a large and ever-growing toolbox of services that allows us to delegate common concerns like infrastructure, networking, DNS, and data storage while focusing on the features and problems unique to our application. While all of the concepts here can be ported to other cloud providers, we (along with many others) have found AWS to have the most mature feature set among the competitors. Our company, Source Allies, has built a deep expertise in working with AWS and we are an APN Partner.

Prerequisites

Before we get started, we will need to ensure a few things are setup on our local machine:

• The examples in this guide assume a Bash shell. If you are on Windows then the Git installation includes Git Bash.
• Install Git for source control
• Sign up for an account on github.com if you don’t already have one and create a repository for this project. Clone that repo locally.
• You will need an AWS account with broad permissions to create new resources. The entire cost of this series will be low (less than $25 per month)
• Install the AWS Command Line Tools and set them up to access your account. We will use these to bootstrap our environment.
• Install a recent version of NodeJS
• Install Docker to test our containers. This does not work well on versions of Windows below 10. If you are on an older version of Windows either use Docker toolbox or simply skip running the image locally and let AWS build the image.
• Obviously, you will need something to edit the code and configuration we will be building. Any text editor should work just fine.

Initialize the project

Navigate into the project directory and run the following on the command line to create a package.json (you can answer the prompts however you choose):

npm init

It is also recommended to add the node_modules directory to your .gitignore file so that dependencies are not checked into source control.

Changes for this post

Table of Contents

• Introduction (this post)
• Unit Testing
• Koa
• Docker
• Cloudformation
• Code Pipeline
• Fargate
• Application Load Balancer
• HTTPS/DNS
• Cognito
• Authentication
• DynamoDB
• Put Product
• Validation
• Smoke Testing
• Monitoring
• List Products
• Get Product
• Patch Product
• History Tracking
• Delete
• Change Events
• Conclusion

We look forward to sharing our insights with you! If you have questions or feedback on this series, contact the authors at nodereference@sourceallies.com.

About the Authors

Paul Rowe studied computer science at Western Illinois University. He started working with Source Allies in 2007 and has over a decade of software development consulting experience in the Health Care and Agriculture markets. Paul is versed in a variety of Node.js, Java and AWS tech stacks. He experiments on GitHub here.

Matt Vincent studied industrial engineering at the University of Iowa. He founded Source Allies in 2002. Matt is an AWS Certified Solutions Architect & DevOps Engineer with a specialty certification in Data Analytics.