Java and Azure

The Announcement

Microsoft recently announced a partnership with Oracle which brings a number of Oracle technologies to the Windows Azure cloud.

In short, they announced:

  • Hyper-V (i.e. the virtualisation technology underpinning Azure) is now certified to run Oracle software.
  • Virtual Machine images will be available with the Oracle Database, and Weblogic preconfigured.
  • Properly licensed and supported Java on Azure.

Items 1 & 2 I’m not that excited about, but it’s item 3 which is interesting.

The current state of Java on Azure

Microsoft have supported Java on Windows Azure since the start. There’s an SDK and tooling built into Eclipse.

However, Microsoft haven’t been able to install Java, you’ve had to do that yourself. This has meant that the package you deploy to Azure has had to contain the Java installer, any frameworks and web servers you need, as well as your application code. This makes the package too large to work with, in some cases too large to even upload. It certainly slows down application updates.

Utilities such as AzureRunMe have helped bridge this gap, by splitting your package into separate zip files in blob storage which are only downloaded when required. However, ultimately you have to do more work to get Java running, and it takes longer to spin machines up.

Having said that, Java applications work surprisingly well in Azure. Applications are coded against the JVM, rather than the operating system and make relatively few assumptions about the environment. They also tend to use ORMs (like Hibernate) giving you a simple database schema which is easy to port to Windows Azure SQL Database.

I often find that Java applications are quicker to get running in Azure than similar .NET apps.


When we talk about Java here, we’re really talking about the Java Virtual Machine (JVM), the runtime which hosts Java applications.

Java is just one of the languages supported by the JVM, there has recently been a small explosion in language options on the JVM, including:

  • Clojure
  • Scala
  • Groovy
  • Jython
  • JRuby
  • Kotlin

…to name just a few.

What does this mean for the future?

I haven’t got any special knowledge here, but there are few things Microsoft could do now:

  1. Provide a ‘Java’ role in Cloud Services. This would have Java and (optionally) Tomcat pre-installed, making deployment of Java applications faster and easier.
  2. Enable the JVM as a hosting option on Windows Azure Websites (alongside Python, .NET, PHP and Node.js).
  3. JVM support gives you Ruby (using JRuby). There’s already a Ruby SDK for Azure, and JRuby seems to be the fastest Ruby runtime (AFAIK). This is potentially true for this long list of languages too.
  4. This is probably good news for Hadoop on Azure.
  5. Enterprise Java developers should certainly take note. The capabilities of the Azure Service Bus, coupled with competent PaaS and IaaS offerings and the low-cost SQL Database, make Azure an attractive option.

Hold On, Load balancing…

Java web applications (in my experience) often hold large object graphs in memory, as state stored against each user session. This means that sticky sessions are required, and the Azure load balancer in Cloud Services is round-robin (sort of). Sticky sessions aren’t very cloud friendly, but it’s difficult to make legacy application stateless.

Whilst there are ways to work around this, they all rely on ‘un-balancing’ the load balancer, and will frequently add network hops and overhead to the processing of each request. We need to be able to select a load balancing strategy on endpoints configured in Azure (i.e. round robin/sticky/performance based decision).

As a side note, the load balancing strategy for Windows Azure Websites is sticky.


Better support for Java on the Microsoft cloud goes well beyond one language, and unlocks a number of possibilities, such as better support for Ruby and Hadoop for example.

Load balancing is one pain point, but something we know they can fix in the platform.

Azure remains an exciting place for everyone from the smallest startup, to the largest enterprise.