Guide to Debugging Serverless Applications

The Evolution of Serverless Architecture

It all started in 1953 when IBM launched its first commercial computer. And then, here we are today, discussing a Serverless Architecture. Through all these years, computing has not only revolutionized the way businesses operate, but has gone through tremendous transformations in itself.

Following several successful (and otherwise) use-cases of On-Prem and Cloud Computing frameworks, a Function as a Service (FaaS) framework was conceptualized, which ensured that applications run on stateless containers, enabling focus on executing code, instead of managing complex infrastructure and related resources. This led to the invention of a Serverless Architecture, which focused entirely on executing application binaries, while the required resources were managed and owned by a third-party. In its core, a Serverless Architecture allowed enterprises to not only focus better on core application development but to also bring down overhead expenses substantially.

While Serverless framework has allowed developers to build and deploy applications faster, it also brings a set of debugging challenges when compared to a traditional framework. In this article today, we take a look at the practices, challenges, and popular tools for Serverless debugging.

What is Serverless Debugging?

Since Serverless architecture is still in its formative stages, there are evolving approaches and tools that integrate seamlessly with a FaaS platform, while helping with constant data collection. As a serverless application runs on functions that make calls to multiple event sources and services, debugging essentially involves testing one or more of these components, with a focus on application security.

Debugging in serverless brings in a host of unique issues. These include - highly distributed components, the inherent lack of remote debugging tools, ephemeral design of containerized applications, and a lack of local setup frameworks. Besides, the use of numerous components supporting a single application also introduces multiple points of failure, which should also be addressed during debugging. More so, serverless applications are architecturally complex with a loose dependency between components, making debugging more critical and complex, at the same time.

Serverless vs Monolithic Debugging

While monolithic applications have been losing popularity to serverless applications, they reign supreme when it comes to ease of debugging. With monoliths, debugging happens locally, within their Integrated Development Environment (IDE), with the developer creating a breakpoint at the line of inspection. Since IDEs come with a debug mode, this is all that developers needed to do when identifying bugs in code. On the other hand in serverless architecture, the most popular method of debugging is logging. Developers monitor and chronicle all service actions through logs to gain an understanding of application behavior.

With monolithic applications, all issues can be tested and resolved in a local environment. The failure points typically occur in the User Interface, Back-End, or Database. Serverless applications, on the contrary, involve multiple distributed and connected components. This makes it hard to set up and resolve issues of serverless applications within a local environment.

Besides, monolithic applications support remote debugging. You can connect the IDE to remote servers, granting the developers privileged access. While this is possible, it is only applied in scenarios where a local simulation is unlikely to yield results. By nature, serverless applications do not support remote debugging due to a lack of OS and server-level access.

While the testing and resolution process may take some effort, it is usually simpler in a monolithic application, as every task and function runs within a single process. Serverless applications, on the contrary, require hopping across process boundaries with very loose dependency between components. This makes debugging an arduous task that involves collecting and analyzing massive amounts of data.

Types of Serverless Debugging Frameworks

Serverless applications are ephemeral and event-driven, this means that the serverless functions could call different services at different times depending on need. As a result, while some services can be simulated locally, debugging these applications mostly involve checking entire logs.

Serverless debugging frameworks are, therefore, divided into two distinct approaches using AWS Lambda:

1) Local serverless debugging
2) Serverless debugging for the cloud

Local Serverless Debugging

In Software development, a crucial part of debugging involves running it locally. The Serverless Application Model (SAM) is a solution that helps developers run their applications locally on Amazon’s Serverless framework using AWS Lambda. This solution comes with two distinct components: the SAM Template Specification and the SAM Command Line Interface. The template specification lets you define your application using permissions, events, APIs, and functions. While the Command Line Interface lets you invoke functions locally, debug on functions step-by-step, and package & deploy apps to the cloud. Here’s a complete guide on how to use AWS SAM for local debugging on AWS Lambda.

Serverless Debugging for the Cloud

Once you have deployed an application to the cloud, you need a way to uncover issues as your functions connect to services. Some of these connections usually cannot be simulated in a local environment for testing, so you’ll need a procedure for live testing. Here is the procedure for live-testing an application deployed to the AWS Cloud:

• Start by testing the API Gateway. Some of the most popular tools for testing API endpoints and gateways include: SoapUI, Postman and Curl.
• The second step would be testing Lambda functions directly in the AWS console without using an event source. This can help you easily diagnose issues in Lambda during an application’s first deployment. This step also requires the creation of test events that emulate AWS services.
• The next step involves tracking the application’s behaviour using AWS CloudWatch Logs. Lambda functions are configured to send their log data to CloudWatch by default. The solution then creates a LogGroup for each function, containing all events triggered by the function. Other application tracking solutions include Splunk and ELK.
• Finally, you can analyze and debug your application using AWS X-RAY. This solution provides end-to-end monitoring of events and creates a graphical visualization of all application components. This makes it the perfect debugging tool for applications both in development and production.

Popular Serverless Debugging Tools

While you can debug your application using native tools like CloudWatch and X-RAY, it is a manual and tedious process that requires multiple solutions. There are tools that are made for serverless debugging, simplifying the process by providing an integrated interface and a seamless experience cleaning up all functions and services. Some of these tools include:

Faasly.io

FaaSly provides an end-to-end single-pane-of-glass view of all your requests at the function as well as the invocation level. Besides, its Interactive Service Map acts as your command-center to quickly identify performance bottlenecks, and resolve them faster.

Built-in security- Achieve enterprise-grade security and compliance with deep integration to Envoy, while intercepting every network request that leaves the Lambda worker. If your functions are ever compromised, the real AWS credentials are always safe.

Codeless instrumentation- Instantly understand the health of your distributed systems in real time, without even touching the code.

AWS Cloudwatch

AWS CloudWatch offers you a powerful platform to monitor your infrastructure and applications. While doing so, it offers single-interface visibility, low-latency metric collection, log Insights, and resource utilization insights. CloudWatch also collects data while offering credible insights on system performance, resource optimization, and your application’s operational health. This data is visualized dynamically on dashboards so you can access information on your services, applications, and resources from a single screen.

SLS-Dev Tools

Serverless Development Tools is an open-source framework that provides a collection of tools for developers of serverless platforms and applications. This collection of tools follows a cloud-native approach, facilitating faster innovation and production. Since this collection is a pay-as-you-use model, you only need to pay for the time you use for running and testing your application. While the basic version covers almost all critical features of the tool, an advanced version, known as SLS-DevTools Guardian, helps in detecting issues as soon as they come up, helping in real-time debugging.

Lumigo

Lumigo provides an interface to instantly access application logs and troubleshoot serverless applications. The platform offers end-to-end logging and monitoring, allowing developers to dig deeper for intricate details on these functions, in an attempt to isolate the root cause of application problems. This tool has functions that let it identify your application’s critical path and points of failure, which helps improve your application’s efficiency through reduced latency.

Dashbird

If you run a Lambda based application, Dashbird should be one of your top debugging and optimization tools. This tool is configured to detect some of the popular Lambda failures, including Memory Issues, Timeouts, Runtime, Exceptions, and Configuration Errors. Dashbird also alerts you of failures through Slack or email, for full-time availability. As an addition to that, you can also integrate Dashbird with AWS X-RAY for insight on all events and function invocations.

SignalFX

SignalFX offers a cloud monitoring solution, capable of integrating with major providers, including Google Cloud Functions, Azure Functions, and AWS Lambda. This tool gives you real-time performance monitoring and constant visibility for all your serverless functions. With its list of features including, low-latency metrics, cost optimization, cold-start detection, and monitoring of execution time, SignalFX is steadily gaining popularity with developer communities.

Closing thoughts

While Serverless is a novel technology, it is already transforming the way we ship and deliver applications. Despite its growing popularity, serverless debugging is still evolving, due to the fact that most available tools are yet to be integrated with other services for end-to-end testing.

In this article, we explored various ways you can perform Serverless debugging either locally or cloud-based. This article also highlighted some of the most popular and simple tools to help debug serverless applications.

With a large scale adoption of Serverless, we are sure to expect several new approaches and tools for debugging in the coming years. Till then, follow the ones we highlighted above, and let us know if you have a use-case to share.

This article was originally published on https://blog.faasly.io/guide-to-debugging-serverless-applications and has been authorized by Faasly for a republish.