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 Testing Workshop

    Testing is one of the hardest challenges for developers building with serverless on AWS. Event-driven async flows and inadequate local environments make it difficult to write effective tests while maintaining a fast feedback loop.

    In this 4-week online workshop, you’ll learn:

    • Patterns for writing tests for commonly used AWS services
    • What you should and what you shouldn’t write tests for
    • How and when to deploy unit, integration and end-to-end tests
    • How to manage test configuration and maximise test reusability throughout your pipeline
    • Workflow optimisation techniques

    Plus with the weekly group sessions, you get personal feedback on your testing questions.

    The next workshop is in November 2020. Early bird subscribers get a large discount.

    Learn more...