Size up AWS Lambda vs. Elastic Beanstalk for app hosting

Elastic Beanstalk's flexible PaaS

Elastic Beanstalk provides a versatile application platform using familiar AWS compute instances. It supports a range of popular languages and middleware platforms, design patterns and use cases, as well as customization in the runtime environment.

Elastic Beanstalk began in 2011 as a packaged Java EE platform running the Apache Tomcat server. Since then, AWS has expanded the languages, application servers and runtime environments supported for PaaS app delivery.

Elastic Beanstalk works with Java, Go, PHP, Python and Ruby programming languages. Its application servers range from Tomcat to Nginx with the Node.js runtime, Phusion Passenger and Puma, as well as several generations of Microsoft IIS for .NET applications. It also supports Docker containers and several integrated development environments.

The PaaS stack handles the dirty work of infrastructure provisioning and management on AWS. For example, it can deploy EC2 instances with an OS and application stack, load balance and auto scale workloads and monitor application health via CloudWatch. However, it does not completely insulate developers and DevOps teams from the underlying infrastructure details on AWS servers. Users can tweak and customize infrastructure as needed. For example, they can choose their OS, such as Amazon Linux or Windows Server, and can use custom Docker container images with a range of languages, web applications and libraries via Elastic Beanstalk.

Elastic Beanstalk also provides access to Java VM settings and environment variables. Users can choose from diverse AWS storage, instance and database options, as well as non-core components, across multiple Availability Zones. If users need to troubleshoot issues, they can log into the EC2 instances. 

Elastic Beanstalk users pay for the AWS resources that the PaaS offering consumes to run and store the application. So while Elastic Beanstalk is free, application planners should estimate the total cost of the EC2 and Relational Database Service instances, S3 buckets and network charges for average operation and spike periods.

Lambda's hot yet misunderstood hosting paradigm

Lambda, released in 2015, provides event-driven code hosting with abstracted infrastructure provisioning and management. It makes serverless computing an option for enterprise IT teams.

Lambda supports code written in Java, Go, PowerShell, Node.js, C#, Python and Ruby. Lambda also offers a Runtime API that enables custom functions in other languages. Serverless functions aren't as easily categorized as IaaS or PaaS since, unlike platforms for conventional applications -- EC2, Elastic Beanstalk and even Kubernetes managed containers -- Lambda doesn't require the AWS user to set up an execution environment for application code to run. Instead, Lambda code modules sit dormant until triggered by the right event, or set of events, to execute functions.

Lambda's event-driven nature means that AWS can execute functions from a cold start. Code that hasn't run in a while activates within seconds, while repeat instances run within a few tenths of a second, thanks to caching. Lambda automatically scales to handle high volumes of incoming events, provided developers properly configure the amount of memory available for functions.

Lambda is designed to handle transient, asynchronous events, so functions must complete within five minutes and the service will throttle events that exceed a set limit. Lambda is not a substitute for Elastic Beanstalk or other conventional cloud hosting configurations for steady-state workloads that require a relatively consistent level of compute resources over long periods.

Unlike Elastic Beanstalk, Lambda's execution and billing model doesn't charge users for idle infrastructure, but only the compute resources consumed, as measured by the number of events, memory size and total execution time per month.

Serverless vs. PaaS on AWS

Serverless can replace VMs and containers for some application workloads, but the comparison of Lambda vs. Elastic Beanstalk isn't so simple.

The constraints on serverless, notably a limit on Lambda execution time and no direct support for stateful code, make the serverless model a poor fit for many typical enterprise systems.

Both Elastic Beanstalk and Lambda insulate developers from the overhead and details needed to configure and deploy runtime compute instances. Both the PaaS and serverless services can significantly boost developer productivity and improve agility. However, their differences make Lambda and Elastic Beanstalk complementary, not competitive.

Many design patterns require a mix of event-driven, API-based code that fits serverless with Lambda and file-based services using persistent VM instances that can run via Elastic Beanstalk. Lambda can handle infrequent, asynchronous code, such as event handlers that call other cloud services for heavy-duty processing, while Elastic Beanstalk underpins how developers build, deploy and manage the custom back-end services for the application.

In general, Lambda's fine-grained usage measurements result in a cheaper implementation for event-driven code than if using an ongoing resource consumption model with Elastic Beanstalk. However, serverless developers must monitor for event spikes caused by bugs or attacks and other unusual situations. An inordinate amount of function invocations will result in sticker shock when the monthly AWS bill arrives.

Unfortunately for indecisive developers and those with complicated application architectures, there's no clear winner in a Lambda vs. Elastic Beanstalk comparison. Instead, these hosting options require teams to carefully assess application requirements and craft designs that exploit the strengths of each service as appropriate. Get the balance of PaaS and serverless right, and applications will be more responsive and scalable, yet cost less to operate and maintain, than traditional VM deployments.