A Closer Look at the AWS Lambda Reference Architectures

I'm a huge fan of AWS Lambda. I basically think it's one of the two or three greatest services AWS have ever launched and they've got some good ones. I was therefore excited to see the publication of five reference architectures for using Lambda on Werner Vogels' blog last week. The AWS Architecture Center has 16 existing reference architectures for common use cases that are useful for getting people up to speed with architecting on AWS. These new Lambda reference architectures, I suppose, are meant to do the same thing for serverless architecture. Now, while they're called "Reference Architectures" they're actually more good examples to follow. They haven't been genericised to the same extent the ones in the architecture center have. Basically they cover: 

1. Mobile Backend. An example mobile application for uploading photos and notes.
2. Real-time File Processing. Fan-out architecture for a markdown file conversion app that takes an upload event to S3 and fans it out using SNS to separate Lambda functions doing conversion into HTML and TXT.
3. Web Applications. An example web app for a dynamic voting application.
4. IoT backend. An example of ingesting and processing sensor data using an array of services.
5. Real-time Stream Processing. Using Lambda to receive and log data from a Kinesis stream in DynamoDB.

If we look at the high-level at these five examples, they disclose a few things about how AWS are thinking about Lambda's positioning in their service landscape:

• Lambda is targeted largely at new use cases. Only one of the five reference architectures (web applications) has a direct parallel among the existing AWS reference architectures. That would indicate that, whereas much attention has been paid to Lamda's use as a serverless backend for web apps, Amazon actually see it more as a play to extend into use cases poorly served by other AWS services.
• IoT is big. Two of the use cases are explicitly focused on taking data from connected devices and processing it in real-time either as a backend to a frontend device app or as part of a stream processing pipeline. 
• Real-time processing is big. Again we have two of the use cases focused on real-time processing of data either file based or stream based. The event driven architecture behind Lambda does seem particularly well suited to this area.
• NoSQL is everywhere. All five reference architectures use DynamoDB as part of the stack. It seems to be the new default database as far as AWS are concerned and not a single traditional relational database is in sight.
• Lambda functions are small discrete packets of functionality. This will come as no surprise, but every Lambda function in the reference architectures does a small, well-defined job triggered either by a web service call through API Gateway or as a response to a (mostly data driven) event. They are effectively business functions encapsulating a discrete packet of work such as archiving or converting a file, logging something to a database, or responding to a single well-defined user action. That is to say they are not extremely granular as they do encapsulate a complete piece of business functionality, but they are quite granular in doing only a single small thing.