Real Microservices with AWS Lambda

January 5, 2016

Tags: #cloud #lambda #api #microservice #aws #java #javascript

Lately, I started working on my first Cloud project, which runs exclusively on Amazon AWS resources. I read before many things about the AWS cloud and played some little time with this and that, but made no real experience. Now I was forced to - and made a great experience!

A very special use case led me to AWS Lambda. I had the requirement to execute a function on a scheduled basis. For this, running a whole server, no matter if EC2, Elastic Beanstalk, Docker, or whatever, seamed to me too much oversized (in infrastructure and money). There’s just this small function, calculating some data, interacting with a persistence layer and sending some messages depending on the data. First, I was thinking about starting and stopping an EC2 instance on a schedule. Then, a co-worker told me about Lambda. This was exactly what I was looking for: just deploying code and functions (no whole instances) and executing them event-driven.

Lambda provides runtime environments for JavaScript (Node.js), Java 8 and Python. So you can write your function or code fragment in one of these languages. If you just need to interact with the AWS APIs, you don’t have to provide any dependecies on your own, because the AWS APIs are availabe in each of the runtimes and you can code in the online editor. Cool stuff! If you have more than one file to code and/or 3rd party libraries to use, you can just upload a zip file with your content. Lambda will unpack and execute the code. The executions will be billed on the consumed time (in units of 100ms.) and allocated memory. Pretty fair conditions.

As I already said, the functions will be executed based on events. And there are a lot of possible events available:

• S3 events, such as upload and download of files
• received emails/messages/notifications via SNS and SES
• DynamoDB events, as data is modified in any way (like a DB trigger)
• events based on CloudWatch logs and metrics
• based on data streams of Kinesis
• scheduled events, based on cron-expressions
• manually triggered from the command line
• and some others

All executions of your functions can be monitored with CloudWatch, where the logs and metrics of your services are available.

If you have the need to call your functions via HTTP - or as REST API call, you can add one or more API endpoints to your Lambda code, whether additionally to the events, or just instead of events, then the API call is your event. This is made possible with AWS API Gateway, which is not only available for Lambda, but as well for many other AWS services.

With this Lambda approach, it’s possible to deploy real microservices, acting on events and on API calls. But every service just has one purpose, not more! And because the AWS APIs are available in general, Lambda makes it easy to use the AWS infrastructure and not depending on too much 3rd party code.

In case you need it - there’s a tutorial availabe.

« First Conference Talks 2016 announced JFokus - a conference I can really recommend »