Comments on: Is multi-language PaaS really better? Not necessarily

By: Diane Mueller

Diane Mueller — Tue, 05 Jun 2012 01:40:44 +0000

[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.

By: cobiacomm

cobiacomm — Sat, 02 Jun 2012 15:20:45 +0000

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

By: Adron

Adron — Fri, 01 Jun 2012 18:28:10 +0000

[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.

By: Andy Piper

Andy Piper — Thu, 31 May 2012 22:27:42 +0000

[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!

By: uri1803

uri1803 — Thu, 31 May 2012 15:02:53 +0000

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)

By: John

John — Thu, 31 May 2012 01:29:03 +0000

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.