Java on Windows Azure Roundup

06 November 2010

Introduction

I've been working with a number of customers, predominantly independent software vendors (ISVs) helping to migrate Java applications to Windows Azure.

There were some interesting Azure announcements at the Microsoft Professional Developers Conference (PDC) last week, so I thought it was time to give my perspective on the current state of Java on Azure and share some thoughts on what's coming.

The Story Today

My interest in Java on Azure started with Steve Marx and his Does Windows Azure Support Java? blog post and conference talks (still well worth exploring).

I haven't seen many "File > New > Java Azure" applications being written. Java people usually have an existing stack that they want to migrate and extend for the cloud. Often the application represents hundreds of man years of development and is tested on platforms ranging from Solaris through to AS/400 and Windows. Being cross-platform, these applications aren't about to start accumulating Azure specific features (at least not without a plugin architecture). I think that platform compatibility and bootstrapping tools are more important than developer tools per se.

The good news is that most Java applications are, by their nature, XCOPY deployable. Getting them packaged and uploaded to Azure is usually straightforward. Running them is the fun part.

Microsoft still seems to be promoting the Windows Azure Tomcat Solution Accelerator, but in the immortal words of Harry Enfield, "You don't want to do it like that." AzureRunMe is arguably a better starting point. It's general purpose and extensible; you don't have to keep uploading wedges of JVMs and app servers every time you want to change something.

The Windows Azure platform is well-designed, open, standards-based and interoperable from just about any platform with a TCP/IP stack. If you want to use Windows Azure specific features, then the Windows Azure SDK for Java is a good choice betrayed by a confusing web site. You might like to jump straight to the Sourceforge download.

There is an Appfabric SDK for Java Developers.

We have a Log4j appender for Windows Azure.

You might want to look at the Windows Azure tools for Eclipse, but do yourself a favour and buy Cloud Storage Studio too.

What are the Snags?

If you want to use JDBC to SQL Azure, then good luck. You might get away with it, but there are problems with connection timeouts and some reports of bugs due to SQL Azure / SQL Server differences.

You're only allowed 5 ports in your service definition. Many Java stacks use ports liberally for everything from JMX, JCA, clustering etc. Configuring these ports at runtime, whilst achievable with a bit of Sed Fu, is a bit of a pain.

If you're using non-blocking IO with java.nio, then you're probably going to hit trouble. For example, Apache DS and Jetty are both problematic, depending on their configuration.

You can't use the loopback adapter, so you need to beware when configuring IP addresses.

It can be a little challenging to build hybrid on-premises/cloud solutions although PortBridge is your friend.

The Java News from PDC10

The headline: "Improved Java Enablement: Microsoft plans to make Java a first-class citizen on Windows Azure. This process will involve improving Java performance, Eclipse tooling and client libraries for Windows Azure. Customers can choose the Java environment of their choice and run it on Windows Azure."

Virtual Machine VM Role will be a catch all solution so that we can say, "If it runs on Windows it'll run in the cloud". I don't advocate Infrastructure as a Service, but for pesky applications that violate the Azure Platform as a Service model, it's a nice fall-back position. It will also solve problems with unhelpful vendors who won't support their software in Azure because it's not a recognised build of Windows.

I'm more interested in Elevated Privileges than the VM Role because it should allow us to do installs, registry hacks and file system permission changes without sacrificing our Platform as a Service ideals. Presumably we will be able to use this to make registry setting changes to reconfigure the JDBC driver and work around problems or install a specific version of the C++ runtime for example. It's not yet clear to me whether this will enable us to run Windows Services, but I can't see any reason why not.

Extra Small Compute Instance should be a great way for cash-strapped developers to experiment with Azure. I hope that my own monthly Azure bill will now be lower than my hotel bills on future expenses claims.

Our WindowsTelnetDaemon was only ever meant to be a tactical fix, I'm looking forward to deprecating it in favour of Remote Desktop access. I hope that debugging Azure apps will become a lot less like remote debugging a Mars Rover.

The ability to dynamically take instances off the load balancer for debugging will be useful.

The improved Azure Platform Management Portal looks clearer and there is support for multiple users and roles. I'm disappointed that it appears to be Silverlight only which limits the Java / open platform story. I'll no longer be able to control my Azure instances from my iPad.

Azure Connect (formerly Project Sydney) will probably deprecate PortBridge for Azure scenarios and will make it much easier to build hybrid on-premises/ cloud solutions. I expect it to open up many enterprise consolidation scenarios.

Open in the Cloud

Vijay Rajagopalan gave an interesting talk Open in the Cloud: Windows Azure and Java and demoed the Fujitsu InterStage Java app running on the forthcoming Windows Azure SDK 1.3. There were some interesting clues in the demo.

The Eclipse tooling and packaging support looked good, but it's not a high priority for me. I think it will be tough to support a wide range of application servers and versions this way. Java developers are usually smarter than the average bear and will want to do their own thing, so having them manually ZIP up their frameworks and supporting tools for upload to Blob Storage isn't a big deal.

It appears that the CSPKG file still contains the Java Runtime and App Server making deployment across low bandwidth (rural home broadband!) connections too time-consuming. Dynamic web site updates through Tomcat looked promising.

Support for remote debugging looks good too, although that's pretty easy to achieve yourself using JDWP. You also need to be very careful about security (you don't want Script Kiddies attaching their debuggers to your app!). Again PortBridge is your friend in the short term, and Azure Connect will be the strategic answer.

Windows Azure 1.3 SDK will fix the Java NIO issues and enable the loopback adapter.

Looking at the Fujitsu configuration file, it appears that you'll be able to specify a "localPort" attribute to an EndPoint, so we won't have to worry about port remapping to 20000 20001 etc. in the future. It appears that the 5 port limit has been relaxed too?

I'm looking forward to checking out the support for the Windows Azure Management API in the new Windows Azure SDK for Java.

Other Thoughts

Unfortunately there was no official news, as far as I could tell, on JDBC to SQL Azure fixes?

I didn't hear much about the developer fabric which is too different to production reality to be useful for Java development scenarios. I'd still like a Virtual-PC-like solution that mirrors what's really running in Azure.

I've been playing with HyperV in anticipation of custom VM role, but it's more suited to servers than developer machines and laptops (issues with driver support for graphics cards in Windows Server 2008 etc). It would be nice if there was a more developer friendly solution using Virtual PC, but as far I can tell that's 32 bit only and therefore won't be suitable for building Azure custom VMs? VMWare support would be helpful, but I guess that's pretty unlikely.

Summary

There is now real commitment by Microsoft to Java on Azure. Some of the dates are a bit hazy, but the future looks bright, easier and more certain.

Java on Azure can work very well, and this is proving to be a more popular scenario than many of us would have guessed.

There will still be a role for AzureRunMe and we're aiming to continue to maintain, extend and support it.

Thanks Microsoft, we spoke, you listened and responded.

Of course this is also good news for Clojurians.