Waratek aims to slash Java infrastructure costs with nifty new app
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].