Serverless

The pros and cons of Lambdalith

“Lambdalith” refers to deploying monolithic applications using AWS Lambda. This is typically associated with (but not limited to) building serverless APIs.

With a Lambdalith, a single Lambda function handles all the routes in an API. You can use Lambda Function URLs [1] or put the function behind a greedy path in API Gateway.

This contrasts with the “function per endpoint” approach, where a different Lambda function handles each API route.

Lambdaliths has been the source of intense debate in the serverless community. While I generally prefer the “function per endpoint” approach, I have adopted Lambdaliths where it makes sense.

In this post, let’s discuss the pros and cons of Lambdaliths and the nuances that are often overlooked.

How to implement Durable Execution for Lambda (without frameworks)

“Durable Execution” means a system can execute workflows reliably and remember progress even when failures occur. It typically involves persisting progress to avoid repeating side-effects on retries and allowing you to recover gracefully from failures.

It’s commonly associated with workflow orchestrators such as AWS Step Functions and AWS Lambda doesn’t support durability by itself.

But, as you will see in this post, there’s an easy way to add durable execution to Lambda, without needing to adopt a durable execution framework or rewriting your Lambda function as a Step Functions state machine.

And it only takes a few lines of code!

Event-Driven Architectures: How to limit the scope of end-to-end tests

A common challenge in event-driven architectures is the potential for unintentionally triggering downstream consumers when running end-to-end tests.

Ephemeral environments can help, but not when you must publish events to a shared event bus.

In such cases, you can conditionally create a local copy of the event bus as part of the ephemeral environment so your test events will not trigger downstream event consumers.

How we built an AI code reviewer with serverless and Bedrock

Building Evolua, an AI-powered code reviewer, taught us a lot about balancing cost, performance, and developer experience.

While selecting the right LLM and crafting prompts is important, the real challenge lies in handling large PRs, mitigating model limitations, and ensuring a smooth user experience.

In this post, we break down our architecture, why we chose Bedrock, and key lessons learned – like why the LLM is actually the easy part. If you’re using AI to write code, Evolua can help catch bad code before it reaches production.

How to invalidate Cognito-issued JWT tokens

The ability to invalidate a user’s session with immediate effect is a common enterprise requirement.

However, this goes against how token-based authentication is designed to work. JWT tokens are stateless and are typically short-lived (for security reasons) but can be refreshed with refresh tokens.

So, is it possible to invalidate Cognito-issued JWT tokens?

The short answer is no.

The long answer is yes, you can achieve this effect with some work and some performance overhead.

How? Well, come in and find out!

Biggest pre:Invent 2024 serverless announcements

DynamoDB cuts on-demand price by 50% Announcement DynamoDB has reduced on-demand pricing by 50% and global tables by up to 67%. Amazing! Lambda SnapStart is now available for Python and .Net Announcement Previously, SnapStart was only available for Java. It makes sense to add support for .Net. But why Python and not Node.js? I guess …

Biggest pre:Invent 2024 serverless announcements Read More »

Here is one of the most misunderstood aspects of AWS Lambda

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.

Should “serverless” just mean “function-as-a-service”?

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 »

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.

Close