originally posted on stackery.io/reinvent
Wait, did AWS just rewrite the manual again for building apps?
Andy Jassy’s re:Invent keynote today was chock full of new features and services. I’m here to help break down the most important news related to modern application architecture. If you’ve read my first post about how to consume re:Invent content, you won’t be surprised to see below that I’m pointing out news that tell us a larger story about how to ship applications in 2021 and beyond.
Container Image Support for Lambda Functions
Modern applications use managed services wherever possible. The purest form of managed services for compute is AWS Lambda. Write your code and AWS will bill it for the amount of time (now down to individual milliseconds!) it runs.
While the runtime model of Lambda is exceptionally powerful, the tooling for creating Lambda packages had some issues. Lambda packages had to be uploaded as Zip files less than 250 MB in size. This caused two problems:
- Functions needing more than 250 MB of data, say for AI/ML workloads, didn’t fit
- Organizations with a lot of tools and processes in place to manage Docker Container Images couldn’t reuse them for Lambda
Now you can use Container Images for Lambda and specify images up to 10 GB in size! Check out our blog post for more info.
What’s the point? Now, organizations with either Lambda or Docker Container packaging tools and processes can adopt Lambda Functions more easily!
Aurora Serverless v2
If you aren’t steeped in AWS terminology you may need a refresher. AWS Aurora is a managed MySQL or PostgreSQL database cluster service, and Aurora Serverless is the auto- and semi-horizontally scaling version of it. Last year, Aurora Serverless v1 was introduced, and it provided lots of important capabilities to help teams manage reasonable-sized DB workloads in a cost-effective manner.
Now, AWS has come back with a second version in preview.
Key improvements include:
- Much faster scaling (“Scale database workloads to hundreds of thousands of transactions in a fraction of a second”)
- Global provisioning (Great for disaster recovery planning, no more need to manage snapshots cross-region)
- Read replicas (Improves scalability for workloads with lots of read-only functionality)
What’s the point? AWS clearly sees databases as a way to outdo the competition. Andy Jassy specifically talked about Microsoft’s MSSQL pricing as justification for why customers are choosing AWS for workloads.
AWS is innovating by making it so much easier to operationalize a highly scalable and resilient RDBMS system. When building new architectures, use DynamoDB if you don’t need relational solutions, but Aurora Serverless makes it more reasonable to build modern apps with relational databases than ever before.
AWS Proton: Enterprise Platform For Centralized Deployments
Twitter is abuzz with interest around AWS Proton, the new service that aims to help enterprises manage deployments. This thread from the product lead for Proton explains the target development process:
You’ll notice the centralized platform team (called “Administrators” in this image from the official docs) writes and maintains the infrastructure code, and the development teams write and maintain the business logic for applications and services. Using Proton, these two teams work together to define environments and deploy services into them.
What’s the point? AWS finally has a single service solution to manage both application resources and environments they run within. This is great, and there are other neat concepts included, like service versioning and mechanisms to share resource identifiers across services and within an environment.
However, this guarded platform approach is an anti-pattern for modern architecture development. It splits architecture development between teams. Having the central platform team own all infrastructure development also creates a bottleneck for the development teams.
For example, each Lambda Function added to an application will require the development team to ask the platform team to create the Function and its IAM Role. And the IAM Role must to be granted permissions to other resources it needs to interact with. There’s a lot of information here that must be transferred between the two teams in order for the platform team to start working, and in the meantime the development team is blocked until the Proton templates are updated and re-provisioned.
Proton is in preview, and I expect many concerns to be addressed over time. I’m looking forward to best practices solidifying around environment management and resource sharing. I’m thankful Proton is at the very least a great attempt to solve these challenges!
Now what?
These are just the most interesting three announcements I saw that are shaping my understanding of modern application development now and into the future. But re:Invent is just getting started! With the greatest announcements already shared in the keynote, it’s time to turn our attention to the leadership sessions and dive into product sessions to understand how best to use these new capabilities!
