PaaS is language specific?

Recently I've been involved in some discussions with people on the subject of PaaS and specifically how the application language impacts it. I was surprised to hear (or read, since some of this was via email) several of the participants assume that you would need a PaaS implementation for each programming language. So that'd be a Java PaaS, a Ruby PaaS, presumably a C++ PaaS and maybe even a COBOL PaaS.

In my most diplomatic manner, I asked if certain individuals had missed the last 20+ years of middleware development; perhaps they had been stuck on some island somewhere, or maybe off on some rocket traveling close to the speed of light and while we experienced 20 years, for them only a few days have passed. See, I do like to give people the benefit of the doubt where possible!

The idea that we need to have a PaaS implementation for all possible programming languages out there (or at least those that may be used in the Cloud), is ridiculous. Think of it like this: if we can virtualize away the hardware, so it's really no longer a major issue in deployment, then we should be able to virtualize (abstract away) the infrastructure upon which the applications will rely. And yes, that infrastructure is middleware.

Oh wait ... we've done this before. Several times in fact! I won't cover them all, but let's just consider a couple of the obvious examples. First, CORBA, where services could be implemented in a range of different programming languages (e.g., C++, Java and even COBOL!) and made available to users that may be written in a completely different language. Second, Java, and specifically J(2)EE. Like it or not, despite the write once run anywhere message that came with Java, many vendors and users simply did not want to, or could not, discard their existing investments in other languages and so found ways to integrate services and components written outside of Java and often without the knowledge of the end users. For instance, there are non-Java transaction services that are integrated into application servers through the JTA. The same goes for JMS.

As an industry we have decades of experience in virtualizing the middleware layer. It doesn't matter if you're writing your applications and services in Java, Ruby or something else entirely: as long as someone provides a binding to the underlying middleware capabilities, you don't expect, and shouldn't be interested in, whether or not the middleware, or PaaS, is implemented in the same language. And in fact it shouldn't be. I'll keep saying this, but we simply cannot afford to stop the world and reinvent the middleware wheel for PaaS. We need to evolve, but we really don't need to start from scratch. I think I got my message across during the aforementioned conversations, but maybe next time I'll resort to drawing some diagrams, perhaps even with some timelines dating back to the 1960's!

Addendum: In case it wasn't clear in the above, of course there will need to be a language specific component to PaaS, but only that which is sufficient in order to allow the underlying implementations (written in whichever language is appropriate) to be interfaced with the application or service. Consider the JTA and JMS examples above.