Video in the Cloud raises a set of issues related to whether video delivery, and contribution for that matter, belongs in the cloud or in the content delivery network. 

How does content delivery relate to cloud computing?

Recently Sanjeeve Putal with Micosoft Developemnt Team said that Akamai has been in the business of cloud computing from the start; it just wasn’t called cloud computing at the time. 

While Akamai and many other companies are fighting for position during this hype sector of cloud computing, there is some truth to Akamai’s claim. 

They do provide clients with network access to a seemingly dedicated content delivery environment that actually runs on the shared resources of a large distributed system. 

Moreover, Akamai has been developing its “edge computing” capabilities for the last several years.

With the introduction of Web Application Accelerator in 2005, and their partnership with OpSource, earlier in 2009, they have attracted an impressive Software-as-a-Service base. 

However, unlike cloud computing, the client has limited direct access and control to the environment that is hosting their application.

Meanwhile, Amazon launched its content delivery service, CloudFront, in November 2008 [6].

The need for content delivery networks comes from low supply and tie ups in long haul transit capacity. 

With communications technology continuing to advance on multiple fronts — the abundance of dark fiber, the number of lights per fiber, the transmission rate per light, and switching capacity — the changing fundamentals of scarcity and congestion are driving a considerable drop in bandwidth prices. 

Thus, while Amazon and other cloud services providers are moving toward the edge of the cloud by adding content delivery capabilities, Akamai and other CDNs are moving “up the stack” by adding more value added services.

These events beg the question of what distinguishes cloud computing from content delivery and whether current distinctions are sustainable, and how cloud computing and content delivery might merge.

It is deceivingly intuitive to separate cloud computing and content delivery, but this is a “looking back” historical effect. 

There is nothing particularly natural about transporting your application’s content and functionality from a cloud environment to a CDN environment simply for the purpose of providing access to your application.

It is more natural to think in terms of simply enabling access to an application. 

When the separation is looked at from the application provider’s perspective, there is typically no single place in a workflow where a handoff of functionality to a CDN is an obvious or easy thing to do. 

Even develop-then-publish workflows have detailed cycles (e.g., modify, test, operate, monitor, report, analyze, modify, …) where the handoff to a CDN inherently hinders the timeliness and agility of the workflow.

A classic architectural thought experiment sheds light on the situation. 

In a world where processing and delivery (access) are not partitioned, you can set up whatever workflow makes sense for your situation and it can evolve over time. 

The reverse is not true: In a world where processing and delivery (access) are partitioned a workflow and its evolution are constrained and dependent upon the content delivery interface.

Things get more complicated when the functionality handed off to the CDN is more than just content. When the handoff involves interaction, transaction, and other computational elements, then interoperability becomes a major concern.

A related complication occurs when transfer or handoff of functionality occurs among multiple divergent platform-as-a-service environments.

Users have to take care not to end up in a situation where it is prohibitively difficult to port their functionality to other service providers or to pull the functionality back into their own data centers.

The ability to gracefully “pull back” functionality from the cloud was an important point highlighted by multiple panelists during the panel on The State of Startups using Cloud Computing.

Amazon and emerging cloud providers have the opportunity to create non-partitioned seamless environments in which access to an application’s functionality and content is part of the cloud.  Instead, the introduction of CloudFront seems to perpetuate the distinction between cloud and CDN. 

While perpetuating the current trajectory seems simple and noncontroversial, this is only the case for classes of functionality that are not harmed by the distinction. Video functionality, in particular, is constrained by the distinction.

The stage is set for border skirmishes between cloud computing and content delivery, where cloud providers encroach on content delivery, and content delivery providers encroach on cloud computing.  Will the historical borders continue to be meaningful?

This situation could unfold any number of ways.  As for video, the central issue remains: how to go about building a distributed system that meets the demanding needs across a multitude of video applications.