AWS re:Invent 2022 was reportedly attended by over 60,000 people. As a first time attendee I was completely taken aback by the sheer scale of the event, and it did not disappoint.
BUILD SYSTEMS THAT CAN EVOLVE. AND THE BEST WAY TO MAKE EVOLVABLE SYSTEMS, IS TO FOCUS ON EVENT-DRIVEN ARCHITECTURES
The main theme of the week was Event-Driven Architectures. A theme which was skilfully delivered in Dr. Werner Vogels keynote on Thursday.
As Werner eluded to in his keynote; Event-Driven Architectures are not a new pattern. In fact, they have been a popular approach to building loosely-coupled applications for many years. Werner referenced the Distributed Computing Manifesto; a canonical document released in 1998, which transformed the architecture of Amazon’s e-commerce platform. The document hints at things to come and provides some early examples of using events to orchestrate a distributed system.
There were many noteworthy announcements this year, many of which were communicated pre:Invent. However, in this post I will focus on my personal highlights.
Amazon EventBridge Pipes
Werner began his announcement with an introduction into the pipes command in Unix, and how to this day it remains a very powerful tool.
Up until this release, a large part of developing event-driven applications on AWS was handling communication between AWS services – typically this would consist of glue code to bind AWS services together, for example; if we wanted to propagate DynamoDB table changes to an SQS queue, we would need to write a Lambda function to handle this. We would also need to understand how to interact with SQS and implement error handling, exponential back-off, retries, etc. As our projects and platforms scale, the burden of maintaining this code multiplies.
EventBridge Pipes aims to take this pain away by simplifying service integrations, behaving similarly to Pipes in Unix Operating Systems, facilitating communication between AWS services in a consistent and AWS managed way.
Step Functions Distributed Map
Step Functions Map states have been around for some time and provide a means to execute a set of workflow steps for each item in a dataset. This is extremely powerful, and a feature of Step Functions I have used in a number of projects. One of the major limitations of the Map state was that it only supported up to 40 concurrent iterations.
Enter Distributed Map...
Supporting up to 10k concurrent iterations, Distributed Map opens up a world of possibilities for large scale, parallel data processing of objects stored in S3. I can already see where this might useful for many of the customers I work with.
Cold starts have been one of the hurdles that Java developers have faced when looking to adopt serverless, more specifically when working with Lambda. This is due to the nature of the Lambda Function Lifecycle; the process involved in spinning up your execution environment and eventually executing your code.
Lambda Snapstart aims to significantly reduce cold starts by taking an immutable, encrypted snapshot of the memory and disk state, and caching it for reuse. At launch, this feature is limited to the java11 runtime, which is understandable, since for example, Lambda Functions using frameworks such as Spring Boot can suffer from cold start times of up to 10 seconds.
SnapStart is going to be a game changer for Java developers looking to modernise their applications on Lambda. I’ll be keeping my eyes peeled for further runtime support in the coming months, as it would offer some really positive performance gains for a number of different workloads, such as ML.
AWS Application Composer (Preview)
It’s fair to say that AWS’s Console UX can be difficult at times. However, credit where credit is due; they have really knocked it out the park for a few services. Namely Step Functions, where we’re able to visualise our workflows in an easy to navigate tool within the console.
AWS Application Composer provides a very similar experience, in terms of being able to use a simple drag and drop canvas to design and build serverless architectures. App Composer aims to reduce the complexity of getting to grips with the process of stitching together serverless services, and learning IaC tooling for ongoing maintenance of such services.
App Composer is flexible, in that you’re able to start completely from scratch or import existing projects using SAM or CloudFormation templates. It then maintains the visual representation of your application architecture in sync with your IaC, in real time.
Whether you are new to AWS Serverless or a seasoned professional; I think Application Composer will offer a lot of value to you.
As an AWS Community Builder I had the opportunity to meet and network with fellow builders and found the experience to be very inspiring. It’s a brilliant program that provides access to a network of like-minded AWS enthusiasts, specialists and tools to help you on your AWS journey. For anyone wanting to learn more about the program and join the waitlist for the next application round please visit here.
I also did some work for AWS Comsum; interviewing a number of AWS folks, who gave up their time to talk to us and give us some really great insights into the various announcements and sessions they were running. You can find the interviews here.
That’s it for the recap of my re:Invent 2022. Thanks for reading!