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.
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:
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!
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:
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.
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!
Truly composable and maintainable CloudFormation is now within reach
How will we build apps in the years to come? Werner gave us insights in his re:Invent keynote
Achieve operational and cost management success
The Stackery team combed the schedule to find the must-attend events
Or, how to consume re:Invent content to build better apps today