 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
As the world was passing through tumultuous times in the 1940s, developers were taking their first steps. This is the story of the developer species, often recluse and hard to understand. We aim to explore how developers evolved over time and how they made debugging their most powerful weapons for survival through the ages.
The story of our intrepid developer begins in the early days when computers were still sprouting in the world, taking the form of large mechanical machines incomprehensible by the common man. Depending on the definition of computers, this story can stretch far back as to the early ages of humanity. (However, for the purpose of this article, we will consider ENIAC, created at the University of Pennsylvania and introduced in 1946, as the first digital computer according to the scope of our definition.)
As can be expected, debugging ENIAC back then was a completely different experience compared with what we consider debugging now. A lot of evolution had to occur to take us from mechanical beasts similar to the ENIAC computer to the elegant lines of code we are all accustomed to now. So naturally, debugging throughout this evolutionary process also changed, especially when developers realized that the debugging tool was akin to fire — offering essential protection in a scary environment.
Hence, for the sake of convenience, we’ll jump through much of this part of history and get to the next impactful moment in debugging history: logs and breakpoints.
Logs allowed developers to print statements at the points of interest in their code execution, as defined. This provided the ability to follow code execution, though crudely, in complex systems. It allowed users to track preconfigured warnings, errors and simply track the flow of execution. Finally, developers had their first insights into the state of their software systems. By surfacing these logs in local files or in remote logging servers, the developer had reached a crucial point in advancing his debugging practices to ease the task of building software systems.
The perennial benefits of logging have rightfully secured the longevity of the concept in the fast-paced domain of software. The ability to provide insights without disrupting the execution of the code is a major benefit. Moreover, logs have also transformed themselves into what is now known as tracing to work better with distributed systems and cloud native microservices. Through tracing, developers can leverage log-base insights to debug the complex distributed systems and software captured in the frenzy of the cloud movement. Logs have definitely proved themselves to be the developer’s friend in this new era of software.
However, there are also disadvantages that become unbearable, especially at scale. First of all, log statements can lead to an immense amount of noise, rendering them difficult to use. These log statements must be printed and hence can clutter the file to which they are being printed. As a result, debugging can become extremely difficult even for those who configured the logs.
Another pitfall is the cost of logging. Because these logs have to be printed somewhere, the cost of storing logs can easily outweigh the benefits of logging. This is especially true if we are not careful about what we are printing. Davide de Paolis, technical lead at Goodgame Studios, recently analyzed the cost of AWS Cloudwatch logs in a bid to highlight best practices for avoiding runaway costs. He identified that if developers were to print every piece of log statement they find useful, they may incur excruciating AWS bills.
Therefore, logging is critical, but developers are limited by the resources they have available and must perform a balancing act.
As the evolution of software development skipped along, we saw the birth of debugging tools. With these debuggers came the famous breakpoints, allowing developers to take snapshot views of their system. Developers could now execute their codebase to a specific point and pause the execution. This paused state allowed developers to investigate the state of their systems in a manner well presented by the IDE (integrated development environment) with its integrated debugger tool.
Debugging tools were revolutionary for software development, especially when integrating with the IDE. Now, almost no modern software is developed without the use of debugging tools. However, we have reached a point in our timeline where even this remarkable achievement is becoming outdated for our present-day developer.
This is because software systems are now leveraging the advancements in cloud computing and distributed systems. As a result, we see gaps in debugging methods that breakpoints in debugging tools simply cannot fill. One issue is that while using breakpoints, the codebase needs to be run in debug mode. Therefore, we are not actually replicating the actual state of our systems, taking into consideration multithreading, distributed services and dependencies on remote services in a cloud native environment along with multiservice architecture.
Therefore, considering the new era of technology and software, we see a movement to redefine debugging practices to better suit the new world.
As the developer now embarks on her journey into the new world, it is evident that traditional logging and breakpoint will be insufficient to protect her from the perils that lie ahead. Hence, we are already seeing the formation of new concepts such as non-breaking breakpoints, which aim to combine the best of logging and breakpoints.
Non-breaking breakpoints, encapsulated in the new age of debuggers, are allowing developers to debug their code without having to endure any interruptions in their systems. That means these tools allow developers to perform debugging in live environments. Additionally, with the combination of trace logs, these debuggers also overcome the difficulties that arose from the rise of cloud computing and distributed systems.
These new tools are a stark contrast from what was available in the early days. Step-by-step debugging in a remote environment was simply a dream back then. The birth of technologies such as Lambda functions and Kubernetes was scary for those who thought about debugging. However, the developer no longer has to fear these technologies as a new era of debugging is being ushered in to tackle the issues of the new world: remote debugging.
Remote debugging, leveraging non-breaking breakpoints allow developers to set non-intrusive breakpoints at any line of their code base running in any environment. This will allow the remote debugger to capture all crucial insights such as messages and snapshots containing variable states at the point of the non-breaking breakpoint. Better yet, the developer will procure all these insights without having to disrupt the flow of his systems.
The developer’s journey into the new world has just begun, and concepts such as remote debugging and non-breaking breakpoints are still evolving to meet the exact demands of the new age. Luckily, these developers are not alone on their journey as companies such as Thundra are providing remote debugging solutions to help developers in their progress. Thundra’s solution is even more aptly named Thundra Sidekick, providing the much-needed sidekick that the developer needs in this journey.
As software practices and the way we release our systems to the world evolve, supporting practices are also evolving. Developers have already witnessed a breakthrough in debugging tools throughout this perpetual evolution, where each stage is accompanied by a new form of debugging tool or concept. With cloud computing and distributed systems on the rise, we also see a rise in remote debugging, and third-party tool vendors are taking notice. As we go through this new era, we can only imagine what the next era of tooling will look like. All we know is that the developer’s never-ending journey is dotted with many achievements along the way.
