Keep calm and jClarity

jClarity launches performance tuning tool for Java in enterprise and cloud

Lucy Carey
JClarity

Following the unveiling of their flagship product, we catch up with CEO Ben Evans for the lowdown on the new release, and find out what’s next for jClarity.

Since the company’s
inception last December, jClarity have been marshalling their
Java expertise to create a new analytics product. They’ve now
emerged from their East London base with the new jClarity
performance tool, designed to present diagnoses and solutions to a
range of Java and JVM performance issues in plain English, and
bring harmony to your development team. We spoke to CEO Ben
Evans
for the story on their new release.

JAXenter: Can you tell us what challenges you
set out to solve with the jClarity performance tool?

Evans: In the existing marketplace
for performance software, one of the problems is that what’s
available is very good at generating a lot of data, but what they
are not good at is actually providing context that will allow you
to see what the data means. What we want to do is to move the
problem from data collection to data analysis and
insight.

So a step up from what’s on the market
already?

Well, they are very useful tools, and they
certainly have their place, but they can only go so far, and if
you’ve ever been in one of those situations where you’re trying to
use them to debug a serious problem, you kind of reach the point
of, ‘And now what?’, where you’ve got the data, but quite often the
operations team aren’t data analysis experts, they don’t really
know what it means, and how to spot patterns and correlations in
it.

It’s about trying to find a common ground for
anyone where everyone involved in the performance analysis process
can meet up. So you have operation staff,you have developers, and
you have management and often – I saw this all the time in banks –
what would happen is someone would write a script to collect some
data which they felt was important to the problem, and then they
would pass it around in an email, maybe with a couple of
screenshots, and then everyone would just argue about what it
meant.

Whereas, with jClarity, you have the agent, it
diagnoses the problem for you and it can pinpoint about eight or
nine large classes of problem that applications have, then it
stores that record of it, so people can go back and refer to it. It
provides you with a lot more context and a lot more high level
pointers as to what’s actually going on.

The other interesting thing about it is that,
traditionally, people have always focused on performance monitoring
and production, but if you have analysis tools, you can do
something more than just monitor production. You can actually check
code as it’s going in, for example, in a QA or a pre-production, or
a performance testing environment. You can actually analyse
software and products before they get anywhere near a live
customers, So, as well as the early warnings, the, ‘Oh god we’ve
got a problem, we need to fix it now!’ side, we can also do massive
risk reduction.

Would you say that this significantly cuts
down the performance testing process?

Often in large enterprise you have an external
testing team, and they are probably in many cases not well thought
of by the developers, and they get a bit of a hard time, and you
see the same pattern repeatedly; the QA team go, ‘I’m not sure
about this release’, but the development team go, ‘Oh we wrote it,
so it’s fine’, and so the QA guys end up getting overruled. The
release goes in, and then it breaks stuff. But, with our program in
place, you don’t have that problem, because the QA team now have
something concrete to print out. Development teams have to justify
themselves to the QA team, and it’s a lot more quantitative and it
provides that level of communication which is lacking, I think, in
other tools.

Can you tell us more about the kind of Java
and JVM issues which you think jClarity’s new product will
particularly help developers with?

We can do anything from threading to garbage
collection, to application code, to external problems, something
coming up on a database connection or something like that, so we
really do think that we’ve covered all of the major bases where web
performance problems can hide.

Developers often have, as we all do, certain
cognitive biases. If you talk to a developer about what makes an
application and what makes it slow, they will always think of code,
because that’s what they know about and that’s what they’re trained
to think about.

Quite often, in my experience consulting, and
talking about, and listening to customers that have these kind of
performance problems, developers’ application code and algorithms
are a problem probably only ten percent of the time. Nine times out
of ten, it usually is something other than the way that the code
has been written. So that’s one of the other cool things about
jClarity  - it removes that human bias. It’s the machine
itself that sees where the problem is and will tell you where to
find it.

You describe yourself as ‘pioneering’- is
there anyone else at the moment that’s doing something similar to
what you, or do you feel like you’re totally unique on the
market?

I would say that we are highly complementary to
tools that are  already out there, because no-one does exactly
what we do,  but at the same time, we’re only a small start
up, we only have limited resources, we haven’t tried to go out and
solve all the problems that already exist. For example, JAXenter
readers may have New Relic or they may have Appdynamics, and you
know, they’re good tools. But they don’t do what we do.

I think people in a similar space to us can’t do
the kind of analysis we can, because we’re focused on really taking
the essence of the problem and boiling it down and producing a very
smart system which learns. And that’s the other thing about our
system – once it’s calibrated and once it’s on the machine, it just
continues to get smarter.

You told us about your future objectives when
we last spoke in January, which were to get your tools in the hands
of developers and ops folk that need them, reduce the stress levels
of fellow technologists,  build your piece of the “real
Cloud”, and keep up the intensity & building tools that raise
the standard of the industry. How far have you come in achieving
these goals?

Well, the with progress that we’ve made with
jClarity, I think now we’re just about to see a payoff. We’ve
discovered with some of our earlier customers that the way jClarity
can really be used is part of a production build team, and also in
QA.

It’s also become very clear to us that what
we’re building is cloud native, but also can be applied in the
enterprise. And in fact, one of the places where we are really
expecting to see a lot of value for customers with jClarity is
people who are about to make their first cloud
deployment.

If you look where large enterprise spend is
happening, everyone’s talking about the cloud, but not that many
enterprises are fully cloud native and some are still struggling
with their initial deployments.  So, the performance
characteristics of a cloudless application are totally different to
one which has been hosted on their premises, because you have
virtualisation, you’re sharing resources, it just doesn’t look that
similar, and if you’re a bank or a financial, you’re used to just
buying a big load of servers and just building out a data centre
and not having to think about how your resources would be
shared.

In many cases that means you’re carrying a whole
lot of risk, and if you start to move those applications across on
to cloud sensors, there’s a real possibility that something’s going
to break. If you have jClarity running, you put it on the QA run
for your cloud deployment, and you can try it out. We can find a
lot of those problems for you, before you go live on
cloud.

We do also maintain a number of open source
projects that are
on our GitHub
account
, in particular there are testing tools,
and some of the things we’ve open sourced are projects run
deliberately badly, because one of the problems we’ve found is we
need a nice clear signal in order to prove that our application and
our tooling works properly.

Are there any other projects in the pipeline
now you’ve launched your flagship product?

Very good question. We are looking very closely
at customers and seeing what they are developing, and what they’re
going to need, and I would think that post-JavaOne, and all the
conversations there that we’ll be having with people. we should
have a much clearer picture of what our roadmap is going to look
like for the next year.

It’s not necessarily always about the core
analysis capabilities. Of course we’ll continue to refine those, of
course we’ll continue to add in new features and deeper dives into
the areas that customers say they are interested and want more
detail, but the things that we won’t compromise on are complete
focus on customers. One of the things that we realised when we
started looking at the space was that a lot of the products on the
market didn’t always have great customer interface. We want our
product to be easy to use and straightforward, even for people who
aren’t professionals.

Author
Comments
comments powered by Disqus