This is the repo for swyx's blog - Blog content is created in github issues, then posted on swyx.io as blog pages! Comment/watch to follow along my blog within GitHub
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)
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] (https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) 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):
source: devto devToUrl: "https://dev.to/swyx/you-can-run-containers-on-aws-amplify-now-23ka" devToReactions: 62 devToReadingTime: 3 devToPublishedAt: "2020-12-11T14:24:37.337Z" devToViewsCount: 4118 title: You Can Run Containers on AWS Amplify Now published: true description: AWS just added the easiest way to deploy long running serverful code alongside a serverless architecture. category: tutorial tags: Tech, AWS slug: amplify-serverless-containers cover_image: https://d2908q01vomqb2.cloudfront.net/0a57cb53ba59c46fc4b692527a38a87c78d84028/2020/12/10/Artboard-Copy.png
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.
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:
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] (https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) of AWS Lambda.docker-compose.ymlexample 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):
{% twitter 1337088737243783174 %}
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.