tl;dr The combination of AWS API Gateway and AWS Lambda eliminate the DevOps overhead associated with Microservices.

Do you remember the scene in 2001: A Space Odyssey where a group of developers wake up to find that their web application has become a monolith? They go ape over the complexity of building a microservice-oriented architecture and it gets a little ugly. If you’re like me you always fall asleep before the end of the movie so here’s a spoiler for you: AWS saves the day by blowing up the monolith into a bunch of tiny little functions that sit behind an API gateway and everyone lives happily ever after!

If you’ve built a monolith or two of your own, you’ve probably started looking for ways to blow it up using microservices. If so, you’ve likely started to encounter the trade-offs. To quote Martin Fowler:

Many development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping burden.

Much of the burden lies in DevOps. Building, Dockerizing, deploying, monitoring, and maintaining microservices comes with an operational burden that many teams aren’t equipped for. When you’re used to working with monoliths and suddenly find yourself learning about service discovery and unified log processing, some consternation is understandable.

When deciding how small your microservices should be, that operational overhead really starts to weigh in. If it’s a pain to deploy and manage a handful of them, a dozen or two seems daunting. Let’s imagine that we wanted a microservice to consist of a single function. We would need a way to deploy it, invoke it, version it, access its logs, and to horizontally scale it so we could invoke multiple instances in parallel. That’s not something many teams could manage if they were rolling their own infrastructure. Thankfully, AWS Lambda and API Gateway make all of these tasks simple and fun!

What’s a Lambda?

For starters, it’s just a function that takes an event and a context:

exports.handler = function(event, context) {

console.log("This logs to CloudWatch!");

context.suceed("Super duper!")

};

So how do you deploy a Lambda?

While you’re getting your feet wet, you can simply edit your code in the online editor. Once you start getting serious you’ll want to upload a zip archive of your code. I currently use the AWS SDK via Gulp to upload my functions and I promise to detail my workflow in a subsequent article.

What about versioning?

Every time you deploy your function, the AWS Lambda service automatically versions it for you. On top of that, it gives you a $LATEST alias that points to the most recently deployed version. Even better, it allows you to define your own aliases like dev, qa, staging, and production that you can easily point to different versions:

What about invoking a Lambda?

Lambdas are invoked in response to events. AWS API Gateway makes it possible to trigger your Lambdas with HTTP requests, but they can also be invoked in response to a file being uploaded to S3 or an item being inserted into a DynamoDB table.

Trigger Lambdas via AWS API Gateway

As I alluded to above, AWS API Gateway gives you the ability to invoke your Lambdas in response to HTTP requests. Here’s what it looks like to create a POST method that triggers a Lambda function:

Trigger Lambdas with DynamoDB Streams

One of the approaches I’m currently using is to treat DynamoDB as an EventSource that triggers Lambda functions that respond to changes in my data. I use this trick to project data to Firebase where my React and React Native clients can subscribe to just the data they need to render. It’s pretty sweet. (I’m hoping AWS comes out with a Firebase competitor soon or at least add support for load balancing websockets.)

Trigger Lambdas with …

The list of potential event sources for triggering lambdas continues to grow. Here are a few of the possibilities:

What about Monitoring and Logging?

OK, so you’ve now got a great way to deploy lots and lots of tiny microservices, but how do you monitor them? AWS has you covered:

When you click the View logs in CloudWatch link you see this:

And a simple console.log is all you need to see what’s happening in your Lambda:

What about scalability?

Check out this FAQ: https://aws.amazon.com/lambda/faqs/#scalability

Next Steps

Want to star creating Lambdas? Checkout this article to get started: https://medium.com/@tombray/getting-started-with-aws-lambda-node-js-904bc0bfb83#.1uihh7gm5

The combination of AWS Lambda and API Gateway is a game-changer in the world of microservices and I’m extremely excited about the possibilities. Follow me for more upcoming articles about implementing serverless microservices with AWS Lambda, API Gateway, and much more. As always, feel free to get in touch if you have questions!

Follow me on twitter @tombray