In 2000, Microsoft announced that it is building a brand new runtime and a framework called .NET. At the heart of .NET was the Common Language Runtime (CLR) designed to execute an assembly like language known as Microsoft Intermediate Language (MSIL). This was at a time when Sun was trying to lure the developers away from Microsoft Visual Basic and Visual C++ to their flagship Java platform. It was not just Microsoft but an array of language and platform players were seriously threatened by Java’s dominance. Microsoft realized that supporting more languages on top of .NET could bring multiple vendors to join them in challenging Sun. So, Microsoft created a standard called Common Language Infrastructure (CLI) and submitted it to ISO and ECMA. Along with it, Microsoft started engaging with Fujitsu, ActiveState and academia to bring COBOL, PERL, Fortran, Python and even Java to the .NET platform. Microsoft .NET looked similar to Java in its approach of creating a runtime (CLR), libraries (.NET Fx) and language (C#). But Microsoft’s game plan was slightly different than just creating a platform that looked better than Java. Microsoft wanted to downplay the significance of a language by elevating the power of mature framework and a high performance runtime. Microsoft hoped that by on-boarding developers from diverse environments, they could become the de-facto platform for deploying applications. As one of the early .NET evangelists, I vividly remember demonstrating how to build a web application by assembling components written in half-a-dozen languages (I actually wrote an ASP.NET Web Form in COBOL!).
In the mid 2000s, Sun made it possible to bring language bindings like Clojure, Scala, Groovy, JRuby, Jython and others to Java. The community received this well and subsequently brought more languages to the Java platform. Now that it’s been more than a decade since the announcement of .NET, we can take a stock of things! The fact remains that C# happens to be the only language that majority of the developers use on .NET. Unfortunately, Visual Basic, a language that enjoyed loyalty among Microsoft developers, became a second-class citizen on .NET and thus forced all the VB developers to move away from the MS stack. All other languages that Microsoft’s evangelists showcased were only confined to the demos. So, effectively Common Language Runtime (CLR) and Common Language Infrastructure (CLI) are reduced to a couple of languages (or is it just C#?) from Microsoft stable.
How is this relevant today when the platform battle has shifted to the Cloud in the form of PaaS? From the time I read VMware’s strategy for Cloud Foundry, I started to relate it with Microsoft CLR. Just like CLR, VMware did not just build a PaaS, it actually built a meta PaaS! If CLR was designed to run multiple languages as a meta platform, Cloud Foundry is designed to host multiple platforms as a meta PaaS. If Microsoft submitted a subset of .NET specifications to ECMA and ISO and called it Common Language Infrastructure (CLI), VMware had actually turned Cloud Foundry into an open source project and put the code on github. If Microsoft attempted to reduce the Java impact by gaining support from Fujitsu and others, VMware is working with major players in the Cloud ecosystem to offer a PaaS stack powered by Cloud Foundry. Just like .NET is the implementation of CLI/CLR from Microsoft, VMware has the commercial implementation of the project as CloudFoundry.com. It is just that Microsoft is now at the receiving end with Windows Azure. VMware’s smart move came in when they enabled Tier 3 and Uhuru to announce .NET based PaaS powered by Cloud Foundry. Ironically, both Tier 3 and Uhuru Software are founded by ex-Microsoft employees.
I tried compiling a list of current PaaS offerings powered by Cloud Foundry –
[table id=1 /]
Cloud Foundry is not a threat to just Microsoft, it can challenge Heroku, Engine Yard, Elastic Beanstalk, Apprenda and Google App Engine. I believe that Cloud Foundry will commoditize PaaS market by enabling many low-end hosters in becoming a polyglot PaaS vendor. By optimizing Cloud Foundry for Private Clouds running on VMware, it may lead the Private PaaS paradigm in enterprises giving a huge upside to VMware.
As the leader in the node.js community, I am waiting for Joyent to announce their own node.js PaaS powered by Cloud Foundry. Joyent currently offers a SmartMachine for node.js but that is not a true PaaS.
Will VMware see success with Cloud Foundry through its meta PaaS strategy or will it meet the same fate as Microsoft’s CLI? Let’s wait and watch!
- Janakiram MSV, Chief Editor, CloudStory.in
Want to make your startup journey smooth? YS Education brings a comprehensive Funding Course, where you also get a chance to pitch your business plan to top investors. Click here to know more.