Fargate vs Lambda: The Step-by-Step Guide to Choosing the Right Technology

Nowadays, you have two technology options on how to build modern serverless applications in AWS. The choice is between AWS Lambda or AWS Fargate. There are oodles of articles on the internet that compare both these technologies in terms of their features, limits, and pricing.

Of course, in a huge setup, you will combine both these technologies, especially since we’re living in a microservices world. When you design a new feature or service, you often decide right then and there where you will host it.

Sit back. Grab a tasty beverage. We’re going to provide you with a simple step-by-step decision process on how to make the best architectural option for you, and you’re going to like it. We think.

Lambda vs Fargate: 7 steps you need to take to make the right decision

In general, AWS Lambda is cheaper and more suitable for serverless applications. Its nature is a function-as-a-service (FaaS). It just does the simple tasks and that’s all. Don’t expect too much more.

It should be considered as the first option for your serverless module. But wait. It has more limitations and restrictions. So, as always, it depends. Module architecture elaborated from functional and not-functional requirements, surrounded infrastructure and many other factors.

To make a decision you must review the list of restrictions below.

1.Portability. The first question is nice and simple — do you need to run your app in several places? For example, you have mixed infrastructure and the app should run in cloud and on-premise using Kubernetes.

Or perhaps, you use multiple cloud providers and host modules on Azure and on AWS. In this case, a Docker image is the perfect choice for it. It can be hosted in different environments that support docker without any modifications.

Read also: How to Run Isolated Tests Using Docker Compose on AWS

2.Environment control. By this, we mean that some low-level modifications are required for your application. For example, you must install a database or network drivers on your OS. Or you need to run a Java web app on Spring.

It is impossible to do such operations for AWS Lambda right now. But Docker files natively support this, so the AWS Fargate should be an option here.

3.Trigger type. What type of nature does your future module have? Is it event-driven or request-driven?

There are a lot of triggers to start the work, like an SQS subscription, S3 events, DynamoDB events, and many others. AWS Lambda natively supports them. With that said, if you need to just answer API requests, the AWS Fargate might be a solid consideration.

Read also: Top 4 AWS Patterns of Highly Available API

4.Response time. You should ask yourself, how fast should the module respond? Whether it’s super critical to answering within a few milliseconds or, even seconds, will it be enough?

AWS Lambda needs some time to start, especially for the first request, so the response time won’t be all that fast. We know that there are some warming-up solutions, that make lambda be in tonus. But AWS Fargate is much faster and should be an option here.

5.Response size. Do you have a lot of data to be returned from your module? Are we talkin’ more than 6 MB?

AWS Lambda has this invocation (request and response) limit. You have to consider using paging or similar technique to split the load. Or you can go with AWS Fargate, which doesn’t have such a limitation.

6.Process time. You must analyze the expected heaviest operations in your future application. It may do some long-running calculations, data processing or other transformations.

If you know that, they will be in a 15 minutes time window, then you can easily go with AWS Lambda. AWS Fargate doesn’t have any time limits, therefore use it in all other long-running cases.

7.Memory usage. This question is roughly related to the previous one. Usually, when you have some long-running process it needs a huge amount of memory.

Try to estimate the data volumes you need to process in your application. Is it needed to work with large datasets? Do you need video or image processing? All these cases go along with memory usage.

AWS Lambda is not a perfect candidate for a memory-intensive work, so AWS Fargate should be really considered here.

AWS Lambda or AWS Fargate: the final decision

But wait. There’s more. The list above hasn’t covered all the factors and restrictions to consider between both these serverless technologies. We just guided you through the decision-making process you may have while designing a new application module.

Read also: How to Test a Serverless API Using AWS Serverless Gradle Test Runner

We definitely recommend you hit the official documentation on AWS Lambda and AWS Fargate limits, where you can find all the important aspects for your app.

Additionally, it’s always a good call to start your work with a small PoC, which will answer the main unknown questions about future architecture.

Interested in how AWS Lambda or AWS Fargate can help your business? GreenM is an AWS Select Consulting Partner. Contact us for finding the right deployment approaches to reach the expected results.

• AWS
• Data Engineering