InfoQ Interview: Making Your Java Application Production Ready

 ● 19th Aug 2015

4 min read

InfoQ interviews Tal Weiss: Debugging strategies for release cycles on steroids

Developer teams want to push code much faster and see its impact in production. Many times it’s also simply the only way for their companies to stay relevant and keep up with the competition. In order to be able to do that, you need to go beyond implementing Continuous Delivery / Continuous Integration practices and create a production debugging strategy to keep your application afloat.

Fast and furious debugging

In a recent interview with InfoQ’s lead Java editor Victor Grazi, Tal Weiss, OverOps CEO, shares some of his insights about the state of these new demands, and what has to be done in order to make your fast changing application – production proof:

“The main challenge we’ve seen is that companies don’t prepare in advance as to how they’re going to debug and monitor their situation. They ship; issues start happening and then it becomes this really kind of wild chase of trying to get the right tooling in, trying to understand what’s broken with the architecture, how to optimize things at the software level, the GC level or the JVM level.”

“The biggest advice that I can give to any company is make sure that while you’re building out the software, while you’re designing the new application, the new system, already have a monitoring, a debugging, a logging, a devops strategy in place that you build in tandem with the actual code that you’re writing. So come launch day, you will have a very good level of visibility into what’s going on. That will really help you and save you a lot of time when things break down, when you’re pushing your code and things happen, and you have the tooling and the methodologies in place.”

“These will also change and scale and mutate as the application grows and matures. But just having that frame of thought in from day one I think is something that is really a good practice to adopt.”

Logging is not what it used to be

Moreover, Weiss also goes into the future of logging, and how this rather static area that hasn’t changed much up until recent years – Is going through a revival:

“One of the biggest changes that are happening especially within that sphere is that if up until a few years ago, the main consumer for a log file was an engineer, essentially who is just grepping through a log file, just looking for something, looking for a pattern, looking for bits and pieces of information that will help him or her debug something, troubleshoot something. Now the primary consumer for logs has changed. The primary consumer for a log file nowadays for the most part is a machine who will essentially take that logging stream, that stream of logging messages that are being put into the file and begin to glean meaning from that; visualize trend information, anomalies.”

“There’s been a lot of movement within a lot of companies moving towards metric-driven development. So now we can automatically pull metrics instead of putting a lot of information to the log file with the hope that somebody can process that later and then visualize it for us. Tools like Grafana, DataDog and Librato, are now encouraging us to send metrics directly from our application into the devops dashboard via industry standard protocols.”

The full interview and transcript are available on InfoQ – Play video

To dive deeper and go beyond the 10,000 foot view, you can also check out this hands-on session on how to make your own code production-ready. And to top it up, also be sure to check out this roundup of the most advanced Java debugging techniques you can (and should) use today.

Duke on logs

We hope you’ll find these resources useful and if you have more questions that you’d like to be covered, please feel free to use the comments section below!

Alex is the Director of Product Marketing at OverOps. As an engineer-turned-marketer, he is passionate about transforming complex topics into simple narratives and using his experience to help software engineering navigate their way through the crowded DevOps landscape.

Troubleshooting Apache Spark Applications with OverOps OverOps’ ability to detect precisely why something broke and to see variable state is invaluable in a distributed compute environment.
Troubleshooting Apache Spark Applications with OverOps

Next Article

The Fastest Way to Why.

Eliminate the detective work of searching logs for the Cause of critical issues. Resolve issues in minutes.
Learn More