Pure Clouds — Serverless Applications and Architecture

Past and Present

Amazon brought forward the era of cloud computing with their Amazon Web Services (AWS) offering. Their Elastic Compute Cloud (EC2) allows on-demand creation and termination of computing resources. AWS provides well tested and documented Software Development Kits (SDK, devkit) in multiple programming languages. These SDKs allows programmatic control on a host of AWS services and offerings. It had always been possible to create programs and scripts that can monitor an application’s AWS infrastructure and scale up or down it as deemed fit by load demands and business needs. Introduction of AWS Elastic Beanstalk provided high level, easy automation in this area.

Despite programmatic control of EC2 and offering of AWS Elastic Beanstalk, there still have been the concept of physical/virtual servers. Number of these servers are always required to be running and billed irrespective of their usage. These architectures, even though a step forward are still fragile and require constant outside monitoring and support. A complex application with dependencies on multiple services and integration points requires separate scaling policies for different components.

Solution — AWS All The Things

Over the years, AWS has grown beyond the initial offering of EC2, Amazon Relational Database Service (RDS), Elastic Beanstalk. Amazon Simple Storage Service (S3) is the most basic example of these new set of services being offered by AWS. S3’s documentation states

“Amazon Simple Storage Service (Amazon S3) is storage for the Internet. You can use Amazon S3 to store and retrieve any amount of data at any time, from anywhere on the web.”

S3 has been operational for over 10 years now. But the concept was revolutionary. AWS public cloud is the biggest cloud hosting platform. Bigger than all the major competitors i.e. Microsoft, IBM and Google combined [3]. All major companies are AWS customers, including but not limited to Netflix, Adobe, NASA, Aol etc [2].

S3 is about storage. Some of the latter and more interesting AWS offerings are

  1. DynamoDB
  2. ElasticCache
  3. Simple Queuing Service (SQS)
  4. Simple Notification Service (SNS)

These services are central to any application’s infrastructure and architecture. These are often implemented using famous offerings like RabbitMQ, Kafka, MongoDB, Lucene, Elasticsearch etc. to name a few. All of such packages requires complex setup, policies, upgrade and maintenance cycles.

AWS solves all of this and provide a consistent, on-demand, always-on solutions to supplement these. Bring both costs and complexity down significantly. It alleviates fault tolerance concerns and enables faster release cycles.

Despite all of these and more. Concept of application servers still remain. Would it not be great to not be thinking of servers at all? AWS Lambda makes that possible.

Step Ahead — AWS Lambda

This is how Amazon defines AWS Lambda

AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume — there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service — all with zero administration.

Advent of AWS Lambda is no small feat. It is the glue that connects most of the AWS services and makes possible a truly serverless application. Living and functioning entirely in the cloud.

Some of the examples when a Lambda function can be invoked are

  1. Object creation and deletion in a S3 bucket.
  2. Updates in DynamoDB tables
  3. Processing SNS messages
  4. And more.. [5]

Hosts of powerful applications, from file processing to component chaining to data analytics can be created quite easily by making use of AWS Lambda in conjunction with other AWS services.

Potential Downsides of Such Architecture Choice

Without a doubt AWS Lambda and other services offers a powerful mix of tools and services to create any application, where scalability concerns can be disregarded to a good degree. But there exists some potential pitfalls with such solution. Some of these are

  1. A DDOS would create a massive bill. A small scale DDOS or fake application demand will simply create more and more resources. Application will function because of elastic nature of the infrastructure. But cost of not being able to detect and block such an attack can be quite massive. In a traditional setup, a service would simply get degraded or crash under heavy load. But in completely elastic setup, some new ways need to be employed for detection and blocking in such cases.
  2. Debugging may not be straightforward.
  3. Similar to debugging, some training and preparation is required for logging

It should be noted that AWS provides CloudWatch alarms and monitoring for Lambda functions. But these concerns should be considered for a production application.


Over the years. Amazon’s AWS has redefined and created an entire industry segment. AWS continued innovating and is the winner by a significant margin in public cloud hosting. Their recent offering AWS Lambda is a step forward and provides power of scalability, fault tolerance and integration with AWS services in an easy, consistent way.


  1. https://aws.amazon.com/solutions/case-studies/all/
  2. https://aws.amazon.com/documentation/s3/
  3. http://www.zdnet.com/article/aws-public-cloud-is-twice-as-big-as-microsoft-google-ibm-combined/
  4. https://aws.amazon.com/lambda/
  5. http://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html
  6. http://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions.html
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.