Debugging Castles In The Clouds

When developing software, debugging is essential. But users named debugging functions as the most common challenges associated with serverless architectures.

Recently, several solutions have been introduced that claim to make debugging serverless functions easier (or just plain possible). While the solutions take a variety of different approaches, deciding whether you want to debug locally or in production is the first step when selecting a solution that is right for you. To help you make a more educated choice, let’s take a look at just what local and production debugging each entail in the world of serverless.

Local debugging

In order to debug serverless functions locally, the entire cloud provider environment must be emulated so that the application flow can be accurately reproduced. To accomplish this, the various local debugging solutions emulate serverless environments for specific cloud providers, frameworks, and languages.

These solutions have definite plusses: They are easy to set up and of course, do not interfere with production. Breakpoints enable developers to fully control the application flow, and they can extract functions on demand, via custom events.

On the other hand, local solutions cannot possibly really represent the full production environment. Inevitably, events, databases, and other elements will be missing from the simulation. Support for languages, frameworks and cloud providers is still limited, and with each tool only supporting a very narrow technology stack, tool inflation will be the inevitable result.

Most importantly, due to these and other limitations, it is almost impossible to trace production issues locally. So while some issues may be discovered and resolved, others may be stubbornly resistant to local debugging.

Production debugging

The production-first, event-driven and data-driven nature of serverless environments makes production debugging a natural fit since it enables more accurate reproduction (or essentially, production) of issues than local emulators can accomplish. Minor differences in event content, format, or order can make big differences, so reproducing events faithfully results in more efficient and successful testing and debugging.

Similarly, having the right data inputs is essential for reproducing bugs, but migrating data from production to development can be time-consuming and resource-intensive, and complicated by security and compliance considerations.

As a result, production debugging enables rapid debugging, based on “in-the-wild” conditions, without adding overhead to production. The solutions are more likely to work with a wide range of languages, frameworks, and cloud providers than local solutions, enabling a smaller technology stack. Perhaps most significantly, production debugging allows requests to be traced across multiple microservices and serverless functions for more accurate debugging.

Production debugging solutions have a number of disadvantages as well. As edge technologies, their learning curve can be steep. New code must be deployed for setup. And while some solutions provide fully descriptive dump frames, similar to those provided by local debuggers, they cannot be used to set breakpoints.

Choosing the serverless debugging solution that is right for you

There’s lots more to know before deciding what kind of serverless debugging solution will best meet your needs. To get the full scoop on which type of solution is right for you, download our comprehensive Serverless Debugging Guide.