We recently participated in the Global Summit for Node.js ’23 hosted by Geekle. During our talk, titled “Who needs a debugger when you’ve got observability,” we discussed the limitations of debuggers in modern software systems and the benefits of incorporating observability solutions when coding.
I wanted to share the gist of our talk with the community, as it could provide insights into adding observability to Node.js services. We explained why software developers should be aware of observability instead of opening a debugger and how it can benefit their everyday lives.
I’ll demonstrate how to implement an observability stack based on Jaeger and OpenTelemetry and how to debug simple issues in a microservice distributed environment.
“I don’t like debuggers. Never have, probably never will.” – Linus Torvalds.
Linus doesn’t like debuggers, and he’s not alone in this sentiment. Uncle Bob and Edsger Wybe Dijkstra have also spoken out against the over-reliance on debuggers. As Brian Kernighan said, “Debugging is twice as hard as writing the code in the first place. Well, I don’t like them either!
The main with debuggers is that they don’t scale! They only provide a narrow view of a specific aspect of the application, such as a thread, process, container, machine, instance, or environment. They don’t give the complete picture of the entire application, including the story of how data travels through your system or how your code manipulates it. It’s like using a microscope to study the world, which is very focused but only shows details of something small. Additionally, debuggers often provide more information than necessary. If you don’t know what you’re looking for, you’ll waste time scanning and trying to find problems.
Also, don’t forget that debuggers were born in the monolith era when we worked on small modular projects. However, as the complexity of software systems has increased with the rise of distributed systems, debuggers have become less efficient.
Most developers lack knowledge of existing observability tools, despite being open-source and accessible. This lack of familiarity and usage remains even when companies pay to integrate observability into their applications.
It turns out that only about 35 to 40% of the developers in the world even know or use debuggers and most of them still rely on the same old techniques using console logs and print statements as we did in the 90s.
While logs and metrics are crucial in software development, this blog will primarily discuss “trace” specifically. I firmly believe that every distributed or microservice-based application should integrate distributed tracing. This tool is amazing and will significantly enhance your experience.
Rather than writing out all the details, I think it’s best to share with you the video of my talk from the senior developer paid track at the Node.js summit. The demonstration in the video will cover how to instrument your code using OpenTelemetry, followed by a demonstration of using traces to detect issues in your code with the help of Jaeger.
For the demonstration, I use an e-commerce website built on Node.js with multiple microservices.
My name is Erez; I’m the co-founder and CTO of Sprkl Personal Observability. We help developers by instrumenting their code changes using OpenTelemetry and Jaeger, providing them with full context into their code changes directly within their IDE.
I’m a seasoned developer with 25 years of experience writing code at various levels of the software stack, including assembler at Intel, Linux kernel, embedded real-time systems, networking, storage, and cloud computing. I’m particularly fond of using Node.js in my day-to-day work. (Rambled on here, so I can gain credibility before giving you advice.)
BTW: Sprkl is completely free. You can head over to the VSCode marketplace to download it or visit our website at sprkl.dev to get started.
Share
Enjoy your reading 4 Min Read
We promise you’ll only get notified
when new content is out
Font 1
Font 1
Font 1
Font 1
Font 1
Font 1
Font - code
Font - code