Most Read This Week
Enterprise Cloud Computing
A Funny Thing Happened on Java’s Way to the Cloud
Take full advantage of what the cloud has to offer
By: Scott Sellers
May. 17, 2012 09:00 AM
On the surface, everything seems fine. If you do a search, you'll see lots of people offering support for cloud-centric application frameworks. But, when I speak with companies actually moving Java applications into the Cloud or trying to create new Cloud services based on Java, I get a different story. It's not the application in many cases that's in the way, it's the JVM.
An example that highlights these issues comes from one of our partners, Intalio. Intalio offers Cloud solutions based mostly on open source. They and their customers are frustrated by the fact that Java can't take advantage of Cloud elasticity - the JVM strictly limits the amount of memory and cores an individual instance can use. To make matters worse, operators have to deploy multiple small instances (around 2-4 GBs of memory each) to keep garbage collection pauses short enough so users wouldn't really notice the delay. Plus, managing it all is painful. Developers have to create distributed networks within individual machines, and the IT staff has to create and launch lots of new instances and tune carefully to avoid long response times delays. (Their CEO, Ismael Chang Ghalimi, describes the problem in detail in a paper called "Cloud Computing is Memory Bound - located here: http://www.intalio.com/cloud-computing-is-memory-bound.)
It turns out this is a common practice, albeit painful. Companies and SaaS providers love Java. Nine million developers know how to program in it, a great ecosystem of JVM-based languages has sprung up around it, and you can find a plethora of tools to support Java development.
But since Java was launched almost two decades ago, technology has progressed significantly. (Remember when Bill Gates is alleged to have said that 512 KB of memory should be plenty for any application? Bet he wishes he could take that bit of folklore back.) The applications you're developing today have far greater needs for huge amounts of data, speed and deployment flexibility than they did in 1996. This wouldn't be a problem, except that the underlying JVMs that give Java its power and make it easy to develop are still (architecturally) stuck around the server capabilities available in the late 1990s.
For instance, let's look at how conventional JVMs match up with the things we love about the promise of the Cloud:
As another example of the challenges associated with deploying Java applications in the Cloud, consider our experience with a large European wireless service provider. They use a lot of Java applications both for core infrastructure and for their Web presence. In recent years the transaction and user loads have outstripped what their Java instances could handle. They created lots of instances and bought big machines, but in the end couldn't meet their business growth projections. Even the internal Java middleware system that tied together transactional systems was being overwhelmed. To make matters worse, they saw business opportunity in opening up their systems and offering cloud-based services, but in testing they were disappointed. Their current system didn't give them the visibility they needed to bill by usage. It was hard to create new instances and launch them, or move a virtual instance between physical machines. And their infrastructure couldn't dynamically allocate memory in real-time based on demand. These technical roadblocks caused by the JVM were delaying the introduction of new revenue-producing internal and cloud-based services and preventing them from creating features they thought would give them a market advantage.
SaaS providers with Java-based applications run into these same issues. They need cloud support in Java immediately (if not three years ago) to solve current issues and support revenue growth. One of our customers is a major SaaS provider in human resource management. They built their system using Java and their fast growth led in some cases to inconsistent response times and a poor customer experience because of garbage collection pauses and out-of-memory errors and the resulting crashes. Their IT team did everything they could to prevent the problems, including overprovisioning resources on machines in an attempt to handle peak loads. Because the system is multitenant, just one customer loading the system heavily affected everyone else on the same hardware. The problem wasn't the way the application was written, their application middleware or the database, but the limits of the underlying JVM. They started to wonder if they should sign up that next big customer. Could the system even handle it?
As these companies discovered, many Java issues in the cloud can be avoided. When you're architecting or developing a Java app for the cloud, pick your JVM carefully. Look for:
Recent presentations from Oracle have shown features planned for Java EE 7 and 8 that are designed to make Java more cloud-friendly. A recent presentation by Arun Gupta at Codemotion covers these roadmap items, including support for new provisioning features, more elastic scalability, multi-tenancy and Platform as a Service. Clearly, one option is to wait years for these features to show up in commercial products. Another is to take a look at alternatives like Azul Systems' Zing that has many of these features commercially available today.
The Cloud has a lot of benefits for businesses and IT. The issue with Java is that your choice of JVM can stop you from realizing many of these benefits. When architecting, developing or deploying in the cloud, don't default to the legacy Java runtime that was designed for requirements that are long outdated - look for a JVM that allows you to take full advantage of what the cloud has to offer.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads