Changes to Java and VMware software licensing that have been rolled out over the past few years have a material impact on the total cost of running existing Java-based enterprise systems. IT decision-makers are having to weigh up the extra costs with the additional cost and potential disruption arising from reengineering enterprise Java applications to take advantage of cloud-native architectures.
It’s widely acknowledged that IT departments face difficulties modernising enterprise applications that have been running core business functions for years. Java was one of the main languages for developing enterprise applications, as its runtime environment, called the Java Runtime Environment (JRE) enabled code to run on any Java-supported hardware. The code was optimised when the software was run using just-in-time compilation, which has enabled Java applications to take advantage of the latest hardware developments.
But older applications that were architected well before the era of cloud-native computing do not always work efficiently when re-hosted on a cloud platform. Some Java applications can be migrated relatively easily and are able to make the most of cloud-based IT infrastructure, while some, which have been engineered more as tightly bound, vertically integrated systems, may not run particularly efficiently in the cloud.
As Scott Sellers, president and CEO of Azul Systems, points out, the speed required by enterprises to continue to innovate to stay on top is always going to be difficult in an environment where there are a lot of existing applications and legacy IT.
According to Sellers, at any one time, there are 60 billion active Java virtual machines (JVMs), of which 38 billion are in the cloud. “Java is quite prevalent, running all sorts of different workloads,” he said.
Much of the cloud-hosted Java applications will be running in proprietary virtualisation platforms provided by public cloud providers; others may use popular platforms like VMware or OpenShift, and there will be some that need to run directly on the base hardware.
“Where speed is everything and businesses don’t want any extra layers of software, we see high-performance applications that are not virtualised today,” said Sellers. “But the majority of applications are using some form of virtualisation.”
A double whammy
A few years ago, Oracle simplified licensing of Java. Given the prevalence of Java hosted on VMware vSphere, licensing used to be priced based on the number of physical cores of the server hardware.
Oracle now sells the Java SE Universal Subscription based on the number of employees. While this simplifies licensing, it can amount to a Java licensing price hike. Companies like Azul Systems have seen an opportunity to migrate organisations using Oracle Java (Oracle JDK) to their own alternative, based on the open source OpenJDK version of Java. For instance, the Azul Systems version is called Azul Platform Core.
Now, with Broadcom’s acquisition of VMware and its own subscription strategy, organisations using VMware to host their Java applications have to purchase both an Oracle Java SE Universal subscription and a VMware Cloud Foundry (VCF) subscription from Broadcom.
While it does bundle several previously separately licensed products, as Computer Weekly has previously reported, many VMware users will find that their costs increase as they switch over from the core vSphere VMware virtualisation platform to a full VCF subscription.
Lift and shift, and efficient virtualisation
But as Sellers notes, the flexibility of the Java platform means IT decision-makers can lift and shift Java applications from one virtualisation platform, such as VMware, to another, like Red Hat OpenShift, relatively easily. This is an option IT decision-makers can assess when evaluating the total cost of ownership of their enterprise Java applications.
But there are also opportunities to move beyond server virtualisation to containerisation. Here, the Java application needs to be engineered in a way that it can be segmented into small manageable blocks of code that can then be converted to microservices.
Such applications are deemed cloud-native and tend to use cloud-based resources more efficiently than larger, more monolithic Java applications.
The Java platform also offers the potential to improve how virtualised or containerised Java applications run. According to Sellers, there is a lot more information in a running Java virtual machine that is currently not presented to optimise virtualisation or container management.
“There is a tremendous amount of information in the Java virtual machine itself, which can make deployments in containers much more efficient by providing additional information to the Kubernetes management infrastructure,” he said.
As an example, Sellers said that with Java workloads, this information could help Kubernetes make decisions a little bit smarter, such as for auto-scaling. “In today’s environment, Kubernetes orchestration layers are really still looking from the outside in,” he added. “They use fairly coarse grain metrics such as processor utilisation and memory consumption, but there’s a lot more information inside a JVM that could enable the Kubernetes orchestration engine to be smarter.”
There are also efficiency tweaks that can be made to improve Java’s efficiency when run on cloud-based IT infrastructure. As an example, among the technical features Azul Systems provides to improve how JVMs run in a cloud environment is its Cloud Native compiler.
“Every time that a job application starts, it’s doing the same thing on every node: it’s starting up; it’s doing the compilation; it’s warming up, and eventually gets up to full speed,” said Sellers.
He added that much of these tasks are redundant since a JVM replicated across multiple nodes will be doing the same thing. “You’re basically doing very similar work, you’re just scaling them out to be able to handle your aggregate throughput,” said Sellers.
As part of Azul Systems’ Prime Platform, the Cloud Native compiler provides a shared compiler service, which runs as a Kubernetes managed environment.
Given Java’s footprint in the cloud and the fact that IT leaders are experiencing rising costs of enterprise Java systems hosted on VMware, there’s a compelling business case to move away from the Oracle JDK Java implementation to an OpenJDK-based alternative and switch from VMware to an alternative platform for hosting these systems.
