Subscribe to our
weekly update
Sign up to receive our latest news via a mobile-friendly weekly email
Does AWS Lambda have scalability issues? Read on & explore its strengths and potential bottlenecks, how applicable serverless architecture is to different scenarios, and how to monitor it effectively.
In our previous blog, we shared our firsthand experience of implementing a tracing collector API using serverless components. Drawing parallels with Amazon Prime Video’s architectural redesign, we discussed the challenges we encountered, such as cold-start delays and increased costs, which prompted us to transition to a non-serverless architecture for more efficient solutions.
In this final part of our blog series on microservices and serverless architectures, we probe deeper into one of the central questions that arose from our experience: Does AWS Lambda have scalability issues? We’ll dive deep into the intricacies of AWS Lambda’s scalability, examining its strengths and potential bottlenecks. We will also consider the applicability of serverless architectures for different scenarios and highlight the importance of monitoring in any architectural setup and how you can achieve this in a serverless world. Let’s dive in.
AWS Lambda applies two types of concurrency limits: a general account-level limit and a function-level limit.
Additionally, AWS introduced a feature known as “Provisioned Concurrency”. This allows you to keep functions initialized and hyper-ready to respond quickly without hitting cold-start (Lambda container initialization and Lambda function user code initialization) delays which is helpful for applications with predictable traffic patterns since it reduces any cold-start latency.
All of this means that if you need to handle a lot of concurrent executions (more than 10K), AWS Lambda might not fit your case. In that case, you may need to consider going with containers – but first, decide whether you genuinely need concurrency which is this high. The main two approaches to reduce concurrency requirements for a single serverless application are:
In addition to concurrency limits, AWS Lambda uses two types of concurrency controls for your function: “reserved concurrency” and “unreserved concurrency”. The unreserved concurrency pool, which has an account-level limit, is shared among functions that don’t have a specified level of reserved concurrency. Additionally, AWS controls burst concurrency depending on regional capacity. Even with these limits, Lambda functions scale much better than other types of computes on AWS.
Check out this blog post to understand how AWS Lambda scaling speed compares to the other AWS services.
While AWS Lambda is a powerful tool for many applications, there are certain situations where it might not be the most suitable choice:
Remember to evaluate your specific use case and requirements before deciding whether AWS Lambda or another service is the best fit, because there are no silver bullets. As economist Thomas Sowell (A Conflict of Visions: Ideological Origins of Political Struggles) said, “There are no solutions. There are only trade-offs.”
Whenever designing any application, ask yourself these questions from the start: “When something goes wrong, how will I know that something is wrong, how will I know what is wrong, how will I know what to do to fix it, and how can I verify that the fix worked?” Remember that potential issues can be part of your application (“bugs”), caused by an interaction between your application and another application or service (overloaded upstream queue? Unhandled exception from a service provider?), or it can be caused by a service you may not know you rely on (an ISP failure between your application and your users?)
At Catchpoint, we always start monitoring by measuring what the customer experiences. This part doesn’t change between serverless or traditional architectures – a web browser connecting to an application still makes a DNS lookup, a request to the application URL, individual requests for each component, etc. With monolithic applications, a single-parent service may handle all of the requests, so this service can keep track of them all. What’s different with serverless is that the individual requests may each be processed by an entirely different function. The monitoring mechanism needs to ensure that a request handled by one function can be correlated to a request handled by another function.
One nice thing about monitoring serverless applications is that the architecture is already broken down into small components – so tracing the performance of a request through each component is simply a matter of finding a start and stop time of the function. This is the same promise that was made by microservices: they break the overall architecture into pieces so that it’s easier to understand what each piece does. Just like with the overall system architecture – whether you use functions, microservices, containers, or traditional computes, monitoring should be something analyzed from the beginning and planned into the design.
Earlier this year, we announced the acquisition of the assets of Thundra.io, a pioneer in cloud monitoring, a move that strengthens Catchpoint’s Application Experience Solution with advanced microservices and API monitoring capabilities, both critical aspects of Internet Performance Monitoring (IPM). Catchpoint engineering teams are currently in the process of seamlessly incorporating Thundra’s core features into our already industry-leading IPM platform. Soon, Catchpoint users will be able to observe the entire customer experience from the user to the API call, and to the server trace.
We’ve conducted a comprehensive exploration of the benefits, trade-offs, and real-world applications of microservices and serverless architectures throughout this blog series. From understanding the rationale behind Amazon Prime Video's strategic architectural redesign to navigating our own journey with the tracing collector API, we unraveled the complexities and lessons learned from integrating serverless components into applications.
As we conclude this series, we acknowledge that the world of microservices and serverless architectures is ever evolving, and there are no silver bullets. Each architectural choice comes with its unique set of trade-offs and challenges. By adopting a thoughtful and informed approach, understanding the specific requirements of our applications, and leveraging the power of monitoring and optimization, you can build robust, scalable, and reliable systems that drive superior performance and deliver exceptional user experiences.
Happy building!