Servers have always been the backbone of all computing environments, be it on-prem or in the cloud. But servers need to be monitored and managed, updates need to be made regularly, the data needs to be stored properly, backed up, made accessible to the right people, and above all, secured. The coming of Serverless Computing took away all these responsibilities, saving on capital expenditures, and leaving organizations free to focus on their core business more freely.
Of course, the term ‘Serverless doesn’t mean there is no server; just that the server has been abstracted away by the cloud service provider, who assumes responsibility for its management and security. AWS, which changed the face of computing by pioneering cloud computing, has also given the most popular cloud server-led compute service forms, EC2, as well as, Lambda, a serverless compute service that you can use to host highly available and scalable applications. So which one is better? To find out, this article maps the differences between EC2 and Lambda Serverless. Remember though that Lambda is not AWS’s only serverless service, there are several others as we shall see. But they all promise the same benefits as Lambda.
EC2 vs Amazon Lambda
Infrastructure
The biggest advantage serverless computing offers is that you don’t have to provision or manage servers. This is done entirely by the CSP. So you don’t have any provisioning, and management headaches, patching, updates, etc. are all taken care of by the Cloud Platform. With EC2 instances, you control the underlying infrastructure. Thus, you need to take care of scalability, Amazon Machine Image (AMI—templatized configuration, i.e. containing application with OS, App server, etc.), rehydration (spinning up new servers, complete with the latest patches already installed, destroying old servers, etc)
This also means enormous savings in terms of capital expenses, which are converted into operating expenditures, as we will see.
Scalability is an implicit benefit of cloud computing, but with serverless computing, this happens automatically, unlike with EC2. As traffic to your application increases, the platform automatically spins up more Lambda instances to accommodate the traffic. With EC2 this doesn’t happen automatically. Users need to set up load balancers, auto-scaling groups, set up auto-scaling policies, etc., themselves.
Pay for what you use
Pay-per-use is another implicit benefit of cloud computing, but the benefits are significantly enhanced with serverless. As long your function doesn’t run, you pay nothing. With EC2 you still have to pay for your instances, whether they remain idle or not.
Availability
As you don’t need to manage any server, Lambda functions are highly available and scalable. Serverless functions are automatically deployed in multiple availability zones (AZ). You don’t have to do anything. This means that even if one of the AZs goes down, your Lambda will still be up and running. However, with EC2, the onus is on you to deploy it in different AZs, create load balancers—the whole kit and caboodle.
Lambda is not the only AWS serverless service. AWS offers Amazon DynamoDB, Fargate, AWS API Gateway, and Amazon SQS (simple queue service), among others. What this means is that all these services offer the benefits of serverless listed above.
Software
You can’t install software, for instance, web servers, or app servers, in the underlying environment; however, you can install whatever code libraries you need for your Lambda code to run. These can simply be zipped up and deployed. With EC2, since you control the underlying environment, you can install almost any software—there are several pre-packaged AMIs for a variety of different software available. Amazon EC2 supports a variety of different operating systems; with serverless services, AWS Lambda natively supports Java, Go, PowerShell, Node. js, C#, Python, and Ruby code, and provides a Runtime API, which allows you to use any additional programming languages to author your functions.
Compute
Lambda allows you to select compute power at any point. You simply shift the slider bar for memory and timeout. Memory can be ramped up from 128 MB to 3 GB, and timeout from a single second to 15 minutes. As you increase memory to your Lambda, the platform automatically allocates more CPU as well. This happens instantaneously, even while the Lambda is running. With EC2 instances, you can choose the size and type of VM instance. What you’re doing, in effect, is changing the EC2 instance itself, so there is a brief interruption.
Storage
Lambda doesn’t have any attached hard disk, so the deployment package size is limited. EC2 instances allow you to attach multiple hard disks or Elastic Block Storage (EBS). So you’re not limited by package size. You can pretty much deploy any size of package you require.
Cost
Factors like the cost of installing and maintaining hardware, IT staff, etc. make it more expensive to use an EC2. This is avoided with Lambda. Since you only pay for usage, this brings down costs considerably. Plus you avoid paying for hardware, IT staff, etc, however, what you gain in the elimination of management, you lose in control of your infrastructure.
Major Benefits at a Glance
Lambda (Serverless) | EC2 |
No need to manage server | complete control of your environment |
highly scalable | Scalability & availability instances need to be provisioned and configured by users |
highly available | Availability depends on architecture |
no attached storage | Can deploy as much as needed |
Cheaper when traffic is unpredictable | Steady, heavy traffic volumes suit EC2 adoption |
Use Cases
1.Integration
Lambda is excellent for event-driven functions. It offers native integration with other services, like S3, and Kinesis. This means you can trigger lambda to run the object in the S3 bucket directly. With EC2, as we saw, since you control the underlying environment, you can run just about anything. Suppose you need to run a web server or app server with third-party software. You can install all of this in your EC2
2.Traffic (un)predictability
Lambda shines in use cases where traffic cannot be predicted. As it is inherently scalable and automatically highly available, you don’t have to configure anything. Furthermore, since you only pay for when the function actually runs, you avoid paying for any idle time
ECS works best when traffic can be predicted. Because you’re paying for all the underlying infrastructure, it doesn’t matter if it is idle or running. Furthermore, you pay for the entire VM, not just the part being used. Let’s say you’ve set up Elastic Load Balancer, Autoscaling Group with your EC2 running inside. As traffic increases, it spins up another EC2 instance to accommodate the increased traffic, but let’s say only 50% of the new EC2 is being used. You still pay for the entire VM. Clearly, the best use-case scenario for EC2 is when traffic is steady and can be predicted
3.Microservices adoption
Both EC2 and Lambda are well suited for microservices, but for different reasons. Lambda has API Gateway integration and, because the code is modular without dependencies on software, it is generally easier to migrate cloud-native greenfield applications. However, brownfield monolithic applications will need major refactoring. EC2 is also a good candidate for microservices, as you can easily move APIs with dependencies, although you do have to consider the cost and complexity of building and running a greenfield application on EC2.
Takeaway
There is no clear winner in the EC2 vs Lambda debate. As we have seen it all depends on your requirements, the need to control the underlying environment, storage/memory, traffic volume, predictability, etc. Serverless is clearly here to stay, but not all organizations will benefit from it. If you’re considering going serverless, but are not sure, talk to us.
