Saas, Not Quite There Yet?

We picked up on some discussion from InfoQ on topics related to Software as a Service. We believe that Saas will be part of the underpinning that pushes ThirdPipe transport. Saas is to Visicalc as ThirdPipe is to the Apple II. Its the demand engine that pushes the ThirdPipe supply chain forward. Listen in to a few clips then we’ll regroup –

Services that are built largely from other services are a reality, and offer many clear advantages. [For instance] … by leveraging service options like Amazon’s EC2 and S3, a very small company can build a simple, narrowly focused service and can cost-effectively sell it to a mass audience.

The types of services that could be used in the creation of new services span the spectrum, from base infrastructure services to complementary high-level application services that can be composed or mashed up.

Example services include: compute and storage services; DB and message-based queuing services; identity management services; log analysis and analytic services; monitoring and health management services, payment processing services; e-commerce services like storefronts or catalogs; mapping services; advertisement services; in addition to the more well-known business application services like CRM and accounting.

And…

Eric Norlin adds:

I believe that Greg is right on the money with the idea that the very process of building a “software company” is being altered by the service-based architectures being provided by “saas infrastructure enablers.”

And…

Larry Price argues:

EC2 and S3 are amazing and cool and Werner Vogels is a rock star for having lead the team that created them; but until there is a common portability standard and multiple suppliers, the market for virtual infrastructure services is not mature.

What is part of this proposal is the development of a derivatives market in business processes. A MashUp at this level on top of virtual services is not much different that its financial cousins on Wall Street — CDO’s, CDS’s and Options. It has some of the same dangers as well –

• Subprime meltdown = S3 outage.
• Bank reserves = Capacity planning (Or the lack of as we are finding in the financial world)
• CogHead failure = Hedge fund bankruptcy*

The Larry Price quip hints at the problem, but not far enough. It was tough enough that a MashUp would go Google Maps - in-house infrastructure. But when the MashUp goes purely virtual the level of complexity in meeting 9’s quality of service requrements (if needed) become almost impossible to calculate. Not only that but for every service provider added the level of portability of the application diminishes. My ability to move my Db off of S3 to BlueCloud is reduced for every additional API that I add to my overarching app beyond simply the Db API call.

It would also be interesting to research what the cascade effects were of the S3 failure. I think Amazon should at least issue a white paper to the industry as a whole as to what the multiplier effect was. We need to know in order to be able to assess risk. Were I a VC partner I would want to know that before I plunk my money down on a purely virtual venture.

It will become quite clear to the Saas providers that a series of unified APIs based on service set will be required. They will resist at first as differentiation provides lock in. But long term the unification will occur. Committes will be formed for Db, GIS, Presentation, QoS Metrics, etc. But in the end a portable set of APIs will come to be. The development community should demand it now before we move too far down the Saas road map.

Linky
*CogHead is solvent, I am referring to the hedge risk in the underlying ’stock’. In this case S3 service.