Datacenter - Network as a Service

SOA is not a product, but an architecture and the prescribed approach is now finding its way (quite violently sometimes) into the network. Let us start with the framework. We need to create a point of indirection between a network device (the service provider) and the end station (service consumer). That point of indirection is the repository where network devices register their service and its scope. The same repository should support a querying mechanism that returns a service description to the initiator of the query. We need a stack on the initiator which understands the description (i.e. no human involved) and can initiate a peering relationship with the service provider whose service description was returned as response to the query. We also need the repository to differentiate between a cataloged service (inventory) and a service instance (presence). We also need the repository to be available at a well known address because the network device is factory configured to find its repository. Finally, we need a service that creates this repository service should one not exist (when the first network box is deployed for example).

The next question is what is the protocol of communication that will support a conversation between the end station, repository and peers that are present. This is where folks gets in own way. For cataloging, we don't need presence information and for presence we do not need to be cataloged. One requires a session oriented protocol while the other requires a simple request/response. Both these protocols exist in inustry.

Where further work is required is description of the service and that is where the crux of the whole architecture lies. Here we need to take care that we don't fall into the trap of describing our CLI as XML.

Java CE (Cloud Edition)

Virtualization and its live migration is becoming an innovation blocker. Recall that the original problem that we are trying to solve is "How does an application get access to resources on demand?" In other words, how do we get an operating system that scales to an entire datacenter. Even with virtualization my application is contrained to an operating system.

What we need is a language run-time like JVM that talks to a hypervisor directly. What we need is a hypervisor that abstracts resource for an application at a level that the application understands i.e. tables, databases, files, serversockets and clientsockets, IO etc.

JeOS (Just enough OS) is a slow-start in a wrong direction. What we need is JNOS (Just No OS!).

Cloud needs Resource Reservation & Broker

A key element of the infrastructure that will form the cloud is resource reservation and a protocol that enables applications to reserve the resources. Without this element we can't have a credible SLA offering. But this reservation system has to be integrated into the billing system as well as the customer entitlement system.

Today's oversubscription systems allow contending processes to carry entitlements, however those entitlements have no basis in economic value of the user who initiated the process. For example, in VI, one can allocate shares to compute elements but those shares do take into account the customer's SLA entitlements. Neither did I see anything in the recently released vCloud API anything that says someone is thinking about it.

Since the days of Cluster/Grid, we have been making pretty powerpoint slides showing the business value of IT to customers. Cloud is supposed to provide the mechanisms for the customer to harness/govern the business value.

Policy vs. Mechanism in Cloud

Existing architectures come embedded with their own policies with little control left to end user. It appealed to the enterprise customer as they only had to learn the knobs and how much to turn it before the product starts to smoke. This is about to change in Cloud Computing.

The forceful intermediation of an economic model into the use of an application (which the main difference between cloud and a cluster-grid) is disaggregating the policy definition point or PDP into multiple tiers. This is similar to what we saw happen to policy enforcement during the development of 3-tier datacenters in late 90s. A policy defined at the CSP level will be inherited, extended and enforced at the enterprise IT level and further changed and extended at the end user level. This requirement of the cloud will create a bias in the architecture of a system towards mechanism and policy negotiations.

The policy vs. mechanism was a hot debate in early 90s and looks likely to return once again.

Cloud CPE

Hardly anyone mentions the need for a CPE which IMHO is a requirement for a cloud computing model. Today MSFT announced that their next version of Office will have a free online version. But one of the big features of a cloud is "offline browsing/applications". That is the only way to protect oneself from highly publicized outages at Amazon a few months ago and Rackable a few weeks ago.

CPE that enforces local security policies including authentication & filtering. Offline browsing and metering is a business model requirement in cloud computing.

The other function that is hardly discussed in CC discussions is syndication. I have been trying to add an animation/3D module to Google's online presentation (powerpoint equivalent), but not even google has open plug-in architecture to enable this. Unless folks think that Cloud is just another proprietary application running on the network, this functionality is the key extensibility requirement for a useful CC app.

MMOG is the true Cloud App

MMOG or Massively Multiplayer Online Game is a widely used cloud application that never makes it to any discussion on cloud computing. MMOG is expected to be $9B market by end of this decade with its ground zero in China. WOW (World of Warcraft) which debuted in China reached a peak concurrency of 500K users. These cloud applications have tens of millions of registered users with millions of daily visits. This industry has spawned an ecosystem around the applications with operators called MMOs. As with all technologies they have now introduced open platforms for games.

These gaming platforms have already experienced the issue that business oriented cloud computing platforms and later operators will face.

Appleap.com shows which games/apps are the most popular on Chinese SNS.

Servers for Clouds

Three major segments of cloud computing Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS), Software-as-a-Service(SaaS)

PaaS
force.com
googleapps
longjump, bunjee labs,

DNS is part of the cloud

With all the automation promised for an ISV in the cloud, there is a need for a service that most of us take for granted. I had blogged about it almost a year ago, but only recently figured out that I was only scrapping the surface of the problem from a cloud perspective.

If seven ISVs use the same cloud, whose DNS service are they going to use? Inside their cloud operation if an IP address is generated for a machine, how does a Java process open a socket on it? You cannot hardcode IP addrs. How can app guy write an application now that could be deployed behind any FQDN at any cloud. Cloud has multiple zones, how will the app developerknow the zone?

All of these issues cannot be solved by using DNSaaS. Some device inside needs to enable this.

Cloud Application Programming Model

Most of the definition(s) of cloud computing highlight just one of its dimension i.e. scale of the application delivery. Cloud computing, they say, is about internet scale (millions of simultaneous connections)application access that is hosted at a WAN latency distance. While remote hosting is an important characteristic of the cloud, it is not really, IMHO, the most important one. Back in late 1990s, we experimented with hosting applications remotely. That failed. It failed because the programming model did not evolve to accomodate distribution of functionality across WAN latent connections.

In today's Web 2.0 world, we have new page elements which can be dropped into a page which invoke remotely resident applications. This document management inspired model needs to evolve into a programmatic model for real cloud computing to happen. Document management paradigm is not an evolution from object oriented paradigm that is dominant today. The efforts that went into discovering the most efficient way to migrate object oriented programming to the web got lost in the endless debates on SOAP vs REST, Sync vs. Async, Language vs. Description etc. etc.

What a programmer aiming to write to cloud really wants is a way to import a library (java package for me) which is resident in a SDK that is installed somewhere on the web. This way I can import any java package that is somewhere in the world and access any database that is hosted anywhere in the world and have a class object sitting in my local directory that I load into any JVM on any device.

May be it is time for Sun to create a J2CE (Cloud Edition). J2CE should not require me to download anything other than a Netbeans IDE that has built in well know SDK locations that are resident around the world.

Bungee Jump off Puenta Iglesia over Rio Colorado

My first bungee jump off a bridge in south america over river Colorado. The bridge is 80m over the water and the bungee chord extends to within 20m of the ground.




I checked with AIG, if there is a mishap during a bungee jump, they don't pay your