DZone Interviews John Matthew Holt: Founder, CTO of Waratek

John Matthew Holt

I recently had the chance to sit down (via telephone) with John Matthew Holt, Founder and CTO of Waratek. We talked in depth about Waratek's new CloudVM for Java.
Topics include:

• What it has to offer to Java developers
• How it can save you money
• Its 99% Java hypervisor
• The development process
• And how it compares to the competition.

If you're a Java developer or a sys admin, you're sure to find something interesting in this following transcript:


DZone: Tell me a little bit about the Waratek Cloud JVM.

John Matthew Holt: The Waratek Cloud JVM is a brand new Java virtual machine. It's very unique; it's unlike any JVM before it because it is a virtualizing JVM. A cloud VM virtualizes Java applications pretty much exactly the same way VMWare virtualizes operating systems. We do that by building into the JVM a full-scale, first-class hypervisor. This hypervisor allows us to create a virtualized Java facility within a JVM. This JVM looks and feels on the outside like an ordinary JVM: it runs on Red Hat Linux but when you run the JVM suddenly you're confronted by the hypervisor inside the JVM. And through the virtualization engine in the JVM it creates a facility called a Java Virtual Container and the JVC is like a Linux Container—like a Linux LXC—inside the JVM. These JVCs are razor-lightweight. Less than half a MB memory footprint to boot, start and run a JVC Servers can run hundreds of these JVCs, and then you can start to do transformative things with Java. You can start to run 64 instances of JBoss applications server within a single JVM, run off Tomcat, version 3, 4, 5, 6, 7, all side-by-side simultaneously in the same JVM.

DZ: What do you think that this JVM of yours has to offer practicing Java developers?

JMH: That’s a good question. In some ways, or in many ways, people described the JVM we've developed as unique because it is a JVM designed for system administrators. And first and foremost, the standard distinction is: What was the problem or the challenges that we set out to solve with the development of the CloudVM? And very briefly the answer was this: There's recognition in the last 12-18 months in the industry that Java-at-scale has problems. Enterprise scale Java—people who want to run lots and lots of Java applications on the same infrastructure: PaaS vendors or large fortune 500 companies that have so much Java they call it the Java Estate—they face a lot of challenges consolidating and virtualizing Java applications. They draw right down to the issue of the JVM. 

When you start up a JVM it allocates a heap space. The Java application side of that JVM is only using some part of that heap—often half or less. If you're only running one JVM per server you haven't got a problem. The problem comes when you start to run 2, 3, 4, 10, 20, or more per server—you start to reach this problem or this glass ceiling where the JVMs occupy, reserve, and hog all of that memory from the operating system and the hypervisor yet actually inside each JVM the memory utilization is very low. So you get this paradox where the hypervisor tells you you've fully populated and allocated your memory, yet you know by using JConsole or RTview that you know it's not the case. So you get this situation that you just can't pack more Java applications on your server even though you know you have the capability to do so. 

There's also some other problems that sys admins have, like once you start up an application with a specific heap size like two gigabytes of heap, you can't ten days later change that to 2.5 GB without restarting the application and the JVM. These complaints are more sys-admin complaints rather than developer complaints. For the developer community the value proposition ultimately of having a virtualized JVM or a PaaS vendor or an enterprise environment operating with a virtualized JVM is that the hosting cost and the operating costs of running the application drops significantly.

DZ: So what sets your JVM apart is the way that it significantly reduces operating costs?

JMH: Absolutely. The key starting value proposition is, first and foremost, significantly lowering the operating cost for a large number of Java applications by increasing the consolidation relations that admins and operators can achieve by driving up the density of Java apps per server that they can pack. The effect is that if you have an estate of 300 maxed-out servers running Java applications, with the Waratek JVM that may drop to 150 or 100 servers. So an additional 200 servers can be decommissioned and that comes off the bottom line.

DZ: What sets you apart from other Cloud JVMs?

JMH: In the Java and JVM space there really isn't an equivalent cloud VM. Including Waratek there's essentially only four: there's the Oracle suite of JVMS-Hotspot and OpenJDK—there's the IBM J9 JVM, there's the Azul JVM and that's pretty much it from a commercial perspective. It's very unique to be walking in the Java space and to provide a design for elasticity, multitenancy, and resizing on the fly—which are all characteristics of cloud computing but which have never been a property of Java before. In the Java space there really is no cloud VM to compare against. Outside of the Java space: Python, Ruby, Perl, etc., these environments already have and are friendly toward elasticity and multitenancy than Java and JVMs have ever been. There is a recognition that Java has such a long way to go—it's not a language problem or an API problem—it's a JVM problem. There are only a few parties in the world that do that kind of work in a JVM that have the potential to solve this problem.

DZ: How do you feel going up against some of these big names like Oracle or IBM?

JMH: [Laughter] There's a very healthy appreciation and value for innovation. Java is fundamentally positioned and promoted as an open community standard. Of course there's the governing body—an elected representative group of developers, users, customers, and vendors who develop, grow and promote Java. So Java has a natural openness and I think everybody is interested in seeing Java continue to hold its station as the single most dominant development environment of the last 10 years. If you walk into any large enterprise today and ask them what the major application development language that they use today, it's Java.

For people who question if Java is going to be the new Cobalt as it were—well the second question is what is going to be the new Java? There's really nothing that can step up and take the place of Java. Because of that everybody is interested and motivated to continue to see Java thrive and grow. And yet there has been this sudden emergence of a realization that Java has limitations and is not adapting to the cloud well and is not proving economic and lightweight for elastic and multitenant environments. There's a great interest for all parties to solve this problem to allow Java to continue to grow and thrive.

DZ: How do you see the Waratek Cloud JVM changing the development world?

JMH: Ideally I'd like the Waratek Cloud JVM, from a developer perspective, to be transparent and invisible—allowing programmers to write the code they want to write, take the shortcuts they want to take, and produce their applications in the most economical and speedy way possible, but provide the hosters and the operators who have to run those applications a much more economical, easy and powerful way of managing those applications: big and small.

One side comment—one of the novel, exciting features of the Cloud VM is that the hypervisor running inside the JVM is very uniquely 99% written in pure Java itself. That's quite an achievement but we do that for a very specific reason—by writing the hypervisor in Java we publish and we can publish the internal API of the hypervisor itself and allow anybody to write their own extensions, enhancements, plug-ins, and adapters, to the hypervisor. I think this is where programmers and developers start to get interested and excited, because it's the only API we publish but it's a very powerful API where they get the opportunity to change the way Java operates for them and do that for the very first time.

An example would be: Say you have a JVM running lots of JVCs and lots of applications each running one different JVC. If you wanted to change the file system that is accessible or seen by JVC #7, say, in any ordinary JVM you have to open JDK, jump into C code, modify C code to change the way the Java applications interacts with the file APIs and the operating system, custom compile JVM (it would no longer be TCK certified), and then you have this very strange, kind of unsupported JVM.

But, when you have a hypervisor running in the JVM and you publish the API to the developer community allowing them to change the way the virtualization works in the JVM, if somebody wants to change the file system in JVC #7, all they need to do is write one pure Java class. They can implement the file environment interface defined in the hypervisor to find, say, about 23 functions, override those 23 functions, and then while JVC #7 is running, they can go JVC07.attach(<their object that implements the file-drive interface>) and just like that [snap] java.io.File, java.io.FileInputStream, java.io.FileOutputStream, java.io.RandomAccessFile, ZIP files, JAR files, and so on, all transparently, immediately, and seamlessly get mapped onto their implementation file-driver. So it allows programmers for the very first time to do things like chroot in pure Java, encrypted file systems in pure Java, and the like. That's very exciting to fundamentally be able to change the image of a JVM for applications and with the hypervisor you can change the file system, sockets, server sockets, threads, CPU, memory, and everything about a JVC—you can completely redefine anything about a JVC on the fly in pure Java.

DZ: What was the development process for this JVM like?

JMH: [Laughter] Long. And labored. Developing a JVM is not a walk in the park. The community of practicing JVM engineers is very small, perhaps as small as 200-to-300 practicing JVM engineers. It's quite a phenomenal statistic if we think that this small community of several hundred people writes the foundational software that is used by 9,000,000 practicing Java developers around the world. So it's a very imbalanced relationship between the people who develop it and the people who maintain it but the real challenge for us in developing a JVM and so radically and significantly innovating in the way the JVM operates was to recruit up a team of JVM engineers, train them, teach them, turn them into JVM experts, and then cut right to the core of the JVM and start to rethink from almost the first principles what is the operation of a JVM and how do we start to fundamentally virtualize and bring virtualization capabilities into the JVM. So the development process was plagued by the challenge of adapting and transforming virtualization techniques, frameworks, and concepts that hypervisors are familiar with, but apply those inside the compiler of the JVM, inside the garbage collector, inside the VM substrate. And that was the real challenge: doing a translation or a metamorphosis of a technique that began its life at a hardware level and adapting that so it can fit an abstract machine environment.

DZ: What other interesting things are going on at Waratek?

JMH: We have an exciting roadmap going ahead over the next 12+ months with new features and enhancements to the product. All the way from things like multi-version JVCs where JVCs can run different versions of Java to the host JVM, new features like sleep and hibernate which don't have any precedence in the virtualization world. More classic features like live migration and snapshot of JVCs. These are all tools, these are the backbones of the way systems administrators use and operate their hypervisors today, but they've never existed in the Java and the JVM world, so hypervisors always resorted to the hardware virtualization level to do their live-migration, to do their snapshot and by definition then what they're migrating or snapshotting is not just the Java applications: they're snapshotting the whole operating system, they're snapshotting all the drivers in the operating system, they're snapshotting the JVM itself, and so forth. But by bringing that same facility and putting it into the JVM with the hypervisor that's in the JVM it makes for very fine-grain, very lightweight, very easy-to-use, very powerful live-migration snapshot facilities—these same kind of facilities that people already love from hypervisors but bring that into the Java world for Java administrators, but also to Java programmers as well.

DZ: Switching gears--I understand you recently gave a talk at the New York Enterprise Tech Meetup?

JMH: I was one of three talks at the NYET Meetup—a fabulous group of about 100 very diverse people from all sorts of different institutions and backgrounds in New York. I presented Waratek JVM there, introduced them to it and gave a live demonstration and had a very strong and very exciting response!


DZ: Thanks for speaking with me, John.