from Andy Boothe
Based on the results of this JMH benchmark, string operations are faster than regex operations in Java, even if the two operations are logically the same, like String.equals and Pattern.matcher/Matcher.matches.
In some cases, much faster.
Continue reading “In Java, Strings Much Faster than Regexes, Even for Same Operations” /**
* Gets all of the headers with the given name. The returned array
* maintains the relative order in which the headers were added.
*
* <p>Header name comparison is case insensitive.
*
* @param name the name of the header(s) to get
*
* @return an array of length ≥ 0
*/
@Override
public Header[] getHeaders(final String name) {
List<Header> headersFound = null;
for (int i = 0; i < this.headers.size(); i++) {
final Header header = this.headers.get(i);
if (header.getName().equalsIgnoreCase(name)) {
if (headersFound == null) {
headersFound = new ArrayList<>();
}
headersFound.add(header);
}
}
return headersFound != null ? headersFound.toArray(EMPTY) : EMPTY;
}
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 AWS Lambda functions using Python invoked via a Function URL, although the code will show the principles for validating requests in any language or platform.
I couldn’t find an example payload for CloudWatch Logs data delivered by a Kinesis Firehose stream to a Lambda function URL, so I set one up.
Sample payloads appear below, as well as a walkthrough of the process I used to create the data stream.
Continue reading “Sample AWS Kinesis Firehose CloudWatch Log HTTP Endpoint Payload”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.
AWS Lambda 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.
Continue reading “Unpacking My Default AWS Webapp Architecture”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!
I’ve also released a custom Lambda runtime for Java 21, if that’s more your speed.
These should be plenty to get you started on your AWS Lambda + Java 21 adventure!
Continue reading “Community-Managed AWS Lambda Base Images for Java 21”By standing on the shoulders of giants (I’m looking at you, Mark Sailes), I was able to turn around an AWS Lambda Custom Runtime for Java 21 on Java 21 launch day. Instructions to use it are in the repo’s README. All files required to create your own function are in the releases, so no building required.
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.
Happy hacking!
HumanGraphics is a REST API that converts names, locations, and faces into structured data and demographics estimates. Sound interesting? Take it for a test drive!
And it launched today! Check out the website for a special launch offer!
Continue reading “Announcing HumanGraphics!”