Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: Hello and welcome to AWS Bites, the weekly show where we answer questions about AWS in about five minutes. My name is Eoin and again, I'm joined by Luciano. Before we get started, just make sure to give us a follow and subscribe so you can be notified when we release the next episode. And today's question we've got is, should you use Fargate or AWS Lambda for containers? What do you think, Luciano?
Luciano: Yeah, I think it's important to start by clarifying what do we really mean with the word container, because I think there are at least two different ways of seeing a container. One is when you look at a container as a packaging tool, so you put all the code in this unit and there is also the idea of running that code. So considering that container as a runtime environment, right? So in that sense, in the context of Fargate and Lambda, if you're looking for a container runtime that is maybe closer to something like Kubernetes, probably Fargate is a better definition, a better service for that concept.
And instead, if you're looking just for something that helps you to run code without worrying too much about how it's running, then maybe Lambda is a better service for that type of idea. And in general, also, it might make sense to think in terms of long-running services rather than just run some code when an event happens. So also that's another way of seeing the difference between Fargate and Lambda, because Fargate is definitely more suitable for long-running services, maybe more traditional web servers like, I don't know, an application written with Django or Spring Boot or Laravel, so more traditional MVC frameworks where you are running a long-running server, that server is accepting multiple requests, and all of that could be a unit that you are running as a container on Fargate. Instead, with Lambda, it gets much different, even the way you are going to write your code, because you generally receive an HTTP event, there will be one Lambda dedicated to respond to that HTTP request, and it's going to have to try to respond as quick as possible, because of course your pricing is also related to how quick you can respond. Yeah, but with that being said, I guess it might be interesting to see how do you get started with both? What do you think on that front?
Eoin: Yeah, Lambda is still the more serverless kind of solution, so it's easier to get started, you have less to do. With Fargate, you have a lot of configuration to do, you have to create a cluster and a service and you have to understand what a task definition is, and what a task is, so it's a lot more of a container orchestration kind of an environment. With Lambda, it's much more about run this code in response to this event.
So like you say, containers then are just a packaging mechanism, so if you're looking for something that takes a lot of the heavy lifting off you, Lambda is definitely the way to go. You can simplify the Fargate deployment process like the CCS patterns in CDK, which are quite useful for that, but realistically they're just hiding a lot of that complexity for you, you have to kind of understand what magic is going on under the hood.
The other thing about the difference then between Lambda and Fargate is it's all about limits, and Lambda's limits are reasonably well known, but when you deploy Lambdas with a zip, you're limited to 250 megs of code, but with container images which were announced last year, you have 10 gigabytes, you can put 10 gigabytes of a container image up there, which really changes the number of use cases you can use for Lambda.
Your memory limit is also 10 gigs in Lambda now, but you don't get any disk, right, you will leave temporary storage up to half a gig, but that compares with Fargate where you have up to 30 gigs of memory and you can get up to 200 gigs of ephemeral storage. So Fargate in that sense, in terms of memory and storage allows you to do a bit more, but interestingly enough Lambda allows you to get up to six CPUs if you've got a lot of concurrency going on in your compute, and Fargate's limit is actually just four CPUs, so it depends on your context and you have to evaluate each thing separately. So understanding that Fargate allows you to control CPU and memory separately, but with Lambda you move the memory slider that also moves the CPU slider and the amount of networking bandwidth you have, so it's all about your context and understanding which works best for your workload. So is there anything else we need to cover off when we're comparing Lambda and Fargate for containers?
Luciano: Maybe we can talk very quickly about cost, but again, it's very hard to give you a recipe to calculate the cost because it really depends on the type of application you are trying to run and how you build that, but I suppose in general we could say that Fargate tends to be cheaper and more controllable. As you said, you can control memory and CPU independently, so if you have applications that don't require a lot of CPU and maybe a lot of memory or vice versa, you can probably fine tune Fargate more than you could do with Lambda, so that could help you to save money.
Also Fargate runs on spot instances if you want to, so that's another option that will help you to save a lot of money. I think it's up to 70% and I think we have the article we already mentioned in a previous episode that you wrote that can give you a lot more details around that, so we're going to put that in the links. Another thing in general, another dimension that is worth mentioning in terms of cost is that Fargate, there might be a little bit more waste in terms of bootstrapping the container and starting to run it and also shutting it down. While with Lambda you tend to get a lot more instantaneous times for bootstrap and shutdown, so if you have very short running tasks, maybe it's better to just write a Lambda and get the Lambda to do that work. You can also save money that way because you're going to be able to fine tune for those times and save money on the bootstrap time, but again, you'll need to make an analysis and see exactly how the different rules that you need to satisfy for your application will affect the pricing and the characteristics of the runtime. Yeah, that's a really good point.
Eoin: With cost, always have to be aware of it and don't make assumptions about what's more expensive. Your mileage may vary. So we'll link to that article in the show notes again. And also there's an article that we created around the topic of how Lambda container images work, which might be useful for people who are coming from a traditional container deployment environment. So let's leave those in the show notes and wrap it up there. I think that's all we've time for. Please do follow us so that you get notified about the next episode and we'll catch you for the next episode next week.