Introduction
We will go over a comparison of AWS Fargate vs AWS Lambda Functions.
Did you know that both solve the same problem in different ways?
Read on and I’ll explain why AWS has introduced two technologies that tackle the same problem but with a different approach on solutioning.
We will break down this in the following sections:
- What is the Difference between AWS Fargate and AWS Lambda Functions
- A quick comparison between the two
- A Detailed Comparison of AWS Fargate vs AWS Lambda functions
I have used both extensively in my projects and have a lot of experience to know the ins and outs of each technology. I believe both have a place in my heart but which one should you use the most and why? I will be breaking down this and you can make your own mind up, my goal in this article is to provide you with facts in order to better decide along with some use-cases.
We will go point by point on how both compare in various tasks and what is the advantage of each of them.
What is the Difference between AWS Fargate and Lambda
At the very high level you need to know that both AWS Fargate and AWS Lambda functions are server less implementations by AWS that let you execute your code in a fashion that does not require you to setup and maintain a server.
Their core difference lies upon the fact that Farget accomplishes this using a container approach which gets built by one of the pre-defined templates or your own whereas Lambdas are more like pre-defined execution environments that AWS themselves maintain for you.
The above statement means that you will be responsible with Fargate to implement and maintain all the dependencies including packages or libraries that your application may need to run properly.
In the sections below I will be providing a very high level summary table of their differences and how they compare and later on I will break down their differences section by section with extensive detail.
Quick Comparisson
If you don’t want to spend a lot of time going through the differences between the two, I made a quick comparison table for you to go through and see the differences between the two and hopefully make a choice for yourself.
For more detailed information and how these two compare you will need to keep reading on the sections below as I answer very popular questions and I go into depth on their differences so you can make a more educated choice for your next project.
AWS Fargate VS Lambda
| AWS Lambda | AWS Fargate | |
|---|---|---|
| Initial Setup | Easy | Difficult |
| Ease Of Use | Easy | Average |
| Support | Good | Decent |
| Deployment | Easy | Average |
| Security | Very Good | Good |
| Speed | Good | Very Good |
| Integration | Very Good | Low |
| Features | Low | Good |
| Popularity | Very Good | Low |
Detailed Comparison AWS Fargate vs Lambda
Now that we went over some definitions lets start diving into the deep waters and break down each feature to help you decide which solution is better for you. I will try to give you all the facts from my experience on using both. Keep in mind that Fargate is newer than Lambda’s so it’s normal to be behind in some areas but like I said earlier the project is still very promising and I think there’s great room for improvement.
Initial Setup
The first section I want to discuss is the initial setup of the environment where your code will be executing on. The edge here is on AWS Lambda functions as they are pretty much hands off and you don’t really need to do anything. More specifically all you need to do is bundle your code together with the libraries you are including and it will just work once deployed in the AWS infrastructure.
In contrast with Lambdas, unfortunately with AWS Fargate you need to put more work to get it working properly. The initial setup of your environment such as the container that will encapsulate your code needs to have all the dependencies met along with the libraries. So if you have a runtime you need to setup you will need to ensure this is properly setup running if you are building your own custom image.
Furthermore you also need to maintain and update this as the time passes by. Otherwise like EC2 you can select from a pre-defined list (which currently is limited) of containers and base your changes off that if you need to do any customizations.
Once you do all the above setup then you should be able to get it running similar to Lambda’s.
Winner: AWS Lambda
Ease Of Use
Both technologies are based off AWS infrastructure. In general AWS makes it very easy to use their stuff especially if you are staying within their ecosystem. The problem here and the sticking point in my opinion is that you need to do extra work if you are going with AWS Fargate. The extra work is basically going through the initial setup that I mentioned and doing periodic maintenance.
Furthermore you need to understand how containers work and how well the integrate from an architectural point of view with the rest of the AWS services. On the other hand AWS Lambdas blend in very well and you don’t really need to have this extra knowledge. All of the above increases the barrier of ease of use for a beginner that’s now starting out which makes AWS Lambda’s much easier to work with.
Winner: AWS Lambda
Support
For support since both services run in AWS they are covered by your support plan. However support does not start there or end there in any way. The community around it, the forums and the people that have knowledge and know-how I believe are all forms of support. Some of them may be indirect levels of support for example lets say you have a question and it’s not detailed very well in documentation you can quickly check other websites or blogs like mine to find an answer.
Since AWS Fargate is a new technology and there’s not a lot of resources around for it, that kind of information at least initially will be limited. This means you will need to leverage a better AWS plan to get the answers that you need. Don’t get me wrong I have used AWS support in the past but in a business environment where the quick turn around SLA’s are there cost more money which your organization may not have initially and in some cases it may be prohibitive for a startup.
If you feel confident and sometimes may want to dive into the deep on your own I’d say this may not be an issue but someone requiring support from day 1 with limited amount of time and resources will find a better sanctuary with AWS Lambda’s.
Winner: AWS Lambda
Deployment
Deployment is also an important factor when it comes to using any Serverless technology. More particularly it has a lot to do with how quickly your setup comes online and starts serving it’s initial purpose which is to get your code running smoothly without issues.
As we discussed in the initial setup AWS Lambda is pretty much hands off and does not require any kind of work from your end. On the other hand AWS Fargate does require more work which means you will basically have a harder time deploying it.
If your workflow starts from AWS Batch or an API Gateway you need to think through how this would be triggered architectually and how it will play in the bigger picture of your project. In my opinion AWS Lambda functions abstract a lot of this effort for you and you simply don’t have to worry about it leaving you with a cleaner and easier solution.
Winner: AWS Lambda
Security
Both services are hosted and maintained in the AWS environment which means from an infrastructure point of view both will be naturally secure. However with AWS Fargate as we discussed in previous sections you have the option to build your own environment and container.
This means whenever there’s manual work involved you are now maintaining also the security of your setup in some direct or indirect way. This leaves you open to the fact that you may make some misconfiguration or have an older version of an environment deployed that has vulnerabilities that require patching.
Since there’s an extra level of support needed here it’s obvious that AWS Lambda by nature is more secure as AWS takes that load for you on the following tasks:
- Patching vulnerabilities
- Correcting misconfigurations
- Keeping environments up to date
- Following proper security standards
As you can see the list is pretty big of tasks you may need to do as extra work with AWS Fargate in this case the edge goes easily to AWS Lambda functions.
Winner: AWS Lambda
Speed
Execution speed is an important consideration when going with a serverless technology. I would say this is one of the closest battles of all the comparisons we have done up to now. Let me explain the reasoning. Since both rely on your code being deployed, executed and then destroyed they follow a very similar if not identical model on the overall timeline.
The difference here is that your AWS Fargate container will not be as optimized and as fast to be span up versus the highly optimized instance of an AWS Lambda function. AWS puts a lot of effort to keep the pre-defined execution environments such as Python, NodeJS highly optimized with the least amount of dependencies needed in order to run.
The above keeps your environment lightweight and faster to start. That start time from when your instance goes from cold to hot (running) is very important if it is being invoked many times a day. Imagine an API invocation to generate a result or a stock transaction it slowly adds up and latency is critical if you want a fast response. If it’s more of a background batch job that doesn’t require an immediate real time response then it’s a non-issue but since we are seeing this in a holistic way we need to take all scenarios into account. From the above it’s important to understand the AWS Lambda is faster but your use-case may be unaffected.
Winner: AWS Lambda
Integration
When it comes to integration AWS Lambdas have been around for a very long time in the AWS ecosystem. This makes them high integratabtle and useable. The most common in my opinion use-case is invoking them from an API Function. While AWS Lambdas support this, AWS Fargate does not. I do not want to make this as the most important factor but it generally covers a very wide range of scenarios of where serverless functions initiate from.
Since it’s very important to understand AWS Lambda functions have around 12 trigger points of how they can be invoked on the other hand AWS Fargate does not have so many I believe right now there’s about 4 ways to trigger it. As you can tell the difference for integration is massive and it does play a huge role if your project is hosted entirely on the AWS ecosystem.
Since it’s a new technology that’s constantly evolving I’m expecting these numbers to drastically change and Fargate to do a lot better in the coming years in terms of integrating. If you are one of the lucky people that your code integrates with the triggering points you want then it’s a non issue but since the difference is so big right now I have to give this to AWS Lambda functions.
Winner: AWS Lambda
Features
Features, features this is a very common question that keeps coming up in serverless functions. Since inception I believe serverless technologies have been oversimplified and over the years they started to evolve to the point where the user wants more. Yes this goes against the principle and simplicity of a serverless function but I think due to popular demand we are bound to see them evolve and get more advanced.
Since it’s so popular I’m going to talk a bit about it here and give you my perspective. Flat out I can tell you that Fargate is much better because you have complete control of your execution environment. This means the possibilities and features differences you may have are also endless. On the other hand AWS Lambda functions stick to the primary principles of serverless and are super simple by nature not really offering a lot of features on what you can do with them outside of executing your code.
I’m still torn on the philosophical dilemma on whether or not you should have a lot of features on a serverless technology so for now I’d say that I’m gearing towards keeping my code simple. But if you are the person looking for those features and the extra spiciness in your serverless life then AWS Fargate is the solution for you.
Winner: AWS Fargate
Popularity
Let’s close this final comparison on popularity. For this we will be using the help of google trends to see how well adopted each of those ecosystems are. To make it a bit more fair I’m going to limit this to the last 90 days as Fargate is a fairly newer system to AWS Lambda functions. Since AWS Lambda functions have been around since the start of time it will not be a fair comparison to backdate this popularity graph.
As you can see above AWS Lambda still wins by a long margin when it comes to popularity. I would dare say that Fargate is still fairly unknown to the world and it is very promising for the future.
The trend above does not discount in any way AWS Fargate which I believe does a good job at what it is designed to solve. In this case AWS Lambda functions are the clear winner and comes on top in the comparison.
Winner: AWS Lambda
Conclusion
We were able to successfully go over AWS Fargate vs AWS Lambda Functions, hopefully I answered any questions you may have had and helped you get started on your quest of selecting the right AWS service to run your server less code in.
If you found this useful and you think it may have helped you please drop me a cheer below I would appreciate it.
If you have any questions, comments please post them below or send me a note on my twitter. I check periodically and try to answer them in the priority they come in. Also if you have any corrections please do let me know and I’ll update the article with new updates or mistakes I did.
Which one would you pick and why?
I personally think both have their place in the right project. It really depends on what you want to accomplish and how you want to go about it. Even though I love AWS Lambda functions I think sometimes the limitations of them handicap you from accomplishing the task at hand, fargate is a fresh approach and with a bit of extra work lets you accomplish more things.
You can find more information about the projects in the links below:
If you would like to find more articles related to Python: