This is the second post in a 2 part blog series on debugging, monitoring and tracing NodeJS Lambda applications. If you haven’t yet seen part 1, check it out here (it’s a great read!) Now let’s get back into our post with one of the most commonly experienced issues when it comes to Lambda functions, Cold Starts.

In this two post series, we are going to explore some ways to trace and debug NodeJS Lambda applications. Delving into some methods to look further into resources utilized to and some methods to optimize code. AWS Lambda, an event-driven compute service first introduced roughly eight years ago, changed how we build out cloud applications as an industry.

AWS provides multiple ways to deploy containerized applications. From small, ready-made WordPress instances on Lightsail, to managed Kubernetes clusters running hundreds of instances across multiple availability zones. When deciding on the architecture of your application, you should consider building it serverless. Being free from (virtual) server management enables you to focus more on your unique business logic while reducing your operational costs and increasing your speed to market.

The most important thing with building out any application is to think BIG. Build for ten users now and 10,000 users tomorrow. Having infrastructure that scales as your needs do is critical for user adoption—one of the many reasons we love a serverless approach and particularly AWS Lambda. The other part of any growth journey is managing access to organizational cloud infrastructure, especially with rapidly growing organizational development and DevOps teams.