I have a love-hate relationship with Lambda. The service offered by AWS sparked my interest in 2014 however lack of tooling discouraged my complete adoption of the service. These days however it’s hard to find many workplaces not talking about Serverless technology and Lambda.
Photo by Brett Jordan on Unsplash
I love lambda for the following reasons:
Automatic Scaling
Minimized Costs
Ecosystem of Triggers
Rapid prototyping
The reason I hate Lambda is assumptions on:
Infinite scaling
Ease of management
First, what is Serverless? Serverless architecture is a cloud model where providers allocate resources on-demand to fulfill requests. What services are considered serverless appears to get blurrier as time goes on. My perception of what is serverless comes down to minimal fixed costs with costs scaling based on usage with minimal management of infrastructure.
But now what is Lambda? Lambda is an offering from AWS that allows for code execution without worrying about provisioning or managing servers. Lambdas have triggers to determine when the code should be executed, in most scenarios this is caused by API Gateway receiving an HTTP request. Once you dive out of just Request/Response patterns Lambda will assist in building event-driven processes.
Uh-oh, what’s event-driven? To avoid turning this article into a thousand questions, event-driven processes that utilize Lambda can be imagined as a flow diagram. Other services in AWS can trigger Lambda execution, a very common example that is shown in tutorials is whenever a file is uploaded to an S3 Bucket ( Cloud File Storage ) you can trigger a Lambda to resize the image.
A good resource if you are interested in learning how Lambda fits into the event-driven paradigm. https://docs.aws.amazon.com/lambda/latest/operatorguide/lambda-event-driven-paradigm.html
Okay, awesome we got some of the terminologies out of the way for those not familiar with Lambda. Now let’s get into the hate side of the relationship. There is a very common misconception from the buzzword Lambda and Scale that they shouldn’t expect to see any restrictions in concurrency.
Lambda does a wonderful job at offering low-cost compute when you burst concurrent requests between 0–1000. Once you reach that 1000 concurrent requests you are going to be throttled and the system needs to handle that.
I get it, your first thought is what’s the likelihood of a user requesting something from my API 1000 times at the same time. Your right it’s unlikely for small-scale products unless being targeted unethically.
This is where lambda chaining can come in and be a tad bit of a pain. Let’s say whenever a user makes a POST request to an entity we cause additional Lambdas to trigger to fetch another entity. That may take down our number of concurrent requests from 1000 to 500 assuming two lambdas are required to process a request.
Concurrency is determined at a particular point in time, there isn’t a strict per second rule but an understanding of maximum concurrency. If our third party API that we are syncing data to unfortunately takes a few seconds to return we are now further limited.
System complexity can get out of hand quickly, be conscious that relying on the convenience of Lambda for compute can land you in a situation where you are struggling to maintain below a concurrency limit.
Ease of management, now Amazon does provide a lot of amazing tools for observability and monitoring of Lambda and Serverless applications they do require a steep learning curve and aren’t baked into the service.
It’s far too common to see engineering teams utilize Lambda in an always sunny mindset. Lambda by itself doesn’t safeguard your team from making critical architecture mistakes and anti-patterns that could result in the degradation or failure of a system. Be prepared to understand what it means to measure, analyze and understand the performance of your Lambda system and not assume AWS is holding your hand.
A must-have in my opinion is Lambda Insights, it’s a set of additional metrics and aggregates available in Cloudwatch to assist in monitoring AWS Serverless applications built on Lambda. There is an additional cost to running with Enhanced Monitoring but has to be weighed up against the impact of extended downtime. Read more about Lambda Insights here https://docs.aws.amazon.com/lambda/latest/dg/monitoring-insights.html#monitoring-insights-enabling-console
I’d recommend investigating the case studies of AWS X-Ray to determine if it’s valuable for your system. https://aws.amazon.com/xray/
Please don’t take this as a don’t use Lambda story. Lambda is a powerful offering that can enable engineers to build cloud solutions. I’m always down to chat Serverless and Lambda so feel free to reach out.
I’m hoping to get a few articles together in the coming month demonstrating my thought process when developing RESTful APIs using Lambdas and some of the gotchas to look out for.
Top comments (0)