Yet another mind-blowing set of announcements on today’s keynote, presented by Dr Werner Vogels, technology officer and vice president at AWS.
So much to consider, and so many of our established architectural choices to reconsider. This for me just reinforces how fluid our architectural patterns need to be in order to access the very best availability, scale and cost savings that AWS cloud can deliver.
The very word “architecture” can almost imply a final state but here at KCOM we recommend our customers consider their cloud architecture to be a living thing, adapting not only to meet new business objectives but also to re-evaluate past decisions. We must continually look for potential simplifications or optimisations to the seemingly endless torrent of new services and features that AWS recurrently provides.
Some highlights for me include:
A new Lambda Runtime API. Simply put, this opens up the event mechanism in Lambda to a point that it’s now possible to bring your own runtime and therefore support practically any language. Amazon has already produced a few reference implementations of C++ and Rust runtimes and we expect many more to follow from AWS and the Partner Network. Even porting legacy COBOL code into a serverless architecture is now possible, significantly revealing new migration opportunities.
Alongside this was another Lambda announcement that perhaps is equally important, Lambda Layers.
One of the challenges with managing Lambda is common or duplicated code used in multiple functions - libraries or frequently used assets such as SDK’s and Frameworks and now even complete runtimes. Typically, these dependencies would be packaged within your Lambda function and referenced directly. An update to one of those assets would require updates to each individual function which at best is a management burden and at worst could result in inconsistencies or even security challenges.
Lambda Layers introduce a new common artefact that can contain arbitrary code or data, this can be referenced simultaneously by multiple functions, even operating in multiple accounts or environments. Those functions are transparently preloaded with the published assets when they execute. Technology partners will use this to provide a deployment mechanism for their own layers integrating monitoring, security and management capabilities. For everyone else it’s going to simplify the management and deployment of common code artefacts within your serverless architecture.
ALB support for Lambda
AWS Application Load Balancers now support Lambda functions as a target, allowing a Lambda function (or a group of functions using the ALB’s content-based routing) to directly respond to HTTP/S requests, this opens up a whole new world of integration options for serverless computing.
AWS Step Functions Integrations
AWS Step Functions has been significantly extended beyond the initial Lambda integration. It’s now possible to perform DynamoDB get’s and put’s, launch an AWS batch job, start a container task on ECS, integrate with SNS and SQS, start a Glue job or work with SageMaker. This has the potential to massively simplify Serverless Workflows with Step Functions taking care of managing the workflow state.
Amazon Managed Streaming for Kafka
Although only in preview, another interesting and perhaps more predictable announcement was Amazon MSK. Bringing Kafka as a service to the growing list of AWS managed services that relieve us of the complexity of operating scalable and resilient Kafka clusters on the AWS Cloud.
This is just the surface of it of course, for the full list of announcements and launches look here and then go and re:Invent your cloud architecture.