Java in the Azure Cloud

Tuesday, Apr. 26th 2011

Microsoft has been promoting the use of Java in the Azure cloud, and has been providing lots of material showing how it’s done. They’ve also been distributing Java tools for Azure, including an SDK for Eclipse, and an Azure accelerator for Tomcat. Their latest offering is the “Windows Azure Starter Kit for Java,”? which provides tools for packaging and uploading Java-based Web applications running on Tomcat or Jetty. In considering this, the main question that comes up is “Why?”?

It doesn’t work

“It doesn’t work”? is an extreme statement, isn’t it? And Microsoft has demonstrated that it can create Java Web apps and run them on Azure, so why do I say it doesn’t work? The problem is that these examples are extremely constrained. For example, Azure makes a virtue of its lack of a persistence mechanism. Instances can fail or restart at any time, which means that data isn’t persistent between instances, and applications therefore must not depend on persistent data. However, both Java Web applications and the servers they run on do depend on some sort of persistence or state. With effort, the applications can be re-engineered, but one has to wonder whether it’s worth the effort to do this, or whether the time might be spent moving to a different cloud offering where this re-engineering doesn’t need to be done. There’s also the problem that the Tomcat and Jetty servers themselves require persistent data to be stored. And the problem gets even worse when we go from a simple servlet container to a full-fledged application server like JBoss, WebLogic, or WebSphere: application servers, and the Java EE programs that run on them, rely even more deeply on persistent data. While some Java EE application servers can be altered to use alternative persistence mechanisms like Azure storage, the process is arcane to most Java EE developers and not worth the trouble; it would probably be simpler to use a cloud offering where the application server can be deployed without alteration.  In addition, a default application server relies on an extensive array of network endpoints for a variety of protocols that exceeds the number allowed by a worker role or a VM role. To run an app server on Azure, it is necessary to cut down the number of endpoints to the point where much useful functionality is lost. While it may be possible to construct Java EE examples that work as demos, it’s unlikely that any real Java EE apps, web-enabled or otherwise, can be migrated to the Azure cloud without drastic, impractical or impossible, modifications to the underlying application servers in order to accommodate the persistence and networking issues.

It’s not what users want

Beyond the technical issues in getting an app server running on the Azure platform, we need to ask why we would want to do this on a Platform-as-a-Service (PaaS) such as Azure, when it would be far simpler to run such an application on an Infrastructure-as-a-Service (IaaS) offering like Amazon EC2. It’s one thing to say it can be done; it’s another thing to actually want to do it, as opposed to the easier alternatives. The market seems to bear this out – a recent Forrester study shows that Eclipse (that is, Java) developers prefer Amazon EC2 or Google App Engine, while Visual Studio (that is, .NET) developers prefer Windows Azure. Developers really don’t want to go through the contortions of packaging up their Java app plus the app server or servlet container, then configure and start it up as a special action under elevated privileges in an Azure worker role, just so that they can run Java EE, when they can easily install their application on a convenient Amazon EC2 image.

What users do want, it doesn’t do

Users will want to do things with Java on Azure, but not what the creators of the Azure Starter Kit for Java think they want to do. Rather than running a self-contained Java server in an Azure role (something they can more easily do elsewhere), they will want to integrate their Java with the .NET code more directly supported by Azure. For example, they may well have a Java library or application that they want to integrate with their .NET application. Depending on the Java side’s architecture, the Java might run in the same process as the .NET code, or it might run in its own process, or even a separate worker role. In any case, the Java side wouldn’t need to run in a full-fledged app server; it would simply expose an API that could be used by the .NET application.

A scenario like this is exactly the sort of thing that JNBridgePro supports. Java can be called from .NET code, and can run in the same process or in separate processes running on different machines. Up until now, those JNBridgePro deployments have been in on-premises desktop and server machines. In our upcoming JNBridgePro Cloud Edition, it will be just as straightforward to implement these interoperability scenarios in the cloud.

In summary, there’s a role for Java in the Azure cloud, but we think Microsoft is pushing the wrong scenarios. The Azure Starter Kit for Java is clever, but it (incompletely) solves a problem that cloud developers don’t have, while ignoring the real-world problems that cloud developers do have.

Posted by Wayne | in Cloud | 2 Comments »

2 Comments on “Java in the Azure Cloud”

  1. Arun Gupta Says:

    Agree with your assessment on the current state of Java in Azure, it’s pretty lame and requires to jump lots of hoop to get a basic sample working. I even published my Java wishlist for Azure at:

    Also tried the Eclipse plugin and most of it seems like a placeholder and a rush release to put a stake in the ground. I also published a blog explaining how to run GlassFish in Azure and explained at:

    The part I don’t understand is why will Java developers deploy their applications in Azure instead of EC2 or other more Java-friendly platforms.

  2. Steve Carlisle Says:

    Actually, last I hear, 2 of the top 5 apps (based on consumption) in Azure are written in Java. I think my company is running one of them.

    The main reason I like Java in Azure is that I hate operating system maintenance. I hate stack management. I just want to code, and frankly, after the first time you build a Java app in Azure with Eclipse.. you can just code and deploy. The pains of first doing it is the only issue, but after that, it gives me better results that AppEngine (hate the fact that it’s Java support is so weak), and doesn’t have the management that AWS makes me do.