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

Comments

• Anonymous
  February 24, 2009
  PingBack from http://www.clickandsolve.com/?p=14041

• Anonymous
  March 07, 2009
  You're certainly correct in saying that if .NET had been the development medium at Coghead that their demise would've been far less traumatic for their users, but I think you're overlooking the fact that from Coghead's perspective that also would have left little to prevent clients from being able to pick up and move on whenever they felt the whim. It's also possible that they may have looked at it this way: If all that Coghead offers is yet another .NET development platform, then how do we differentiate our product from buying dedicated Windows server hosting at GoDaddy? In a sense, the more that you reduce the risk of "lock in", the less you make SaaS products seem any different than just developing your software in house and hosting it online on a dedicated server. Of course there are real practical differences, but IMHO Coghead might have worried that if they provided a "bare metal" .NET development platform without any "value add" (value being in the eye of the beholder) it would (in their eyes) have greatly diminished what they had to sell.

• Anonymous
  March 09, 2009
  The comment has been removed

• Anonymous
  December 13, 2009
  You can argue that Coghead tried to do to much all at one, used the wrong technologies, However, they provided an accessible path for non-traditional developers to "roll their own" database application. You don't get that if you simply expose these non-IT "developers" to a .NET platform.   I once consulted for a company that transitioned  between a decentralized and a centralized IT model.  The centralized IT group wasn't staffed or budgeted to respond 'quicky' to departmental requests, as the old 'decentralized' model was. Since the 'technical' people in the individual departments weren't happy with the response rate for new requests, they started developing applications using Microsoft Access, with no involvement or even guidance from IT. So Coghead seemed like a fruitful avenue to explore, because you could develop those "ad-hoc" applications and still get your data in and out of the platform. I'd never commit a client to any "cloud" computing platform without a formal contract with code escrow provisions, otherwise you risk your business on the whim of the company decision-makers when someone like SAP wants to hire away your engineers or otherwise acquire your IP, reduce competition, etc. This had already happened with "traditional" software firms, when ADP acquired Golden Gate and terminated their customer contracts.