Non-standard PaaS – The Software Industry’s Rubber Stamp

Mar 2, 2009 by Sinclair Schuller

Coghead’s departure from the PaaS world sparked plenty of interesting debate. One small debate that caught my attention started on Phil Wainewright’s post about Coghead’s demise with a comment by Microsoft’s Eugenio Pace, which then spilled into a post Eugenio wrote here.

To give a brief synopsis, Phil argues that Coghead’s demise and the subsequent stranding of customers highlights the need for a “…standard for transferring not just data but application logic…” The argument stems from the fact that Coghead customers could not easily migrate their applications to another platform, potentially setting those folks back by months of development time, but more importantly, possibly having to throw in the towel on their applications if Coghead goes offline before they manage to perform the migration. Eugenio replied that such a standard essentially exists through standard technology stacks like Java & .NET and that if Coghead was anchored around one of these substacks, customers would not be stranded. He [Eugenio] went on to say that a “standard” was not essential. Phil responded with the following post over at eBizQ.

It’s probably of no surprise to readers that I’m siding with Eugenio on this one. First, let’s clear up some definitions. Let’s call well known development platforms like .NET, Java and Ruby to mention a few ’Standard stacks’. Standard here is being used to describe wide use and general acceptance: that is, I can walk into a development shop and drop one of those names, and engineers either work on that platform regularly or are very aware of its existence. Let’s refer to everything else as ‘Non-standard stacks.’ Something like Coghead or Caspio is definitely ‘Non-standard’; outside of the SaaS choir, few have heard of them. Note that I’m refraining from using words like ‘proprietary’; being proprietary is ok if you’ve achieved a gold standard status in the industry. 

Complex Apps Need Expressive Runtimes

First, a root problem of Non-standard stacks is that they do not Stand on the shoulders of giants. They attempt to re-invent full stacks but fail miserably. I’d be ok if these platforms focused on helping business analysts, casual developers, etc. but they all claim to solve the ailments of ISVs and software engineers. This is simply not the case. They are far too restrictive to be general purpose and solve complex issues. Stacks like Java, Ruby and .NET are unbelievably expressive. It’s like handing Michaelangelo a rubber stamp instead of a full set of paint and brushes: I’m sure he could have done something at the Sistine Chapel with a rubber stamp (see title), but it would look nothing like what we have today. For example, what happens if someone wants to build an audioprocessing application on Coghead (or an equivalent) and deliver it as SaaS? It can’t be done. The expressiveness required for this sort of endeavor is beyond any current Non-standard stack for SaaS. Clearly, .NET, Java and Ruby can support this endeavor. Now, build a Non-standard stack with the expressiveness of the ‘antiquated’ stacks and it has a fighting chance!

A Standard Probably Won’t Help

Assuming one is ok with the limited stack and understands that they will function in a small corral, then the discussion moves to ‘lock in/lock out’. The whole conversation stemmed from the idea of ‘lock-out’ experienced on Coghead. Yes, having an intermediary ‘logic standard’ would have prevented lock out. I can appreciate Phil’s desire for a ‘kill all’ logic standard, but it’s quite impractical, almost impossible to implement correctly, and wouldn’t eliminate the ‘lock in/lock  out’ problem. Eugenio really hit the nail on the head with some of his comments regarding “minimum common denominator syndrome” (the fact that a standard has to be the baseline and expose only control mechanisms that are common across translation targets) and the fact that each implementation can innovate atop of the standard, but this is hidden from the standard. Most folks want to take advantage of innovation, but if you do and you live in standard world, you’ve now re-locked yourself. It seems that it doesn’t really solve the problem, only pushes the boundary out into the world of mediocrity. Many moons ago, I was a Java architect and  also worked as a .NET architect. I can assure you that even in similar stacks, the idea that the ‘logic’ could be captured generically in a standard is difficult to swallow. For the sake of making a point, imagine writing an audio processor delivered as a SaaS application in this generic standard (XML or otherwise). Next, what happens when rogue group X doesn’t like the standard? They’ll define a competing ‘standard’ of course! This never happens in the dev industry…

If you’re locked into Java or .NET, yes, in agreement with Phil, it’s still lock-in, but not anywhere near as bad as lock in to a non standard stack. Locking to a standard stack provides some sense of ubiquity with a max downside of having to figure out where and how to run your IP, and how to fill the gaps left by the now done platform. Lock in to a non-standard stack means a downside of disaster.

The Better Way

At Apprenda, we chose to implement a real multi-tenant, SaaS commercialization and architecture platform ontop of a giant – .NET, and allow those writing apps to leverage this. This gives you a certain amount of mobility and ubiquity, and defers SaaS architecture and commercialization issues to the platform. In SaaSGrid’s case, we treat SaaS like a cross-cutting concern, which leaves most of the application to it’s own concern. This ensures that lock in/lock out is minimized and the application can actually function somewhere other than SaaSGrid, but when in SaaSGrid it runs fully as a service. I think Eugenio’s point that this design seems much more reasonable and would have helped ISVs with application from simple to complex deal with the disastrous Coghead outcome. This is very different to Phil’s examples of Heroku or Engineyard for Rails.

The SaaSBlogs group on LinkedIn now has 1500+ members and it’s growing every day; make sure you are not missing out and join today.