One of the most misunderstood aspects of Lambda is how throttling applies to async invocations. Or rather, how it doesn’t!
The TL;DR is that you will never experience throttling when you invoke a function asynchronously.
It also means that despite SNS and EventBridge having longer retry periods than Lambda’s internal queue, these have no practical impact in the case of Lambda throttling.
Read the full post to understand why.
Gregor Hohpe said something that has me mulling over for some time now. Essentially, he asked, “Should we narrow the definition of serverless to mean just function-as-a-service (FaaS)?” “Serviceful” For context, I’m firmly in the “serverless means serviceful” camp: a) Serverless is a mindset: To leverage managed services to deal with undifferentiated heavy lifting so …
Should “serverless” just mean “function-as-a-service”? Read More »
Back in 2018, I shared several ways to implement fan-out/fan-in with Lambda. A lot has changed since, so let’s explore the solution space in 2024.
Remember, what’s “best” depends on your context. I will do my best to outline the trade-offs you should consider.
Here is the biggest mistake many teams make when they try to adopt serverless and why they ultimately fail.
Don’t make the same mistake.
AppSync now supports invoking Lambda resolvers asynchronously. This simplifies a common challenge in GenAI applications where we had to hand off the call to the LLM to a background function so we can stream the LLM response back to the caller.
Step Functions lets you set a timeout on both Task states and the whole execution. By default, an execution can run for a year if TimeoutSeconds is not configured. To a user, the execution would appear as “stuck”. Which is why AWS best practices recommend using timeouts to avoid such scenarios. But once you have configured a timeout for the execution, it’s then important to consider what happens when you experience a timeout.
In this post, let’s explore 3 ways you can handle an execution timeout and use a Lambda function to perform automated remediation (e.g. applying rollbacks).
Testing is an integral part of software development, and serverless is no different.
Test Driven Development, or TDD, is long regarded as a leading practice in software development. And yet, one of the most misunderstood parts of Test-Driven Development (TDD) is the “Driven” part of the name. It’s not just about “writing tests before you write the code”. If your tests do not inform and drive your API design, then you’re not really doing TDD.
In this post, let’s look at how we can apply the TDD mindset to serverless and use our tests to drive the design of our serverless application.
There are many ways you can implement WebSockets with serverless technologies nowadays.
In this post, let’s explore four options – API Gateway, AppSync, IoT Core and Momento Topics. We will look at how they work, their pricing model and compare them.
I’m a big fan of Step Functions, but it’s yet another AWS service you must learn and pay for.
It also introduces additional complexities. My application is harder to test; my business logic is split between configuration (ASL) and code; and I have new decision points, such as whether to use Express Workflows or Standard Workflows.
So it’s fair to ask, “Why should we even bother with Step Functions?”. Why not just do everything in code, inside a Lambda function?
Let’s break down the pros and cons and look at the trade-offs of each.
“Lambdalith” is a monolithic approach to building serverless applications where a single Lambda function serves an entire API, instead of having one function per endpoint. It’s an increasingly popular approach and provides portability between Lambda and containers and lets you use familiar web frameworks.
Tools like the AWS Lambda Web Adapter have made this approach more accessible, and it also works well with Lambda Function URLs.
But don’t be too hasty to get rid of API Gateway just yet!
In this post, let’s look at the pros and cons of API Gateway vs. Lambda Function URLs, and let me explain why I still prefer API Gateway.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.