Where does Fargate fit into your serverless toolkit? (reader question)

AWSArchitectureContainersDaily Email

Email list member Glenn Stovall wrote in asking a great question:

How does Fargate fit into all this? It sounds like its “serverless containers” is that right? I thought containers were for full on applications that would require persistence, how would that work?

The short answer to this (from the serverless side of the fence) is that Fargate serves a few narrow compute use cases that do not fit will within AWS Lambda. You can certainly build “full on applications” with Lambda as your primary compute service (plus API Gateway, etc) just as you can with classic container-based architectures (on Kubernetes or ECS).

Fargate provides the flexibility of being able to fully define your own runtime (by supplying your own Dockerfile) whilst not having to worry about provisioning or managing the underlying cluster of EC2 instances that the container could run on. Its pricing model is somewhat similar to Lambda in that you only pay for as long as your container is running (including startup time to download the container image). However, it has a minimum charge time of 1 minute so is generally best suited to longer-running tasks.

Here are a few use cases where you might consider using Fargate over AWS Lambda:

  • You have a pre-built container image for performing a specialised compute task that would be difficult to recreate within a Lambda environment
  • You have a long-running compute operation that could take longer than 15 minutes (the Lambda maximum) to complete and that cannot be broken up into smaller sequential or parallel tasks
  • Your workload has a consistent throughput AND you need the portability containers give you of being able to lift and shift your compute workload to another cloud provider (which would require some code refactoring if you used Lambda) but still want the managed instance provisioning that Fargate provides over classic ECS and Kubernetes.
  • Your compute task needs a large large local filesystem greater than Lambda’s 512MB temp storage limit (e.g. for video processing). This is no longer the case as Lambda now supports mounting EFS file storage.
  • Your compute task needs more than 3,008 MB of memory (the Lambda limit)

Hope this helps.

— Paul

P.S. If you’re a developer wanting to learn more about the non-technical aspects of growing your career, then you should definitely check out Glenn’s new podcast Production Ready which explores the human side of software.

Originally published .

Other articles you might enjoy:

Free Email Course

How to transition your team to a serverless-first mindset

In this 5-day email course, you’ll learn:

  • Lesson 1: Why serverless is inevitable
  • Lesson 2: How to identify a candidate project for your first serverless application
  • Lesson 3: How to compose the building blocks that AWS provides
  • Lesson 4: Common mistakes to avoid when building your first serverless application
  • Lesson 5: How to break ground on your first serverless project

    ☎️ Serverless AMA

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>