Plumbr is all about detecting performance problems in Java applications. Whether this application is residing in a desktop machine under developer’s desk or hidden in a production vault guarded by the Bastard Operator From Hell– does not matter. We have designed our software to cover both ends of the spectrum. Or so we thought. Oh boy have the last couple of months proven us wrong.

Installation. Installation has to be easy. What can be easier than clicking on the downloaded JAR file and pressing NEXT for a few times?

Wrong, especially when your software is intended to run in dark corners of the server room. Instead of Swing-based UI’s you should start thinking in terms of rpm -ivh yourpackage.rpm and its close relatives like dpkg or yum,

To make things worse, organizations use different tools to support their release processes. Before you can say “I got this package management thing covered” your support channel will be overrun. Requests to embed your installation into shell scripts, continuous integration tools, release management software or configuration management tools will be flocking in. And just when you think you have it covered there will be the next Ansible just around the corner requiring your attention.

License server. Many B2B solutions are licensed in capacity-limited formats. Whether a particular piece of software is licensed by the number of users, server capacity by transaction volume does not matter that much. Your enterprise level clients wish to have transparency and control over their licensing deals. So you toss in your own custom-built licensing server.

Only to discover hate mail filling your inbox the day after releasing your license server. Apparently installing 80 different license servers from 80 different vendors is not something operations are eager to deal with. So before designing your proprietary solution, take a look at common licensing formats and making sure your licensing solution can easily be integrated into corporate licensing solutions.

API support. Of course you need to provide an API to  your service. What could be a more appropriate than publish your interfaces as MBeans?

Well, if you bother to look up from your Java developer seat then you might again be surprised. JMX is about as well-known and widely used as Microsoft’s WebTV. But give operations an API they actually can and want to use and you will discover them using your product in ways you did not even think about. Publishing alerts created by your service to instant messaging solutions or embedding the statistical information into custom built company-wide dashboards. I bet you did not think about that.

The key here is also in publishing raw data. Apparently operations want the freedom to aggregate their data themselves.

Rolling out updates. Notifying users when a new version of your software is out and recommending an upgrade – this should be a no-brainer, right?

Well, try to deploy your software to 100’s of people within a single organization and wait for the next update. Voilà, you have just summoned most of them to contact helpdesk on the same day asking about these upgrades. Toss in frequent upgrades and you have created a nightmare for your customer.

Packaging. If you live a life of a -javaagent, then it should be obvious. You want to live your life packaged as a JAR file and if lucky, get promoted to an IDE plugin.

If you somehow scrolled over the installation section above, then let me repeat the key take-away: your solution must be embeddable to different tools and processes. You can and you will have your own face, but do not be surprised being bundled into other tools and solutions.

Logging. It shouldn’t really matter, does it? log4jslf4jlogback – pick one and be happy with your pick. Unless you are Ceki Gülcü, you could actually just roll a dice and be done with it?

Nope. Operations seem to have a sweet tooth to control what, when and how is being logged. Some of them just wish to log everything just in case and toss it to Logstash for future pattern detection analysis. And then there are guys who wish to add tampering-proof certification to their logs. And then the security audit team steps in to make sure that you do not log any financial or otherwise sensitive information.

The original post was posted in Plumbr performance tuning blog.