Fargate vs. Lambda

AWS Fargate and AWS Lambda are two popular computing services offered by AWS for running serverless applications. While both services provide similar functionalities, they have different architectures and use cases. This article will compare AWS Fargate and AWS Lambda and discuss their pros and cons.

Fargate

AWS is Amazon’s solution to run docker containers without managing any servers for container orchestration. It is a serverless compute engine that allows one to run containers without managing the infrastructure. It complements ECS/EKS and makes launching container-based applications much more effortless. When cluster capacity management, infrastructure management, patching, and provisioning resource tasks are removed, one can finally focus on delivering faster and better quality applications.

Fargate is billed on CPU and memory used per hour. ECS does not allow one to configure Fargate to use arbitrary amounts of CPU and memory, and the amount of memory available depends on the amount of configured CPU. Like Lambda, any unused CPU or memory is essentially wasted money so one will want to try and size the application appropriately.

AWS Fargate works as an operational layer of a serverless computing architecture to manage Docker-based ECS or Kubernetes-based EKS environments. For ECS, one can define container tasks in text files using JSON. There is support for other runtime environments as well. Fargate offers more capacity deployment control than Lambda, as Lambda is limited to 10GB of space and 10GB of package size for container images and 250 MB for deployments to S3 buckets.

‍

Fargate functions must be packaged into containers, increasing the load time to around 60 seconds. This is a very long time compared to Lambda functions which can get started within 5 seconds. Fargate allows you to launch 20 tasks per second using ECS RunTask API. Moreover, you can launch 500 tasks per service in 120 seconds with ECS Service Scheduler. That said, scaling the environment during unexpected spike requests and health monitoring tends to cause a bit of a delay in start-up time.

Therefore, one can focus on building the applications while AWS does the heavy lifting of provisioning, configuring, and scaling servers or clusters. All one needs to do is define the infrastructure parameters, and Fargate will launch the containers.

‍

Key characteristics and use cases of AWS Fargate

• Deploys and scales applications easily, from single-use utility applications to entirely containerized microservices architectures.
• Eliminates the operational overhead of choosing server types, patching, sizing, cluster scheduling, optimizing cluster packing, and more.
• Allows you to pay only for what you use as Fargate’s fully managed container environment automatically allocates the required to compute power on-demand.
• Integrates with a range of sibling AWS services for networking, CI/CD, security, monitoring, etc.
• Allows developers to have workload isolation.
• Improves security with isolated compute environments.

‍

Lambda

AWS Lambda is an event-driven serverless computing service. Lambda runs predefined code in response to an event or action, enabling developers to perform serverless computing. This cross-platform was developed by Amazon and first released in 2014. It supports major programming languages such as C#, Python, Java, Ruby, Go, and Node.js. It also supports custom runtime. Some of the popular use cases of Lambda include updating a DynamoDB table, uploading data to S3 buckets, and running events in response to IoT sensor data. The pricing is based on milliseconds of usage, rounding off to the nearest millisecond. Moreover, Lambda allows one to manage Docker containers of sizes up to 50 GB via ECR.

Lambda is explicitly designed to handle small portions of an application, such as a function. Lambda is billed on a combination of the number of requests, memory, and seconds of function execution. When trying to manage Lambda costs it is important to size the function’s memory requirements properly since it directly affects cost.

As Lambda has a generic and simple application model, it can be used for almost any type of application. However, it can be most suitable for applications with unknown demands and lighter-weight apps with stateless computing.

‍

Key characteristics and use cases of AWS Lambda

• Reduces costs because one only pays for the resources one uses.
• Scales automatically to handle a few requests per day or even thousands of requests per second.
• Reduces operational overhead such as administration, maintenance, security patching, resizing, and adding servers for any type of application or backend services.
• Allows developers to spend more time on innovation with quicker iterations.
• Supports multiple programming languages.
• Allows packaging and deploying of functions as container images, expanding its use cases.
• Easily integrates with other innovative AWS services.

It is suitable for the following use cases:

• Web applications and websites that require dynamic scaling to handle excessive traffic loads at peak hours and save money when there is no traffic.
• For applications that can be easily expressed as single functions with predictable usage of resources on each invocation.
• Event-driven workloads and apps.
• Custom mobile and IoT backends.
• Asynchronous, small jobs are to be managed in tandem.
• File processing and automated file synchronization.
• Real-time log analysis and data processing.
• IT automation.

‍

Both Lambda and Fargate run on demand. Thus, the applications or functions shut down or become idle after a predetermined amount of time. However, due to the idle time, the environment is not immediately accessible as it normally is while live and running.

Both these serverless solutions offer different abstraction levels. While it leads to lesser operational burdens, one may have to compromise on flexibility and endure a few operational limitations.

The Fargate vs Lambda battle is getting more and more interesting as the gap between container-based and serverless systems is getting smaller with every passing day.

‍

Lambda seems to be the true serverless champion of AWS and is as close as possible to just running code directly without thinking about any infrastructure. On the other hand, the billing model makes it very difficult to predict costs, and its radically different deployment model can be a challenge for organizations that are used to more traditional deployment models.

Theories aside let’s do some experiments in finding the best service for our application.

To know more about deployment in AWS Fargate check out this article: Getting Started With AWS Fargate

So let’s begin our experiment, first let’s deploy a simple Node JS application which will perform intense compute and I/O operations in both Lambda and Fargate.

‍

The /io endpoint performs an I/O-intensive operation in this code by making an API call using the Axios library. When a request is made to the /io endpoint, it uses axios.get to fetch data from the specified API. The retrieved data is then sent as a response.

The /compute endpoint remains the same and performs the CPU-intensive computation using the fibonacci function.

The /io endpoint simulates an I/O-bound task by making an API call, while the /compute endpoint simulates a CPU-bound task.

After deploying the above code let’s test both services by writing a simple python which simulates traffic to both endpoints.

‍

The code makes separate requests for I/O and compute operations for each platform, measures the latency for each request, and stores them in separate lists (lambda_io_latencies, lambda_compute_latencies, fargate_io_latencies, fargate_compute_latencies).

After making all the requests, the code plots the latency data separately for I/O and compute operations using matplotlib. The first plot represents the latency comparison for I/O operations, while the second plot represents the latency comparison for compute operations.

‍

Output of I/O operation:

‍

Output of compute operation:

From the above graphs, it’s obvious that Lambda is the clear winner, this is because the container in Fargate requires some extra time to boot up its OS whereas in Lambda there is a pool of initialized containers that can be reused for subsequent invocations, reducing cold start times, but there are some edge cases where Fargate can perform better than Lambda we can’t conclude that any of the service is better than other. Since it will purely depend on the type of application we are going to deploy.

‍