Rest easy

Waratek aims to slash Java infrastructure costs with nifty new app

Lucy Carey
waratek-logo-teaser

With launch of jSleep, Java virtualization company claims big cost reductions for large enterprise.

 

When people use words like ‘tired’ and ‘sleepwalking’
while talking about Java, they’re usually not being kind. Waratek is hoping to turn these sentiments
around with jSleep, a new
application launched this week, which it claims will significantly
cut Java infrastructural costs – for large organisations at least-
by sending applications into hibernation when not in use.

The seeds for jSleep were germinated when the
firm learnt that, due to the difficulties in shutting off and
rebooting servers without losing data, big organisations were
keeping their servers running constantly. This scenario is also
mirrored on public and private cloud installations, something
Waratek co-founder John Matthew Holt refers to as a “deploy and
forget” mentality.

He added: “The problem is whenever
you run a complex app, something scripted and highly automated, it
needs to be set up by a person who knows how to do it. You might
need to re-link to other systems and do security or connect to data
feeds. Every time you take down an app it is a pain to put back up
again.” 
When Holt took JAXenter on a whistle stop tour
of the nuts and bolts of jSleep, he explained that the program is
essentially Wake-on-LAN for JVCs, which works by giving
instructions, settings and configuration data to the JVM. Working
on much the same principles as a computer screensaver, the JVC is
watching for activity within applications.

There are attributes about what that idleness
may mean, for example no TCP traffic, to no packets sent or
received from that application within a period of time

- or it can be more restrictive,
only reacting to
no activity at all of any kind. After
that period of inactivity, the JVM is then given permission to
‘sleep’.

This ‘sleep’ happens in three ways. Firstly, the
JVM shrinks or reduces the heap footprint in the Java heap and
reduces the heap quota used down to the minimum footprint it can
compress that application to – typically 20-40% of its heap
allocation. Action number two is that the JVM will suspend all of
the threads of that application on the operating system code –
though Holt was quick to add that it won’t destroy, shut them down
or terminate them. And finally, he explained, “the most important
thing is, the JVM will not close any file descriptor, any open
files or sockets, it will keep all of these open, but instead of
letting the application listen to them, because the application is
now frozen the JVM will start listening to those files and those
sockets instead”.

As Holt surmises, the essential motivation for
the jSleep feature is to shrink the footprint and the computational
resources required for that application. He explains that this
feature comes into its own for people who are doing a lot of Java
consolidation, such as large enterprises, PaaS vendors and SaaS
vendors – essentially, anyone with a lot of applications that have
been co-located on a single server which can be, at any given point
in time, “bone idle”.

Waratek reckon that there’s nothing else out
there like jSleep – and that’s mostly down to the way in which
Waratek’s virtualisation works. Unlike VMware, which virtualises at
the bottom of the stack, Waratek is embedded right at the top, next
to applications
. This allows them to
closely monitor for and detect idleness in apps, as well as
compress the unit, ultimately reducing its footprint. Effectively,
jSleep becomes a “property or an attribute that becomes possible
after virtualisation goes to the top of the software
stack
.

Whilst this isn’t a solution that will
necessarily benefit everyone – and Holt freely admits, if you’re an
individual developer with a laptop, then there’s not much good to
you – it’s certainly interesting to see a new take on maximising
Java infrastructural efficiency. To paraphrase Holt, the larger the
Java stays, and the bigger the volume of Java workloads, the bigger
the problem, the bigger the pain, and so (potentially) the bigger
the value [of jSleep].


Author
Comments
comments powered by Disqus