The need for “standards for application logic” in PaaS. Really?

In his latest post on Coghead’s demise, Phil argues that:

“What this highlights is the lack of any standard for transferring not just data but application logic between such platforms.”

My argument is that those standards already exist and are widely adopted:

“Standards for capturing application logic already exist: Java & .NET (and COBOL). Coghead "mistake" was to try to develop their own development platform from scratch, instead of leveraging what already existed and provide value on top of that.”

Phil replied that:

“Doesn't solve the problem

But you still can't *transfer* logic from one development platform to another, say from COBOL to Java, or from Java to .NET, without completely rewriting it. What I'm advocating would be helpful to people developing on established platforms too. My point is that it's essential in a PaaS context.”

My response was getting too long, so I decided to post here instead.

Sure, having an abstract model for your app logic and then deciding implementation details would be great. I buy the attractiveness of such an approach and I understand why people would like this. (I’m sure it will sound familiar to my friends @ ArTech), but there’re problems too (e.g. “minimum common denominator” syndrome, lack of finer grained control, not being able to take advantage of the latest features in a given implementation, etc).

However, I certainly don’t think it is *essential* for PaaS. Nice, desirable, yes. Essential, I don’t think so.

Phil says that “With PaaS, the lack of such mechanisms could become a huge barrier to adoption as customers become fearful of which platform might be next to switch off the lights.”

True to some extent, but there are ways of mitigating this *today* without waiting for the uber-cross-platform-cross-cloud-ocean-boiling model.

Coghead could have chosen to offer app hosting for .NET and/or Java based apps (or PHP or COBOL for that matter), and attract 10,000’s of ISVs that have already bet on those platforms. Instead, they created a *new* platform from scratch. They not only required everybody to learn their new abstractions, their new language, their new tools, etc. Those by themselves are strong adoption barriers, not impossible to overcome, but quite tough.

But they also asked everybody to bet their operational business on them (the “aaS in “PaaS”), because nobody had access to their runtime except them. The lethality to the business viability is in the combination of these two factors. Platforms are catalysts, and as a consequence, they usually don’t do anything useful by themselves. They need to be bootstrapped.  

So, if Coghead had chosen say .NET (I’m biased of course :-)) as their underlying programming model, barriers of entry would have been much lower for many reasons. Among them:

• ISV would have had less cost in creating a “Coghead” solution (they would have reused all their existing skills, tools, knowledge, etc).
• The cost of re-targeting their app would have been lower in the case the hoster goes out of business. Some work would have been required anyway, but not as high as with the current model.

In this hypothetical scenario, instead of parsing the XML files, they would have a bunch of .NET (C# or VB.NET) assemblies.

Some PaaS offerings, such as Apprenda, have taken this path. In my opinion a much healthier and pragmatic path.

The other obvious way of addressing these risks is with a “reverse escrow” from PaaS providers to their ISVs: giving out the runtime to the ISVs if they go out of business. Worse case, ISVs would buy time to port the application into another runtime. (like .NET).