AWS Lambda is a new way to run event-driven applications as a service.  Often referred to as “serverless” computing.  AWS Lambda allows developers to think only about the code, and not have to worry about the layers below.

Already familiar with AWS Lambda?

With three lines of code, you can see inside your Lambda functions.  IOpipe offers application performance monitoring for serverless applications.

It’s all about the functions

AWS Lambda is similar to how a platform as a service (PaaS) works.  In a platform as a service, you typically create an application and deploy it to a PaaS.  Once deployed, the PaaS manages the operational aspects of the application, including scaling and high availability.  Notable PaaS products include Heroku, Cloud Foundry, AppEngine, and OpenShift.


Microservice architectures have been gaining popularity, where applications are broken into much smaller pieces (services) to enable better scalability, more agile development, among other benefits. Lambda embraces this philosophy, and allows developers to deploy a single function at a time.  Once deployed, Lambda will manage the operational aspects of that function, from scaling to high availability.  This is why many people use the term function as a service (FaaS) when describing AWS Lambda or Serverless architectures.  


Can any application run in Lambda?

Some applications may need to be modified to run with Lambda. Serverless is a specific architecture where state and compute are decoupled.  Lambda only takes care of the compute, so state needs to be put into an external service.  AWS provides several services which handle state, including but not limited to S3, Dynamo, and Redshift.  State doesn’t have to be stored in an AWS service, you could also run your own database such as PostgreSQL, Cassandra, Kafka and have the Lambda functions write to those data stores via web requests.


Werner Vogels (Amazon CTO) has released some good serverless architecture examples, which is a nice starting place when thinking about how to architect your application for Lambda.


Ok, but why should I care?

When using Lambda, you only pay for the compute time (in milliseconds) used.  When your function is not being used, you pay nothing.  This means that most people will see huge cost savings when compared with using EC2. Typically, VMs are subject to almost 90% under-utilization. With Lambda, this approaches zero.

Since AWS is taking care of the heavy lifting of scaling your application, and making it highly available, developers can spend more time writing code.  Many companies embracing event-driven computing are now able to move faster than their competitors, since they aren’t worrying about the servers anymore.


This model won’t be restricted only to A users, as Google Cloud Platform and Microsoft Azure are also integrating FaaS products. There are also several on-premise solutions including IronWorker, OpenWhisk, Gestalt, and LeverOS.  Increasingly, applications will be built in an event-driven fashion.


What are the disadvantages with Lambda?

As Lambda is still in its infancy, documentation, tools, and frameworks need to be created or adapted to event-driven architectures.  There are numerous new tools, guides, and frameworks emerging, but it’s still early days.  


Serverless.. aren’t there still servers?

The term serverless can be a bit misleading, as there are obviously still servers needed to run the compute services. It’s often called “serverless” because the servers are abstracted away. In the end, it’s just a name.  The real discussion should focus on how to move Lambda (and equivalent platforms) forward.

Regardless of your feelings on the term Serverless, we’re super excited about the future opportunities event-driven computing offers.

Get started with your first Lambda function.

AWS Lambda is easier than you think!  We’ve put together a simple meme generator tutorial which walks you through how to launch your first Lambda function.  It should take you less than 20 minutes to deploy to AWS.