from Andy Boothe
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”