6 Comments

Summary:

As major PaaSes like Microsoft Azure, VMware Cloud Foundry and Salesforce.com’s Heroku race to embrace multiple languages, a few like Apprenda say that’s exactly the wrong approach. Language-specific PaaSes are better able to exploit a company’s native applications and features, says Apprenda CEO Sinclair Schuler.

6511141237_78c65140da_z

Apprenda CEO Sinclair Schuller

Among platform as a service vendors, the race is on to embrace as many programming languages as possible. Microsoft Azure, VMware’s Cloud Foundry and Saleforce.com’s Heroku all proudly claim language (and framework) agnosticism.

But that isn’t necessarily a good thing, argues Sinclair Schuller, CEO of Apprenda, a PaaS vendor that has taken a distinctly different approach. Clifton Park, N.Y.-based Apprenda has chosen to fully embrace — and exploit — the Microsoft-centric .NET world, not the rest of the programming universe. Boiled down, his view is that any PaaS that professes to be a jack of all trades is truly a master of none. He said:

“On the surface, it sounds utopian to say one platform covers everything. But we find it doesn’t work. If you’re trying to bridge lots of stacks with CloudFoundry or whatever, you have to focus on the common value across all of them and let’s face it, Java, .NET, Ruby, PHP, are all very different from each other.”

Apprenda has some big-name customers, including Diebold and Honeywell, building private PaaSes with its tool. “What typically happens is when a customer goes to implement a PaaS, as soon as their different [in-house] stacks deviate, there’s a problem. If 50 percent of their apps are .NET, a specialized .NET PaaS can exploit those apps fully while a multi-language PaaS cannot,” said Schuller.

While Apprenda is fighting the crowd, it’s not totally alone. Cloudbees proudly declares its focus on Java/JVM-based applications.

A Java-focused PaaS will better suit a customer’s native Java applications and features, said Cloudbee’s CEO Sacha Labourey via email.  And then there’s the service component of the PaaS. Labourey wrote:

“By using a PaaS, you are not just outsourcing the entire management and monitoring of your stack to a third-party provider, this vendor also becomes your place to go whenever you need help in understanding what’s going wrong with your application, why your transactions are failing, why some strange exceptions are showing-up, etc.”

To be credible, the PaaS vendor needs deep expertise in that customer’s preferred language and framework — a PHP or .NET expert won’t be much help troubleshooting a Java issue.  “Today, I know of very few companies that have the depth to help customers understand very hard problems, on all possible languages. The bottom line is that a number of polyglot PaaS solutions out there are more akin to dignified generic hosting solution than a real ally through the ups and downs of your application lifecycle, ” Labourey added.

Apprenda’s Schuller probably couldn’t agree more. He said his customers — like most businesses — run a ton of Windows applications. Apprenda’s appeal to them is that it can put those on-premises applications into the SaaS realm because of its Windows DNA.

If you forced him to choose a second language to support, it would probably be Java, he acknowledged. “But our goal is to focus on Microsoft and Azure and just be really great at that.”

Feature photo courtesy of Flickr user Jian Awe

You’re subscribed! If you like, you can update your settings

  1. I disagree, having a polyglot PaaS allows development companies to choose which language they want to deploy. From this the PaaS provider can land more developers and hence more revenue. From what I see having a single language PaaS is more of a failing of the company providing the platform as they simply have not designed the platform to be open to different development paradigms. Lets say .NET goes away / goes out of fashion where does that leave Apprenda, quite simply without a language and developers. Not a good model.

  2. I think there’s also another point here. If you’re an enterprise, you are bound to have a multitude of technology stacks. It is safe to say that there are very few applications that actually look alike or use the same stack. That’s why single-stack PaaS offerings will not cut it for most of the existing apps. Most of the organization out there are more concerned about how to on board their existing apps to a cloud environment, and only then how to make new apps easier to deploy. Therefore the polyglot PaaSes do make sense. But they too would probably not fit most of the apps out there, and are pretty hard to extend if you do want to support something new.
    The approach we took with the open source Cloudify project (www.cloudifysource.org) is to allow users to use any cloud and any technology stack using a mechanism called recipes – think of it as a Chef Cookbook for describing an application (its components, how to monitor them, when to autoscale, etc.). That way, introducing new stacks is very easy, much like writing a Chef cookbook (you can actually use Chef for the configuration stage).

    (Disclaimer – I work for GigaSpaces, the company behind Cloudify)

  3. [disclaimer: I work for VMware and I'm a Developer Advocate for Cloud Foundry]

    I’ll just make a couple of points in this discussion.

    1. Cloud Foundry as a platform doesn’t just tout language and framework agnosticism (more are being added all the time both on the hosted cloudfoundry.com and through partners contributing to the cloudfoundry.org codebase) – it also offers IaaS agnosticism. That is very powerful – you’re not locked in to a particular vendor or OS platform stack – you can move between them. Worth a mention in the context of this article, I think. CF is now deployed on vSphere, EC2, and is beginning to be supported on OpenStack etc – pretty neat.

    2. Applications themselves may be made up of multiple pieces, and the point of a polyglot PaaS here is to offer flexibility for developers, the choice of the “best tool for the job” as such – as well as recognising the new models of interaction. So we have services like RabbitMQ, and well-formed and understood REST APIs, which enable us to communicate both within a specific cloud, and between clouds. I think that’s very relevant too. You’re simply not locked in to a single cloud that is in some way “less tuned” for a language or framework – use the best of the worlds that suit you!

  4. [First off, my primary employer right now is Tier 3, I also do work with New Relic (APM), Cloud Foundry (It is an OSS Project, join in), a host of other OSS Projects and regularly work with T-1 Level financial entities all the way through to regular LOB apps for companies like Bank of America, Citigroup, Fidelity or Russell Investments) <- just to keep this comment honest & open. So…

    Simple fact and I know there are others out there like me.

    When I walk into an Enterprise gig (which I've done more than once) the first thing I do is remove communication barriers and technology barriers. Having a PaaS is a plus, having a PaaS that doesn't limit what I can use for deployment of applications is an even bigger plus.

    I often talk to or work with enterprises these days and regularly push these companies to use the things that will help them leap forward. Not sit on their laurels. If they want to blog, I make sure they don't try to go the "not invented here" route. I'll get them to deploy WordPress. If they're pushing for new prototype application development in a "Innovation Lab" I'd push for Ruby on Rails or Node.js + Express.js, not Java, .NET, or other overtly heavy frameworks. If there is an entrenched dev team that uses Java or .NET and needs to build a complex application, then I want to be able to utilize those frameworks. If a company has limited itself to one framework for everything, refusing to step outside of that, I generally won't even offer to help until they open up to the wide world of solutions out there.

    In the end, with all these frameworks, there's basically several public PaaS Solutions that work, and then there is CloudFoundry enabled PaaS Solutions. The offerings are all robust. There's no reason to stay limited.

    Summarized:
    To stay competitive, stay open.
    To innovate, don't limit choices.
    To compete, innovate, and lead, keep all the options on the table, always.

    I dig the Apprenda Solution, but to keep the above ideas alive and solid, I'd absolutely have to pair it with something else to keep a company competitive, innovating and leading the pack.

    1. Diane Mueller Adron Monday, June 4, 2012

      [yet another disclaimer: my employer is ActiveState and I work on http://activestate.com/stackato which a Cloud Foundry-based PaaS solution]
      It’s all about choice – not just languages, frameworks but PaaSes as well. As Werner Vogel of Amazon fame has said – “let a thousand platforms bloom” – and whether enterprises choose a polyglot or niche-specific or platform-specific PaaS will be dependent on that enterprise’s needs. The key is not to get locked into one vendor’s solution and choose the one that maximizes your applications portablity. Standardization is slow in coming, but groups like OASIS TOSCA are working on solutions. We should embrace the diversity rather than argue about which variation is the best. A good PaaS will enable your application regardless of language to run on any cloud. It’s not just about which languages or frameworks are supported, it’s about being able to run on any cloud.

  5. The comments are not addressing Sinclair’s main point. Polyglot PaaS technology today does not deliver tight integration with language container semantics. The PaaS connectors today (e.g. DIY Cartridge

Comments have been disabled for this post