Improve average latency by ~3-5x, lower memory usage by ~50%, reduce total cost by ~3-5x; all while making Lambda functions work reliably with databases¹

‍

It seems crazy to think that it was 9 years ago next week that Amazon launched AWS Lambda, ushering in a new wave of “serverless” application development. Today it is estimated that nearly 75% of organizations running on AWS use its serverless offerings².

The promise of serverless computing is well understood - fast deployment, on-demand scalability, pay exactly for what you use – all without the overhead of managing server operations. However, services like AWS Lambda are not without their challenges, especially when it comes to working with databases. 

In this post I want to discuss these challenges in more depth before showing you how, through some simple code snippets running against Neurelo’s cloud API’s, applications can finally take advantage of AWS Lambda even when working with databases.

While serverless offers the many benefits cited above, it presents unique challenges when working with databases.

‍

The Cold Start Challenge

One of the most frequently discussed issues with serverless functions like AWS Lambda is the "cold start" problem. This refers to the additional latency introduced when executing a serverless function after it has been idle. For databases, this can be particularly problematic. If a database connection is established within a serverless function, the cold start time can add significant latency to the initial database query. This problem amplifies when using multiple instances of the lambda function concurrently, as each instance will have the “cold start” issue.

‍

Connection Handling Issues

Lambda functions, being stateless and ephemeral, present challenges in maintaining persistent database connections. Developers typically implement connection pooling libraries within Lambda code, a complex approach that requires careful consideration of factors like cold starts, concurrency limits, and database connection constraints to optimize effectiveness. While connection pooling is a common strategy, its effectiveness can be hindered by Lambda's short-lived instances and potential resource limitations. Developers often have to resort to costly options like AWS RDS Proxy, which lacks support for non-AWS databases like MongoDB, or self-hosted databases. The choice between these strategies involves weighing the trade-offs associated with cost, compatibility, and complexity in the serverless environment.

‍

Application Design, Cost and Performance Considerations

Serverless environments inherently differ from traditional server-based architectures. Consequently, designing, managing and debugging applications can become more complex.

• Statelessness: Each serverless function is designed to be stateless, meaning it doesn't retain any local state between executions. This can make handling database transactions or maintaining database connection states tricky.
• Granularity: Serverless encourages fine-grained functions executed concurrently or sequentially or both, which can lead to higher numbers of database connections, possibly resulting in throttling or connection limit issues.
• Cost vs Performance: Cost benefits of serverless functions diminish when considering the trade-off with memory and latency requirements. Reducing the memory footprint increases latency but also leads to higher costs due to the increased billable runtimes and on the other hand, higher memory allocation improves latency but also results in increased lambda costs as the pricing for lambda increases based on the memory allocated for a function³.

‍

Vendor Lock-in and Other Concerns

While adopting serverless, developers might find themselves more tightly bound to specific cloud providers. This can lead to:

• Vendor- and database- specific configurations: The way one sets up a serverless function or integrates a database in AWS might differ significantly from Google Cloud or Azure, and the database being used.
• Migration Challenges: Moving from one provider's serverless platform to another's could mean significant rewrites and re-architecting.
• Lastly, developers should also consider security implications. While providers manage many security aspects, the serverless model can introduce new vectors of attack, especially when poorly configured database connections are involved.

‍

Neurelo’s Data Access Platform solves these above challenges and makes it possible for developers to build fast serverless applications at a significantly lower cost to run them at scale.

‍

Neurelo as a Database Proxy beyond AWS RDS

Neurelo offers Cloud APIs, with optimized pooled-and-shared connection handling, ensuring swift and reliable database interactions. Neurelo's support for multiple databases, dynamic scaling, and secure access control, contribute to its effectiveness in any cloud environment you choose to run your apps in. It adapts seamlessly to varying workloads, preventing issues like cold starts or connection limit challenges.

On AWS, lambdas can be configured to use AWS’s RDS Proxy to alleviate some of these challenges; however, this works only when using Amazon RDS, and is quite expensive to run. Neurelo’s platform provides versatile and flexible solutions to cater to a broader range of databases beyond AWS RDS, allowing for a more diverse set of use cases in a much more cost-effective and easy to use way. 

Neurelo delivers much improved database interaction latency for serverless executions with databases like PostgreSQL, MySQL and MongoDB, particularly in scenarios with concurrent execution challenges, reducing the load on the database, and virtually eliminating database-related timeout issues for serverless applications. Additionally, by handling data access operations outside of AWS Lambda, Neurelo significantly improves the memory footprint for Lambda functions, leading to substantial cost savings and improved latency.

‍

Example AWS Lambda function written using Neurelo APIs
(No DB connections needed, just use HTTPs calls – simpler, faster, cheaper)

	
const https = require('https')


// Configure the Access Token for our Neurelo environment
const NEURELO_API_KEY = '<TOKEN>'
// Configure the URL to access APIs in our Neurelo environment
const NEURELO_ENV_URL = '<URL>';


exports.handler = (event, context, callback) => {
 // Request that AWS Lambda freeze the process soon after the callback is invoked
 context.callbackWaitsForEmptyEventLoop = false;


 // Make a Neurelo MongoDB API call to return the first 20 neighborhoods
 const NEURELO_API_PATH = '/rest/neighborhoods?take=20'
 
 // Configuration for the Neurelo REST API endpoint we would like to call
 const options = {
   method: 'GET',
   hostname: NEURELO_ENV_URL,
   headers: { 'x-api-key': NEURELO_API_KEY },
   path: encodeURI(NEURELO_API_PATH),
 }


 // Make the HTTPS request to the Neurelo REST endpoint
 const req = https.request(options, (res) => {
     // Use the returned data for our business logic
     let resp_data = '';
     res.on('data', (chunk) => resp_data += chunk);
     res.on('end', () => {
          resp_data = JSON.parse(resp_data);
          callback(null, resp_data);
     });
 });


 req.end();
};
	

In summary, for developers facing challenges with serverless application reliability, latency, memory usage, and cost, Neurelo’s Cloud APIs presents a compelling solution. Prioritizing speed and efficiency in database interactions, Neurelo offers significant cost savings in AWS Lambda usage. The combination of AWS Lambda with Neurelo's Cloud API signifies a strategic shift toward building modern, scalable, and responsive applications. 

Try Neurelo with your serverless application

‍

¹ Based on early lab testing; additional details coming up in a follow-up blog

² https://www.datadoghq.com/state-of-serverless/

³ https://aws.amazon.com/lambda/pricing/