You’re likely familiar with local debugging—the ability to go through your code line by line to find and eliminate bugs. However, with the ever-increasing complexity of development environments, working efficiently with remote systems is becoming more necessary. In this case, “remote” can mean any machine you don’t have native OS-level access to, such as Virtual Machines, Docker containers, and entirely separate devices accessed over the network.

No matter what you’re using Kubernetes for, visibility into your applications’ performance and activity is a beneficial and often essential undertaking – essential, but colossal, requiring entire teams dedicated to nothing but maintaining deployments, auditing, debugging, and keeping up with compliance. Kubernetes has robust support documentation dedicated exclusively to assisting customers with Monitoring, Logging, and Debugging.

In this article you’ll find out how to 10x your development speed with local serverless debugging. Questions such as “what happens when you scale your application into millions of requests?”, “what to expect when going serverless?”, “how does it look like?”, or “how is it to build applications on serverless and work locally?” will be addressed.

The pursuit of Digital Transformation and DevOps practices has led to several benefits such as increased deployment rates and better collaboration across teams. However, it has also led to endless abstraction, an increase in responsibilities, and many new tools (Kubernetes, hybrid-clouds and all their services, etc.). This increase in complexity has turned observability into an essential component of all ecosystems.

Here are the articles, videos, and tools that we’ve been excited about this June. We hope you enjoy these links, and we look forward to hearing what you’ve been reading in the comments or on the Interrupt Slack.

What makes JavaScript great is also what makes it frustrating to debug. Its asynchronous nature makes it easy to manipulate the DOM in response to user events, but it also makes it difficult to locate problems. And JavaScript’s ubiquity has resulted in a variety of runtimes (e.g. Chromium’s V8, Safari’s JavaScriptCore, and Firefox’s SpiderMonkey) but having so many platforms can cause dizzying idiosyncracies — all of which need to be supported equally.