Engine Yard on Windows Azure? Yup, You Read that Right

Lost in the outpouring of interest about last week’s announcements between Oracle and sometime enemies Microsoft, NetSuite and Salesforce was an interesting piece of news – that Engine Yard was going to begin supporting Windows Azure. This is kind of odd – Azure is arguably one of the most PaaS-like infrastructure plays, while Engine Yard has done a good job of supporting as many different languages and frameworks as possible. Add to that the fact that oracle is a large investor in Engine Yard and we have a significant amount of head scratching about this deal. According to the release:

Engine Yard and Microsoft are delivering a commercial grade, open source based platform on top of on-demand infrastructure that is ideal for developers and IT professionals at start-ups, small and mid-sized businesses, and large, global enterprises.

When it becomes available at the end of July, Engine Yard will be offering its application automation and orchestration to Windows Azure. Alongside that they’ll roll out an enhanced user interface, as well as a new cluster model – supporting applications, databases and load balancers – for faster provisioning, configuration and deployment. So customer who want Engine Yard’s PaaS but are committed to Azure as their infrastructure of choice, can now combine the two.

It’s kind of a strange deal – from Microsoft’s perspective it’s an admission that customers want to use Ruby and other open source languages and frameworks – and by extension an admission that Azure’s own PaaS offerings don’t cover off all use cases. From Engine Yard’s perspective it’s acceptance that Azure is a credible platform and that their customers are eager and willing to use it. In terms of how it works, enterprises will be able to purchase Engine Yard PaaS as an add-on from the Azure Marketplace, making it convenient to use new or existing Windows Azure credits.

MyPOV

For Microsoft it’s a nice way to look flexible and appealing to developers who use open source tools. For Engine Yard on the other hand it’s a good way to move ahead of Heroku and open up the PaaS functionality to other hosting arrangements – as such it’s a mid point between, for example Heroku (public PaaS) and the fully private PaaS providers like Apprenda and ActiveState (disclosure, I’m an adviser). It arguably gives them the benefits of both – flexibility in terms of location, with their platform of choice. Of course others would argue that it’s the worst of both the public and private PaaS approaches.

To be honest I don’t see a whole lot of uptake of this – it’s a nice marketing coup and gets both companies a little more air play, but the intersection of developers wanting to use Azure and those wanting to use open source languages within an Engine Yard PaaS is, I suspect, a very small one. Time will tell.

2 Comments
  • Ben, Windows Azure already has Ruby support without EngineYard.

    see http://www.windowsazure.com/en-us/develop/ruby/

    As Azure already supports Ruby and open source frameworks, the comment “Azure’s own PaaS offerings don’t cover off all use cases” may point to flaws in the Azure PaaS model that go deeper than straight Ruby support.

    EngineYard adding advanced load balancing and clustering to Ruby on Azure points to PaaS capabilities that go beyond simple polyglot support.

  • This is a small BUT huge step coming from Microsoft building a great cloud platform that support all variety of software platform for developers. MS quickly become one of the cloud allstars together with AWS and Google

Leave a Reply