Waratek is a one-off company with a disruptive technology (remember VMware was like this once) that forces you to reset your undertanding of how things could work. Waratek’s big idea is that you virtualize as high up the stack as you can because that gives you the best benefit in terms of sharing infrastructure. So rather than replicating operating systems on a hypervisor accessing shared hardware, you simply replicate as small a part as possible of the Java Virtual Machine (JVM). Everything else (hardware, operating system and most of the JVM) is shared.
The rationale goes like this. Much of the enterprise workload that is being virtualized consists of Operating System instances each running a single Application Server instance with it’s own JVM, running a single Application. Both Java and non-Java JVM languages typically generate WAR files which are deployed this way. If you virtualize that in the traditional way you are replicating vast amounts of Operating System, Application Server, and JVM that takes up memory and needs to be switched back into cache when the hypervisor changes context.
Production applications are deployed in separate Application Servers because it is very difficult to share a JVM. Applications in the same JVM compete with each other for heap which has to be statically allocated when the JVM starts. In turn the Application Servers are deployed to separate Operating System instances because once you have multiple JVMs they have multiple garbage collectors that compete for CPU, and also the Operating System struggles to re-use the memory pages between JVMs. All of this makes it difficult to predict performance behaviour when multiple JVMs share the same Operating System, so people typically don’t do it outside of development.
Waratek has developed a custom JVM, which is certified by Oracle, but which differs from other JVMs in that it is a “host” and within it there are multiple JVM instances running as “guests”. Each guest JVM has its own heap – but the size of that can be dynamically changed – and there is a single garbage collector for the host.
Indeed, as much as possible of the JVM is shared between the JVM guests. If we were comparing it to traditional virtualization, Waratek is more like Linux Containers (where the container is thin and the base O/S is thick) than a traditional thin hypervisor approach like ESX. To make the analogy even more direct, Waratek has developed a libvirt driver for the JVM so you can use tools that speak libvirt to grow, shrink, switch on and off and live-migrate your JVM guests just like Virtual Machine guests. Moreover, you can run different versions of the JVM as guests inside a single Waratek JVM host. A 1.7 Waratek host JVM can run a 1.4 JVM guest alongside a 1.6 and a 1.7 guest for example.
Through management of the JVM (and without any changes to the Application Servers) it then becomes possible for multiple Application Servers to operate within the same host JVM in different guest JVMs, each with their own heap. It is also possible to configure the CPU resources allocated to each guest so that they don’t interfere with each other, and to do fine-grained metering of the application’s use of resources through standard JVMTI calls to the host JVM.
A JVM doesn’t actually need to run on an operating system (as we discussed in Virtualize Java without an Operating System) , so in principle it would be possible to deploy a JVM to bare metal (or just to a hypervisor). However, Waratek have’t gone down this route and instead the JVM is packaged for Red Hat Enterprise Linux (RHEL) and CentOS, and available for other distributions on request. So to use Waratek you can buy a big Physical Server, install Linux (don’t virtualize) and run one host JVM with multiple guest JVMs, each running a different Application Server instance.
Given that there are no changes to any other part of the stack (Application, Application Server or Database) and that the JVM itself is certified by Oracle, Waratek is a fairly low-risk try-out for an operations team that has an overstuffed datacenter and/or ambitious consolidation goals. It shouldn’t be necesary to go back via development – there are no code changes, and you can continue to use your supported Application Servers. Only insead of patching them on multiple Virtual Servers, you patch them on a single Physical Server.
This is neither open source nor free to deploy, after a trial period you have to pay per guest JVM. Enterprises typically previously haven’t had to pay for JVMs, but you don’t need additional virtualization software so costs could end up being significantly less than virtualizing in the traditional manner. It will be dependent on the actual level of consolidation achieved. Remember it won’t virtualize the database unless it runs inside a JVM (and anything in use in production likely doesn’t).
This is all fairly new, so we don’t yet have a good view on a number of issues such as Security – specifically escape the guest JVM attacks (everything inside the host JVM runs as a single Operating System user, so the Operating System isn’t any use here).
Waratek is currently aiming to sell this to enterprises to run inside the datacenter – so some of the security issues that would exist in a public PaaS don’t apply, but in reality if this does work and the security is sound this is a perfect match with PaaS. Why mess around building on a complex underlying IaaS or Virtual Infrastructure. You can simply fire up JVMs on servers, and all the management can be done via Libvirt directly against the tenants’ JVMs. It’s much easier to implement, and easier to understand.
Sounds like a great idea and a good place to run the host would be on top of VMware vSphere so you can also take advantage of the advances features and robustness of the platform to further reduce risk and allow additional DR capabilities and non-disruptive maintenance.
Hi Michael,
It’s very early days with this product, so it’s not clear exactly how it will be deployed or how widely used it will be. It’s no threat to VMware yet 😉 and there is always a tendency in the markeplace to layer one innovation on top of another, so you may well be right.
I guess where this gets interesting is that when you get a bunch of standard virtualization management tooling that can use standard APIs to manage guest JVMs and deal with all the DR and non-disruptive maintenance at that level, adding O/S virtualization is just adding complexity. It will mainfest itself in the tooling as hierarchical virtualization – a virtualized entity within a virtualized entity, and we generally don’t deal with that at the moment.