WebFlow is an outstanding website design, development, and hosting platform. The WebFlow API provides webhooks for a variety of important events, and it signs its webhook requests to allow users to validate webhook requests, and therefore confirm that requests actually come from WebFlow.
The below code sample shows how to verify WebFlow webhook requests in AWSLambda functions using Python invoked via a Function URL, although the code will show the principles for validating requests in any language or platform.
Modern serverless applications on AWS are complex with a lot of moving parts. Mapping a developer workflow onto those applications can be difficult. This article discusses the developer workflow I have developed for complex serverless applications at aleph0, with example CloudFormation template and GitHub Action snippetes to illustrate the concepts.
AWSLambda is Amazon’s FaaS product. Pound for pound, it’s one of the best serverless computing products on the market. Easy to use, inexpensive to run (among FaaS offerings), and with compelling features like Layers, Extensions, and SnapStart, Lambda is a rock-solid choice for building serverless architectures.
However, its managed nature cuts both ways. The same FaaS features that make it so easy to use for vanilla workloads — just upload your program and go — also make it hard to use for anything that requires even a little customization, like ML models. I’ve done some significant work building out complex lambda functions for Java lately, and while deploying these complex workloads on AWS Lambda using Java is complex, the reward — a perfectly elastic, pay-for-uptime microservice architecture — is well worth the effort. But it turns out there’s a lot of the “Lambda iceberg” below the water to understand before you can expect to get these complex serverless applications working with high performance and reliability.
In this blog series, I will unpack what I learned in my journey to deploy an OpenCV-backed ML model onto AWS Lambda with minimal cold start, and show how the process can be used to deploy ML models on other backends, like TensorFlow Lite, onto Lambda as well.
As part of optimizing the HumanGraphics product, I am investigating different cloud architectures and their tradeoffs. Documenting my current “default stack” for a new webapp with compute (like an API) seems like a good starting point. Here it is:
Experienced cloud engineers and architects should should look at this diagram and agree that it’s at least a sane approach to building webapps, although certainly there are others. However, a less experienced cloud user might not understand why this architecture is sane. It turns out that there’s a lot to unpack in even this simple architecture — feature differences, business pressures, tradeoffs, and more. Let’s get into it.
I’ve added a new custom base image for Java 21 on Lambda to complement the community base images already available for Java 17, Java 18, Java 19, and Java 20. You can find the images on the ECR Public Gallery and DockerHub and the source code on GitHub. Java 21 is an LTS release with some of the most exciting new features Java has seen in a long time, so everyone should be looking to upgrade ASAP!
There are a couple of known issues, particularly around CDS (Class Data Sharing), per the but they appear to be (mostly) cosmetic at first blush. It’ll be fun ironing that out.
I’m also looking forward to releasing a custom image for Java 21, too, as soon as an updated Amazon Corretto image drops.
I’m using AWS Step Functions to do some complex orchestration of services that could span more than 25,000 state transitions and exchange data sets larger than 256KB, so I’m making heavy use of the new distributed map feature. It definitely makes things easier than the old everything-is-a-child-execution approach! However, the ResultWriter field is not particularly well-documented, so I’m hoping to shed some light on it here with a simple example.
I’ve added a new custom base image for Java 20 on Lambda to complement the community base images already available for Java 17, Java 18, and Java 19. You can find the images on the ECR Public Gallery and DockerHub and the source code on GitHub. All the new features in Java 20 are in preview or incubator, as befits a non-LTS release, but for those who like to live life on the bleeding edge, there’s lots of new toys to play with. These base images will let you get started.
