Today, we're talking with Jonathan Lindo, CEO and co-founder of Replay Solutions, a company that provides tools for capturing and recording applications for debugging purposes.
DDJ: Jonathan, from what I can tell, ReplayDIRECTOR which your company produces is akin to "TiVo for developers" but with a debugger thrown into the mix. Is that a fair assessment?
JL: Well, you're definitely on the right track. ReplayDIRECTOR is a technology that does record-and-replay applications the same way you would use a DVR. In fact, our customers often refer to us as a "TiVo for software" because our technology records and replays software, but also, because it's just that easy to use. When DVR technology was introduced, it changed how people watched television. In the same way, ReplayDIRECTOR is completely changing the way developers resolve issues in their software. Now, you can record any issue, then skip over the stuff you don't want to see during replay, and get straight to the root-cause of any software issue.
Having been a developer since the early '90s, I've felt the pains of non-reproducible issues, the "works-on-my-machine" bugs, and the "heisenbugs" that disappear every time you attach a debugger. When my co-founder Jeff Daudel and I got together to create ReplayDIRECTOR, it originated from the problems we were facing while working together at another company building massively networked and multi-tier applications. We were drowning in a sea of issues that just couldn't be reproduced fast enough. We needed to replay them!
So what is it we do exactly? ReplayDIRECTOR has two important and unique abilities. First, it will record any application or server execution, allowing that application or server to be replayed at any time. During replay, the application is actually running, and executing the same lines of code that were run during the recording. Secondly, ReplayDIRECTOR captures the environment in which the application ran. This means if you had a database, other servers, and hundreds of clients connected during the recording, none of those are required during replay. The recording has captured them all and will simulate the entire environment with our application virtualization technology. This means you don't need to run your database, you don't need the database dataset, and you don't need to reproduce the original load on your application. Your application will believe it's running in the exact same environment, with the same inputs as it did when it was recorded.
The best part is you can use any tools you like during replay, because your application is actually running. Most coders I know have particular debuggers or diagnostic tools they like, so ReplayDIRECTOR allows you to use any standard debugger or tool, such as Eclipse, gdb or Visual Studio to fix the problem. Your application is running live, so you can do whatever you like to it.
DDJ: Can you tell us how it works?
JL: Absolutely. ReplayDIRECTOR is an "always on" recording technology. We built it from the ground up to be high-performance so that it never slows down or interferes with even the heaviest, most complex development, staging or production environments.
Once deployed, ReplayDIRECTOR records every non-deterministic input that can affect your application. This includes things such as network IO, disk IO, asynchronous IO and user input. During replay, these same inputs are then fed back to the application again. By doing this, we can make certain that every line of code executed during recording will also be executed in the same way during replay. This is what puts ReplayDIRECTOR in a different category of quality management solutions. It provides the ability to actually re-execute application without the original environment, and it does this without requiring any source code changes.
As most developers know, the first step in resolving an issue is always to reproduce it, and this is often the most difficult. Because ReplayDIRECTOR has captured the entire environment, youre not spending any time setting up databases, bringing up servers, and generating network traffic. Now you, as the developer or QA engineer, don't have to deal with any of that pain-staking process, because we've captured everything you need with absolutely no effort on your end.
We've essentially changed the protocol for fixing bugs. Let's say you're in QA and you know that a bug occurred in yesterday's build. You go in, select yesterday's recording, and press play. ReplayDIRECTOR goes to work re-executing your application and brings you quickly to the exact point of failure. Your favorite debugger will show you the line of code that caused the problem.
ReplayDIRECTOR eliminates the need to ever recreate the environment a bug occurred in because we're giving you an exact reproduction of the actual bug, along with its environment. The benefits are the time you save, and the fact that you know the problem has been captured in a glass jar, ready to be fixed. Replaying applications from our recordings and fast-forwarding to bugs literally takes minutes.
Anyone who's ever spent more than 5 minutes trying to reproduce a bug can quickly appreciate how valuable Replay technology is, and ReplayDIRECTOR isn't just for developers. Our customers are also running in production, QA and customer support. ReplayDIRECTOR works across the application lifecycle, and the greatest benefits are realized when its used throughout the lifecycle. This can be especially true when youre working with teams located in different parts of the world.
DDJ: If I have the chronology correct, you first launched ReplayDIRECTOR in the game development space. Why there?
JL: That's correct. We started working with some of the biggest software developers in the gaming industry such as Electronic Arts and Microsoft early on. These environments are some of the most complex, high-performance, real-time environments you can imagine. Especially with today's multi-core hardware that is now prevalent.
A nice feature of the gaming industry is their natural embrace of bleeding-edge technology. ReplayDIRECTOR is not an improvement on something that already exists, but a radically new approach to an age-old problem. The gaming industry immediately recognized the value that we deliver, and within a very short period we had teams all over the world saving time by recording and replaying as part of their daily workflows.
The gaming industry also has very advanced needs because the zero tolerance for slipping software ship dates. Bugs need to get killed fast. Also, when your application is a game that needs to be executing in real time, you can't use a solution that's going to slow it down, so we knew that tackling gaming would ensure our technology could handle heavy loads. We also knew that if we passed the test in gaming, we would easily expand into the enterprise and other software environments. Having achieved success with most of the major players in the gaming industry using our technology, we were ready to bring our technology to Java teams around the world.
DDJ: What about multi-threaded applications running on multi-core systems? Can ReplayDIRECTOR aid developers in these environments?
JL: Multi-core environments are our specialty. ReplayDIRECTOR is designed to handle any application, no matter how complex the environment, and multi-threaded applications on multi-core hardware are no different.
Concurrency and multi-threading related issues such as race conditions and deadlocks are often the most challenging types of bugs to reproduce and fix. Luckily, thread context switch timings and memory access ordering are just some of the types of non-deterministic inputs that our technology will record and replay. This means that race conditions and deadlocks will be reproduced every time during replay.
ReplayDIRECTOR changes the issue resolution process from a grueling trek through the layers of the application and compacts it down to one simple, short process. This is especially true for multi-threading related bugs.
DDJ: And ReplayDIRECTOR supports what languages, processors, platforms?
JL: We just announced the general availability of ReplayDIRECTOR for Java EE. We are currently supporting Java running on Windows, Linux, and Solaris environments.
In addition, ReplayDIRECTOR supports native applications, such as those written in C or C++, on Windows, Linux, or Solaris.
As far as processors go, any Intel or AMD x86-based architecture is supported, including 32-bit, 64-bit and multi-core chips. We also support PowerPC and Sparc architectures.
DDJ: Where can readers go to find out more about ReplayDIRECTOR?
JL: For a very quick demo, readers should check out our 3-minute video. There is also a lot of good information on the Replay Solutions website, including info on our most recent release.
Finally, there is a free analyst report by Theresa Lanowitz and Lisa Dronzek with great info.