« Enterprise Virtualization and the Problems of Management | Main | The new challenges for your network management software »

The Missing Piece in Cloud Computing: Middleware Virtualization

This is an interesting piece about the role of middleware (the "classic" tiers and APIs) and of virtualization in attaining the real benefits of utility computing and Cloud Computing (though I'm still hardpressed to distinguish the two terms in a meaningful way). 

What caught my eye particularly is the approach they've taken at Gigaspaces to virtualization for the application container. This notion of bundling and consolidating the logic needed to enforce SLAs and simultaneously meet the requirements of the application architects is an approach for which I have great respect, and which we're employing in our efforts regarding network virtualization at Replicate Technologies.

Nati Shalom's Blog: The Missing Piece in Cloud Computing: Middleware Virtualiztion

In the current server-centric world we use middleware to provide common infrastructure services, such as application containers, data and messaging. To make that same model work in a cloud environment we need to virtualize all of those components. That is, we need to virtualize the container, the data and messaging. By doing so we abstract the application from the fact that it is running on a "cloud" and make the transition from a server-centric model to cloud computing relatively seamless. How do we achieve that?
The SLA-driven container takes an application bundle and manages the
deployment of that bundle over a set of containers based on
Service-Level Agreements. The SLAs define the clustering topology
(e.g., partitioning, size of the application pool, scalability,
fail-over policies, etc.). It is used to map the available physical
compute resources to the application needs. It is also used to provide
self-healing capabilities to our application. For example, we can set
an SLA to ensure that at any point in time we always have primary and
backup instances for each node in our environment - and that each
node's primary and backup must run on separate physical machines. In
case a primary fails, the system will dynamically set the backup as the
new primary, and will launch another backup on another machine.

Powered by ScribeFire.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.