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.
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.
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 (AWS CTO) has released some good serverless architecture examples, which is a nice starting place when thinking about how to architect your application for Lambda.
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 AWS users, as Google Cloud Platform and Microsoft Azure also have FaaS offerings. There are also several on-premise solutions including OpenFaaS, OpenWhisk, Fission.io, and many more emerging. Increasingly, applications will be built in an event-driven fashion.
There are known issues with cold starts affecting latency of requests powered by Lambda, though there have been large improvements in reducing both the time a cold start takes, as well as the frequency of cold starts.
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.