Blog

Java in the Azure Cloud

/in , , , , /

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.

Windows Azure PaaS vs. IaaS

/in , , , /

As a follow-on to our recent JNBridge lab showing how to write Hadoop mapreducers using .NET and JNBridgePro, we were planning to show how to take Hadoop and those .NET mapreducers and deploy them to Windows Azure. This would have a number of advantages over Microsoft’s own Hadoop-on-Azure initiative, which does not support .NET-based mapreducers written in C# or VB, but only supports JavaScript. To get this working, we had to figure out a number of things that were undocumented in Azure, and we were rather proud of what we had come up with. However, we recently scrapped this project in light of Microsoft’s announcement of Azure virtual machines. Using these virtual machines makes deploying Hadoop to Azure no different from deploying it to Amazon’s EC2, and the special insights we gained in getting the Hadoop lab to run under Azure’s previous PaaS (Platform as a Service) offering, interesting as they were, were no longer as valuable now that Azure could now be used in Iaas (Infrastructure as a Service) style.

(Don’t worry, though!  We have another cool new lab that we’re preparing.)

Our experience with Hadoop and Azure, and Microsoft’s new offering of virtual machines, has gotten me thinking about the whole Paas/IaaS conflict. It seems to me that Microsoft, when planning their entry into the cloud, was guilty of overthinking the problem. Rather than thinking about what the customer wanted, they concentrated on what they thought the customer should want. A more charitable way of putting this is that they thought about what a cloud offering should be when considered from first principles. By doing so, they thought they were trying to do the cloud right. From that, Azure got its emphasis on lack of persistent state, and robustness of the entire application even under the expectation that individual machine instances would fail and have to recycle. It was all very cool and very forward thinking, but it wasn’t what prospective cloud users wanted. What they wanted was a way to take their existing applications on which they had spent a lot of time and effort, and which were very valuable to them, and simply deploy those applications to the cloud. Ideally, no changes would be necessary, and any necessary changes should be minimal. It turned out that Amazon EC2 offered this, and Azure did not – instead, it required at a minimum major reworking of existing applications, although ideally applications should be written from scratch in the Azure style. Guess which offering the users flocked to? (Guess which offering we used for migrating some of our services to the cloud?)

It seems that by now offering Azure virtual machines, Microsoft is acknowledging that its original PaaS approach was the wrong approach for the vast majority of potential cloud users. Whether that will still be the case in the future remains to be seen, but for the near future, I think we’re going to hear less and less about Azure PaaS and writing applications for the new IaaS offering.

What other story does this remind me of?  I seem to recall that, over a decade ago, when Microsoft rolled out its new .NET platform, people asked whether their existing Java code would work with applications written for .NET. Microsoft’s response, to paraphrase, was that there was really no need for that, when one simply rewrite the applications for .NET. In other words, one should just “rip and replace.” We all know how that turned out. While .NET flourished, so did Java. Most existing Java applications weren’t migrated, and there was a substantial need for solutions that allowed .NET and Java code to work together. While Microsoft left those solutions to other providers, like JNBridge, it did abandon the “rip and replace” rhetoric and proclaim the virtues of interoperability. It’s interesting that we’re going through the same cycle again in cloud technologies.

Now that Microsoft is adding virtual machines to Azure, will this change your plans to use (or not to use) Azure? Leave a comment below!

Build 2012 Recap

/in , , /

We were in Redmond last week for the Build conference, where Microsoft offered deep dives into their latest technologies. Unlike last year, where the emphasis was on in-depth looks at lower-level technologies like Windows RT, .NET 4.5, and Windows 8 internals, this year’s conference concentrated on higher-level application-oriented APIs like Microsoft Account (formerly Windows Live ID) and Windows Store, as well as more peripheral (to us) technologies like Windows Phone 8. In fact, if we had seen the list of sessions in advance, we might have decided to skip the conference and watch any relevant sessions online (although it was nice to receive the Surface RT, Nokia Lumia 920, and 100GB of SkyDrive capacity that all attendees received). Even so, there were a number of interesting sessions that were relevant to our work on interoperability. (All Build sessions can be seen here: http://channel9.msdn.com/events/build/2012.)

There was an interesting session that unveiled details of Microsoft’s previously announced Hadoop on Windows Azure offering (now called HDInsight). Since the offering has been by invitation only, there haven’t been too many details. It’s interesting to contrast Microsoft’s approach to Hadoop/.NET integration, which uses .NET streaming but conceals it with the artful use of wrappers, with our approach of direct API calls through JNBridgePro (here and here). Each approach can be useful in certain situations.

Microsoft offered more details on their new Windows Azure Virtual Machines, which brings to Windows Azure the capabilities already found in Amazon’s EC2. Microsoft claims advantages over Amazon’s offerings, particularly in the areas of administration and automation. For us and for our users, this is interesting because it makes it even easier to create applications that use JNBridgePro and deploy them to Windows Azure. It had been possible, but there were a number of complexities in setting up and starting the applications in the cloud; now it’s as easy in Windows Azure as it’s already been with Amazon EC2. In addition, Microsoft will be offering virtual machine images containing BizTalk Server 2010 R2 CTP, and you will be able to use JNBridge’s JMS adapter for BTS with those images.

A talk on the evolution of .NET covered both the history of the platform, including all of the earlier milestones, and possible future directions in which the platform can go. The speaker made the very interesting point that the typical PC of 1998 (when the .NET project began) or even 2000 (when it was unveiled) is very different from the typical PC of today, in terms of processing power, memory and storage, user interface, and connectivity, and any future .NET implementations will need to reflect that. We can only wonder what that will entail, but it’s encouraging to learn that Microsoft still considers .NET to be an essential platform for their future offerings.

One of the more surprising things we learned had to do with Windows Phone 8, which we really hadn’t been tracking, since it didn’t seem relevant to our mission. Windows Phone 8’s runtime is actually a version of the .NET CLR called CoreCLR, which is really based on the existing SilverLight CLR. We haven’t supported SilverLight, both because of its slow adoption, and because it has been constrained in what it can do, but we were interested to learn that in response to requests from developers, the CoreCLR will allow Windows Phone 8 applications to access existing native (read C++) gaming engines. Since Java Runtime Environments are also native C++ libraries, does that mean that a JVM can be hosted in a Windows Phone 8 app’s process? If so, it might be possible to support shared memory interoperability in Windows Phone 8 applications. It’s certainly something we’ll be looking into. Will it be possible to do something similar in Windows 8 “Metro” apps? That remains to be seen.

Did you attend Build, or watch sessions online? If so, did you see something that you’d like to call our attention to? If so, please let us know in the comments.