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

    🩺
    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>