DEV Community

loading...
Cover image for You Can Run Containers on AWS Amplify Now

You Can Run Containers on AWS Amplify Now

swyx profile image swyx Originally published at swyx.io ・3 min read

The second week of AWS re:Invent brought a surprise major announcement from the AWS Amplify team: You can run Docker containers as AWS Amplify APIs now!!!

The main Achilles heel of migrating to serverless architectures is having to relearn and rewrite traditional serverful code. With the new Amplify Serverless Containers, it is now possible to deploy code in stateful Docker containers with the exact same workflow as the rest of Amplify CLI.

# example of the new CLI workflow, see docs for details
# Amplify CLI version 4.39+

$ amplify init # if you're setting up new Amplify project

$ amplify configure project
 > Do you want to enable container-based deployments? Yes

$ amplify add api

Please select from one of the below mentioned services: REST
? Which service would you like to use 
  API Gateway + Lambda 
❯ API Gateway + AWS Fargate (Container-based) 
Enter fullscreen mode Exit fullscreen mode

For the first time, this opens up the possibility of running Rails, Django, Laravel, or any other traditionally serverful APIs seamlessly alongside a serverless architecture. If it fits in a Docker container, you can run it! This thus unlocks the full capabilities of their respective ecosystems.

Emphasis on seamless integration: this means that frontend and mobile developers don't need to go to 9 months of cloud school (having to learn the details of VPC, subnets, NACLs, IAM policies, SSL generation, continuous deploy, cost optimization, etc) just in order to get a containerized API up and running on AWS.

This, to me, is a big deal for a number of interrelated reasons:

  • Long Running Code: AWS Lambda functions are limited to 15 minutes. If I need to run longer tasks, like video conversion or batch processing, I would have to jump out of my existing workflow and use a completely different set of tools. Now, I can run Rails + Sidekiq or Flask + Celery with just an industry standard docker-compose.yml. Because Amplify's Serverless Containers feature uses AWS Fargate, we may in future have the option of vertically scaling system resources as needed, beyond the traditional resource constraints of AWS Lambda.
  • Access Entire Ecosystems: Libraries and frameworks that were written for serverful paradigms typically become useless when shifting to serverless/Jamstack architectures, requiring yet another learning curve and search for tools. Now you are free to mix and match them - anything that runs in a Docker container is fair game (and everything runs in a Docker container!)
  • Incremental Migration: This also means that it is no longer a heavy lift to move existing apps and codebases to a serverless/Jamstack architecture. As long as you can separate your UI layer from your API layer, you are now able to host your UI on Amplify Console, and your APIs as a REST or GraphQL service with API Gateway + AWS Fargate.
  • Easy Access to other Amplify categories: because this plugs right into the Amplify API category workflow, this means that your code inside your containers get all the same benefits of Amplify APIs like easy authentication with Amazon Cognito and easy access to Amplify-managed resources like Storage, Functions, GraphQL and more. Because networking is handled for you, you can even talk to other containers - the default docker-compose.yml example in the CLI shows how you can make an Express (JS) app interoperate with a Flask (Python) app!

So, yeah. I think this is awesome - You can run basically anything on AWS Amplify now - meaning that you spend less time wrangling infrastructure and more time writing valuable features. Don't take my word for it, see Ant Stanley (organizer of Serverless Days and overall cloud expert):

P.S. for those who are making comparisons with AWS CDK, note that this capability was actually made with CDK - it solves a higher level problem than CDK.

Discussion (3)

pic
Editor guide
Collapse
khrome83 profile image
Zane Milakovic

I feel like this is similar to what Vercel (now) did with there first version they have now deprecated. Though they were not using fargate. It’s interesting how these things going in circles. I feel like the biggest thing this give amplify is a answer against render, fly and the other services that make containers dead simple.

Collapse
siddharatha profile image
Sid

Would this be the way to run sapper / nextjs with amplify where the dynamic pages/ requests will be served through fargate containers ?

Collapse
swyx profile image
swyx Author • Edited

we don't officially encourage serving HTML from fargate containers, bc it is cheaper and faster via amplify hosting (static S3 pages and cloudfront). This is why I emphasize them as part of the APIs workflow.

however we do allow it - this is why Serverless Containers are enabled for Amplify Hosting. This is useful for, for example, hosting Next.js SSR.