24.06.2016

Serverless Architectures - AWS Lambda

by Robrecht Dewaele

This post is the third in the series of reports on our trip to and attendance of the AWS summit in May 2016. If you want to start reading this series from the beginning, scroll down for the first part or check out this link.

About Robrecht

Robrecht has turned his love for computers into a career in coding while his need for speed led him to developing strong interests in low-level programming. Opting for brunch instead of breakfast is also a daily ritual to keep up with this developers' fast-paced momentum.

To the more technically inclined, serverless is a somewhat silly term. Indeed, servers are still running the online scene, albeit a little more discretely. Moreover, platforms as a service were a thing long before they were called serverless. Sometimes, renaming something can make it sound a lot more sexy though.

It is, however, not an entirely nonsensical term either: it stresses the fact that you as a client are not directly confronted with the traditional shape and form of a server. The service provider maintains, supports and likely even scales the platform for you, so you only have to think about what you are going to use the platform for.

For example, configuring and maintaining a full auto-scaling cluster of virtual private servers most likely sounds like too much work and tangent to one’s (real) purposes. We can certainly do better. Often server setup and maintenance is pure overhead and cloud platforms offer an increasing number of managed appliances.

An early example could be Amazon RDS - Relational Database Service - where the provider takes (partial) responsibility for replication, maintenance and updates, but there is still a clear connection to the concept of a server and scaling is not really done automatically.

The service provider maintains, supports and likely even scales the platform for you, so you only have to think about what you are going to use the platform for.

A more recent example is AWS Lambda, which is a service where you simply upload code that can subsequently be executed just like that: no servers to launch, no software to install. It provides abstraction at the function level and not at the service level (cfr. RDS). Scaling comes completely free of charge (figuratively speaking): multiple invocations of the same function will result in multiple instances of the same function running at the same time. Moreover, when your functions are not being used, you are not paying: auto-scaling out of the box with no additional configuration.

By itself, having code in the cloud that can be executed by the push of a button might be convenient, but not very useful just by itself. That is to say, Lambda functions are building blocks. They integrate rather nicely with multiple AWS services.

For example, Lambda functions can be triggered when a file is uploaded to S3, the storage service of Amazon. Images might be uploaded in full resolution, and a Lambda function subsequently generates a number of lower resolution versions for different purposes. Another example is the integration with Amazon API Gateway, which can link API URLs to specific Lambda functions. At XAOP we used this technology to implement a complete REST API backed by Lambda functions to implement logic and Amazon Elasticsearch Service to provide data. (We are currently working on a case study that will be published on our website.)

Many more examples can be conceived but it should be clear that this abstraction at the function level enables and facilitates micro-service oriented architectures, especially in combination with the API Gateway.

At XAOP, we used this technology to implement a complete REST API backed by Lambda functions to implement logic and Amazon Elasticsearch Service to provide data.

At the summit, we attend an interesting presentation on security in serverless applications. Something other than best practices and the importance of a secure implementation of security and access control caught our attention: wrapping the AWS API using API Gateway.

On face value, wrapping one REST API with another seems like a silly thing to do. When looked at as an extra layer of control, however, the possibilities become more clear. For example, the presenter talks specifically about Amazon CloudTrail, an auditing tool that can be configured to deliver AWS API call logs to S3 buckets. The service supports most but not all calls and support for new services typically comes after they have been introduced to the general public. If you want the logging features right here and right now, AWS Lambda and API Gateway can easily be combined into your custom auditing solution.