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!