The scenario evolves benignly enough ( I must stress that this is a completely fictitious scenario to protect the innocent, though the scenario can and will happen in your company or sector as easily).  “Old Oaks  Inc.”  is a profitable company in Health Care Industry. Old Oaks  has so many applications,  built over half a century.  A  good percentage of the applications are built over Oracle straight up (prior to that in PowerBuilder, and so on). Old Oaks’s new IT chief decided that the new apps must be written in Java and a new set of apps were developed using Java. Some consultants were hired who sold the chief on building an “applications framework” that will form a platform to integrate all those new apps, and also to migrate the difficult to maintain Oracle applications (with most of the business logic in PL/SQL). In a couple of years, while the application framework was being built and used pretty effectively, the senior architect happened to meet some peers at a conference, and mulled over whether they should all share their frameworks. The idea was that they could have a single framework all of them could share and maintain thus reducing duplicate development effort. They managed to sell the idea to the respective managements who agreed to pony up some millions to support such an effort over a few years. The ROI for the whole effort was reduced maintenance cost, and reduced cost of code development that would work for all of these organizations even though their business processes varied in a broad range.

What are the odds for their success? Depends on how well they have understood the perils of building a product by services folks.

Once it is deemed necessary to provide a certain kind of service, IT Services Department builds and delivers the service with Relationship Managers, Business Analysts, Project Managers, and IT service implementers.  The responsibilities of these roles will vary somewhat from organization to organization, though within the services industry they are well understood. The main goal here is to satisfy the customer’s need for the service.  In the scenario above, it is interesting to note that the customer remained the same for the services, though how the services were produced  changed with a shift towards “shard/common” code. Instead using a product created by  a product company, the IT Services Department is a sponsor of a product building effort. So, what is wrong in that?

Well, from the need perspective, there is nothing wrong in the wish for a common piece of “standardized” code. However, product building process works differently than service building process. Product building requires a “Product Manager” who is responsible for defining the product features, and their availability in a particular release (in a customer visible roadmap). The other roles involved  in the services building will change somewhat, though the Product Manager is a somewhat novel role from the perspective of IT service folks. If the services folks do not  understand how the Product Manager role works and empowered  then they are doomed for a low death of the entire effort. The common piece of code will be behind schedule and every delay in schedule will be promptly blamed on the developers  (usually developers become scape goats because they produce the code, and it is too easy not to take the effort to identify the root causes).  Understanding the Product Manager’s role will also have implication on the Chief Architect’s role, and the hierarchical structure of the entity that is building the common piece of code.

At this point,  it would be important to point out that a great many other things need to be understood prior to a services organization building a maintainable  common piece of code that will be sustained and renewed over a period of time. On those things, I will blog another time.

The numbers they quoted focused on answering the question,”Is Cloud the best platform for video broadcasting?” The answer is nuanced, and to set the stage Branko analyzed some of the key aspects: B/w, storage capacity, and the data center size and cost.

It is interesting to see how the current (November 2009) viewership (measured by multiplying the viewers by the minutes watched) of You Tube compares to some of the TV programs. While You Tube is at approx 40 Billion Minutes, American Idol is at 29 Billion Minutes, and the single event SuperBowl XLIII is at 24 Billion Minutes! It is obvious that we have only scratched the surface on video in the cloud.

If the entire TV program in the US were available on the web, it would take a b/w of  1140 Tbs for High Def, and 382 Tbs for Standard Def TV! This translates to roughly 46 Tbs per DMA (Designated Marketing Region, there are 25 in USA) for High Def TV, and 14 Tbs for Standard TV. This calculation assumes there is a single provider, but obviously that is not the case, and the actual b/w needed will be a multiple of this.

Storage capacity needed, assuming a single copy storage, is also a “big number.” 20M Hrs of video content from the beginning of TV is roughly 22.5 PB, wheras the user generated content (including home movies) is at roughly 112.5 PB (assuming 100M Hrs per year).

Branko argues that the current video in the cloud is at the 1% transition point, and therefore is viable for business investment. On the question of video in the cloud – not all videos are viewed equally.  Apparently, 50% of the videos are never viewed more than once in You Tube, transcoding cost (for playing in 8 different formats) becomes an important factor.  There are two options – transcoding while uploading, and transcoding while downloading. Branko and David think that the entire TV Service of USA will cost about $50oM  with transcoding  on the upload with a dedicated system. If AWS (Amazon) is used, the cost goes up by 8 times. They advice a mixed policy that stores different formats based on demand for viewing.

Their company is looking for partnerships to bring their vision of video in the cloud a reality.

2008

September 2008:

The Proceeedings of a September Cloud Session featuring IBM, Amazon, Google, and HP are available here.

December 2008:

The  Proceedings of two December Enterprise Cloud Computing Sessions including IBM, Microsoft, HP, Cisco, and Salesforce.com on Dec 10-11 are here.

The 2008 World Summit of Cloud Computing in Israel recently posted  Video Proceedings. They also hosted an Enterprise Cloud Computing Group Session that may be repeated in 2009.
2009

February 2009:

The Open Group is hosting an Enterprise Cloud Computing Conference in San Diego, US on Feb 3.  The speakers include leaders from Amazon, IBM, Cisco, HP,  and Salesforce.

March 2009:

There could be a series of similar follow-on  international Enterprise Cloud Computing Conferences during 2009 including multiple Indian cities in March.  The scheduling depends on the local level of interest.

1. “Free” Model: Provide the software use for free but some or all of the following will apply to the user.

A. Suffer through advertisements,

B. Surrender the privacy of whatever user does at the website of the service provider, and

C. Email and any identity information shared with the SaaS provider are “harvested” and will be sold to somebody to “spamk” the user thoroughly for their thoughtlessness.

Customer Segment: Mostly individuals, or in rare cases small businesses, who are willing to take the free service. Can be mostly new customers.

2. Subscription Model. Again, the user will have to pay in one or more ways described below.

A. A pay-for-use model. Either in time based or feature based.

B. Fixed monthly usage cost with unlimited usage, or tiered and restricted usage.

Customer Segment: Primarily businesses across the board (many services to individuals have moved down to the “free” model). Smaller businesses are willing to pay a monthly fee to utilize business processes hosted elsewhere. Larger businesses that pride in their “edge’ on specific areas may be willing to use hosted business processes for their “non-core” or “non-edgy” business processes. This model is disruptive to existing on-premise software.

3. “Gifted” Model:  Not all end users pay for the service, and those who do, pay for everybody else (that is, at least for a majority of the costs).

This model is used when the businesses who pay for this service benefit from those others who do not pay. This model is mostly prevalent when the software provided as a service is to share business information/data among multiple businesses. Example: A large chip manufacturer sharing purchase orders and invoices with its (in bound) supply vendors.

Customer Segment: Supply Chain businesses – can be manufacturing, retail chain, or services.

Compare these business models to the business model for Cloud Computing Infrastructures.

In Cloud Computing, the only business model used so far has been Subscription Model. Can we expect to see either the “Free” model or “Gifted”  model any time soon?

It would be fun to speculate what would those models would look like in real world. May be a free platform to host your applications, but those applications will have the “free” model attributes mentioned above such as advertisements. The Gifted model is a bit harder- how about a free auction platform where anybody can build branded companies for public auction that compete with established giants like eBay?Is there a case to be made here for some of these types of companies?

The bottomline is this: SaaS and Cloud Computing may share at least one major business model but Cloud Computing has enough room to grow to come up with businesses that parallel the other business models of SaaS. This assuming, Cloud Computing is really “computing and storage as a service.”

The above concerns do limit the use of cloud computing in the main stream of IT for now.  We will look at enterprise applications that can use cloud computing resources right away in another post.

Meanwhile, I will certainly welcome your addition to this list!

Reduced Capital Expenditure: Using cloud platform means no physical procurement or installation of computational resources. The resources are provisioned over the Internet using a web browser, and are paid for using a pay-per-use model or subscription model. For example, Amazon charges 15 cents per gigabyte of S3 storage each month, and 10 to 80 cents per hour for EC2 server capacity, depending on configuration. According to Michael Crandell, CEO of RightScale, “Amazon is $70 to $150 fully burdened for a server, versus $400 per month for an enterprise.”

Faster Deployment of Application: The use of the Internet to do the provisioning of computational resources means time to deploy an application will be reduced. The cloud computing builder vendors provide services to make this deployment easier. For example CohesiveFT provides easy to use tools to assemble a software environment of OS, database management, and other software required to run the application and to deploy on a variety of cloud infrastructures. 3Tera facilitates graphical assembly of software components to build the software environment, and their deployment over its grid engine. Scalr and RightScale provide the same support for Amazon EC2.

Scale Your Infrastructure to Infinity (almost): Since cloud infrastructure vendors have a large collection of servers and storage, any quick need for large computing resources can be served with a few mouse clicks. This allows businesses to try out experimental applications or services that have heavy computing needs.

Inaccurate capacity planning is OK: The cloud computing platform is intended o scale at will (as stated previously), so it is possible to get extra computing cycles or storage fairly quickly.

Manage Applications Remotely: The applications that run on the cloud can be managed remotely through programmable interfaces that are exposed by the cloud vendors. Google Data APIs allow direct interaction with the applications hosted in its platform.

No Long Term Commitment: Cloud vendors do not require any long term contract from its users, which permits the users to switch clouds, or use different clouds for different purposes.

Access from Anywhere, Anytime: Since the cloud infrastructure can be accessed over the Internet, the applications deployed over them can also be accessed over the Internet from anywhere or anytime by the end users of the application, or its developers.

The above table illustrates key value propositions of cloud computing:

1. Quick provisioning of computational resources,
2. No installation or maintenance work necessary,
3. Remote management of application resources via Web-Service interfaces, and most of all
4. Paying for only what you use.

Enterprise  users will find it hard to resist the quick provisioning aspect and not having to deal with the installation and maintenance headaches, as well as only paying for what you use. Yet, I believe what truly differentiates cloud computing apart from everything that preceded it, including multitenant application hosting, and on-deman computing, is the remote management of the applications through web-service interfaces.

In cloud computing, computing resources that scale to the needs of the deployed applications are provisioned and used on-demand from cloud computing vendors, and are paid for only when used.

I want to stress the pay-for-use (no long term contract), on-demand provisioning, and scalability of computing and storage resources. The pay-for-use is not exactly what some Enterprise users crave, especially those in the IT department. Enterprises like/want a host of things, and not having to do a contract can mean total disorientation in some Enterprises! I will take up on the perceptions of Enterprise in another blog entry.

Today cloud computing seems to be situated closer to S-a-a-S, as an enabler of SaaS on the one hand, and a platform for custom applications that anybody (Enterprise user wanted!) may write. No wonder, some folks prefer to call the entire cloud computing phenomena as a Platform-As-A-Service (P-a-a-S) movement.  This is a very significant thing from the point of view of enterprise users, because it is no longer canned applications, but your own applications that are in the cloud! What does that mean? That is the big question to get an answer for.

The table below helps me to compare these in a truly apples to apples fashion.

The significant differences fall into two areas:

1. who manages the application, and
2. the contract

In PaaS vendor cannot really manage your application without owning the application itself which the enterprise created. So, the headaches of deploying and making sure the all the paths point to the right libraries, etc. never go away.

The next interesting question here is,  what exactly can a PaaS vendor provide an SLA on. On the availability and performance of the application or the availablity and performance of the platform? If the later, then how is this contract different from a contract you would ave with an external hosted applications venodor?