Cloud Computing: Commodity or Value Sale?

By Rich Wellner

There is a controversy in the cloud community today about whether the market is going to be one based on value or price. Rephrased, will cloud computing be a commodity or an enablement technology.

A poster on one of the cloud computing lists asserted that electricity would be a key component of pricing. He was then jumped on by people saying that value would be the key.

It seems like folks are talking past one another.

His assertion is true if CC is a commodity.

Now that said, there are precious few commodities in IT. Maybe internet connectivity is one. Monitors might be another. Maybe there are a few more.

But very quickly you get past swappable components that do very nearly the same job and into the realm of 'stuff' that is not easily replaceable. Then the discussion turns to one of value.

Amazon recognized the commodity of books and won the war over people who were trying to sell value. They appear to be attempting to do the same with computer time, which makes the battle they will fight over the next few years with Microsoft (and the increasing number of smaller players) extra interesting.

There is also the problem of making sweeping statements like "the market will figure things out". There is no "the market". Even on Wall Street. The reason things happen is because different people and institutions have different investment goals. Those goals vary over time and create growing or shrinking windows of opportunity for other people and institutions.

I've made my bet on how "the market" for cloud computing will shake out in the short to medium term. Now I'm just hoping that there are enough of the people and institutions my bet is predicated on in existence.

Elastic Management of Computing Clusters

By Ignacio Martin Llorente

Besides all the hype, clouds (i.e. a service for the on-demand
provision of virtual machines, others would say IaaS) are making
utility computing a reality, check for example the the Amazon EC2 case studies .
This new model, and virtualization technologies in general, is also
being actively explored by the scientific community. There are quite a
few initiatives that integrates virtualization with a range of
computing platforms, from clusters to Grid infrastructures.
Once this integration is achieved the next step is natural, jump to the
clouds and provision the VMs from an external site. For example, a
recent work from UNIVA UD has demonstrated the feasibility of supplementing a UNIVA Express cluster with EC2 resources (you can download the whitepaper to learn more).

This cloud provision model can be further integrated with the
in-house physical infrastructure when it is combined with a virtual
machine (VM) management system, like OpenNebula.
A VM manager is responsible for the efficient management of the virtual
infrastructure as a whole, by providing basic functionality for the
deployment, control and monitoring of VMs on a distributed pool of
resources. The use of this new virtualization layer decouples the
computing cluster from the physical infrastructure, and so extends the
classical benefits of VMs to the cluster level (i.e. cluster
consolidation, cluster isolation, cluster partitioning and elastic
cluster capacity).

Architecture of an Elastic Cluster

A computing cluster can be easily virtualized by putting the front-end
and worker nodes into VMs. In our case, the virtual cluster front-end
(SGE master host) is deployed in the local resources with Internet
connectivity to be able to communicate with Amazon EC2 VMs. This
cluster front-end acts also as NFS and NIS server for every worker node
in the virtual cluster.

The virtual worker nodes communicate with the front-end through a private local area network. The local worker nodes are connected to this vLAN through a virtual bridge configured in every physical host.  The EC2 worker nodes
are connected to the vLAN with an OpenVPN tunnel, which is established
between each remote node (OpenVPN clients) and the cluster front-end
(OpenVPN server). With this configuration, every worker node (either
local or remote) can communicate with the front-end and can use the
common network services transparently. The architecture of the cluster
is shown in the following figure:

Figure courtesy of Prof. Rafael Moreno

Deploying a SGE cluster with OpenNebula and Amazon EC2

The last release of OpenNebula includes a driver to deploy VMs in the
EC2 cloud, and so it integrates the Amazon infrastructure with your
local resources. The EC2 is managed by OpenNebula just as another local
resource with a configurable pre-fixed size,
to limit the cluster capacity (i.e. SGE workernodes) that can be
allocated in the cloud. In this set-up, your local resources would look
like as follows:

>onehost list
HID NAME     RVM      TCPU   FCPU   ACPU    TMEM    FMEM STAT
   0 ursa01     0       800    798    800 8387584 7663616  off
   1 ursa02     0       800    798    800 8387584 7663616  off
   2 ursa03     0       800    798    800 8387584 7663616  on
   3 ursa04     2       800    798    600 8387584 6290432  on
   4 ursa05     1       800    799    700 8387584 7339008  on
   5 ec2        0       500    500    500 8912896 8912896  on

The last line corresponds to EC2, currently configured to host up to 5 m1.small instances.

The OpenNebula EC2 driver translates a general VM deployment file in
an EC2 instance description. The driver assumes that a suitable Amazon
machine image (AMI) has been previously packed and registered in the S3
storage service. So when a given VM is to be deployed in EC2 its AMI
counterpart is instantiated. A typical SGE worker node VM template
would be like this:

NAME   = sge_workernode
CPU    = 1
MEMORY = 128                                                            

#Xen or KVM template machine, used when deploying in the local resources
OS   = [kernel="/vmlinuz",initrd= "/initrd.img",root="sda1" ]
DISK = [source="/imges/sge/workernode.img",target="sda",readonly="no"]
DISK = [source="/imges/sge/workernode.swap",target="sdb",readonly="no"]
NIC  = [bridge="eth0"]

#EC2 template machine, this will be use wen submitting this VM to EC2
EC2 = [ AMI="ami-d5c226bc",
        KEYPAIR="gsg-keypair",
        AUTHORIZED_PORTS="22",
        INSTANCETYPE=m1.small]

Once deployed, the cluster would look like this (sge master, 2 local worker nodes and 2 ec2 worker nodes:

>onevm list
  ID      NAME STAT CPU     MEM        HOSTNAME        TIME
  27  sgemast runn 100 1232896          ursa05 00 00:41:57
  28  sgework runn 100 1232896          ursa04 00 00:31:45
  29  sgework runn 100 1232896          ursa04 00 00:32:33
  30  sgework runn   0       0             ec2 00 00:23:12
  31  sgework runn   0       0             ec2 00 00:21:02

You can get additional info from your ec2 VMs, like the IP, using the onvm show command

So, it is easy to manage your virtual cluster with OpenNebula and
EC2, but what about efficiency?. Besides the inherent overhead induced
by virtualization (around a 10% for processing), the average deployment
time of a remote EC2 worker node is 23.6s while a local one takes only
3.3s. Moreover, when executing a HTC workload, the overhead induced by
using EC2 (vpn, and a slower network connection) can be neglected.

Ruben S. Montero

This is a joint work with Rafael Moreno and Ignacio M. Llorente

Reprinted from blog.dsa-research.org 

Auditing the Cloud

By Rich Wellner

I've written here about the importance of SLAs for useful cloud computing platforms on a few occasions in the past. The idea behind clouds, that you can get access to resources on demand, is an appealing one. However, it is only part of the total picture. Without an ability to state what you want and go to bed, there isn't much value in the cloud.

Think about that for a minute. With the cloud computing offerings currently available there are no meaningful SLAs written down anywhere. Yet people, every day, run their production applications on an implicit SLA that is internalized something like "amazon is going to give me N units of work for M price".

There are two problems with this.

• Amazon doesn't scale your resources. Your demand may have spiked and you are still running on the resource you signed up for.
  
• There is no audit capability on EC2.
  

In the Cloud Computing Bill of Rights we wrote about three important attributes that need to be available to do an audit.

• Events -- The state changes and other factors that effected your system availability.
  
• Logs -- Comprehensive information about your application and its runtime environment.
  
• Monitoring -- Should not be intrusive and must be limited to what the cloud provider reasonably needs in order to run their facility.
  

The idea here is that rather than just accepting what your cloud provider sends you at the end of the month as a bill, the world of cloud computing is complex enough that a reasonable set of runtime information must be made available to substantiate the providers claim for compensation.

This is particularly true in the world of SLAs. If my infrastructure is regularly scaling up, out, down or in to meet demands it is essential to be able to verify that the infrastructure is reacting the way that was contracted. Without that, it will be very hard to get people to trust the cloud.

Cloud and Grid are Complementary Technologies

By Ignacio Martin Llorente

There is a growing number of posts and articles trying to show how
cloud computing is a new paradigm that supersedes Grid computing by
extending its functionality and simplifying its exploitation, even
announcing that Grid computing is dead.
It seems that new technologies and paradigms have always the mission
objective to substitute existing ones. Some of these contributions do
not fully understand what grid computing is, focusing their comparative
analysis on simplicity of interfaces, implementation details or basic computing aspects. Others posts define Cloud in the same terms as Grid or create a taxonomy which includes Grid and cluster computing technologies.

Grid is as an interoperability technology, enabling
the integration and management of services and resources in a
distributed, heterogeneous environment. The technology provides support
for the deployment of different kinds of infrastructures joining
resources which belong to different administrative domains. In the
special case of a Compute Grid infrastructure, such as EGEE or TeraGrid,
Grid technology is used to federate computing resources spanning
multiple sites for job execution and data processing. There are many
success cases demonstrating that Grid technology provides the support
required to fulfill the demands of several collaborative scientific and
business processes.

On the other hand, I do not think there is a single definition for cloud computing as it denotes multiples meanings for different communities (SaaS, PaaS, IaaS...). From my view, the only new feature offered by cloud systems is the provision of virtualized resources as a service, being virtualization the enabling technology. In other words, the relevant contribution of cloud computing is the Infrastructure as a Service (IaaS) model.
Virtualization rather than other non significant issues, such as the
interfaces, is the key advance. At this point, I should remark that virtualization has been used by the Grid community before the arrival of the "Cloud".

Once I have clearly stated my position about Cloud and Grid, let me
show how I see Cloud (and virtualization as enabling technology) and
Grid as complementary technologies that will coexist and cooperate at
different levels of abstraction in future infrastructures.

There will be a Grid on top of the Cloud

Before explaining the role of cloud computing as resource provider
for Grid sites, we should understand the benefits of the virtualization
of the local infrastructure (Enterprise or Local Cloud?). How can I access on demand to a cloud provider if I have not previously virtualized my local infrastructure?.

Existing virtualization technologies allow a full separation of resource provisioning from service management.
A new virtualization layer between the service and the infrastructure
layers decouples a server not only from the underlying physical
resource but also from its physical location, without requiring any modification within service layers from both the service administrator and the end-user perspectives. Such decoupling is the key to support
the scale-out of a infrastructure in order to supplement local
resources with cloud resources to satisfy peak or fluctuating demands.

Getting back to the Grid computing case, the virtualization of a Grid site provides several benefits, which overcome many of the technical barriers for Grid adoption:

• Easy support for VO-specific worker nodes
• Reduce gridification cycles
• Dynamic balance of resources between VO’s
• Fault tolerance of key infrastructure components
• Easier deployment and testing of new middleware distributions
• Distribution of pre-configured components
• Cheaper development nodes
• Simplified training machines deployment
• Performance partitioning between local and grid services
• On-demand access to cloud providers

If you are interested in more details about how virtualization
and cloud computing can support compute Grid infrastructures you can
have a look at my presentation "An Introduction to Virtualization and Cloud Technologies to Support Grid Computing" (EGEE08). I also recommend the report "An EGEE Comparative study: Clouds and grids - evolution or revolution?".

There exist technology which supports the above use case. The OpenNebula engine
enables the dynamic deployment and re-allocation of virtual machines on
a pool of physical resources, providing support to access on-demand to Amazon EC2 resources. On the other hand, Globus Nimbus
provides a free, open source infrastructure for remote deployment and
management of virtual machines, allowing you to create compute clouds.

There will be a Grid under the Cloud

There is a growing interest in the federation of cloud sites. Cloud providers are opening new infrastructure centers at different geographical locations (see IBM or Amazon Availability Zones)
and it is clear that no single facility/provider can create a seemingly
infinite infrastructure capable of serving massive amounts of users at
all times, from all locations. David Wheeler once said, "Any problem in computer science can be solved with another layer of indirection… But that usually will create another problem“,
in the same line, federation of cloud sites involves many technological
and research challenges, but the good news is that some of them are not
new, and have been already studied and solved by the Grid community.

As stated above Grid is not only about computing. Grid is a technology for federation.
In the last years, there has been a huge investment in research and
development of technological components for sharing of resources across
sites. Several middleware components for file transferring, SLA
negotiation, QoS, accounting, monitoring... are available, most of them
are open-source. As also predicted by Ian Foster in his post "There's Grid in them thar Clouds",
those will be the components that could enable the federation of cloud
sites. On the other hand, other components have to be defined and
developed from scratch, mainly those related to the efficient
management of virtual machines and services within and across
administrative domains. That is exactly the aim of the Reservoir project, the European initiative in Cloud Computing.

Conclusions

In order to conclude this post let me venture some predictions about the coexistence of Grid and Cloud computing in future infrastructures:

• Virtualization, cloud, grid and cluster are complementary
  technologies that will coexist and cooperate at different levels of
  abstraction
• Although there are early adopters of virtualization in the
  Grid/cluster/HPC community, its full potential has not been exploited
  yet
• In few years, the separation of job management from resource
  management through a virtualized infrastructure will be a common
  practice
• Emerging open-source VM managers, such as OpenNebula, will contribute to speed up the adoption
• Grid/cluster/HPC infrastructures will maintain a resource base
  scaled to meet the average workload demand and will transparently
  access to cloud providers to meet peak demands
• Grid technology will be used for the federation of clouds

In summary, let's try to forget about hypes and concentrate on the
complementary functionality provided by both paradigms. My message to
the user community, the relevant issue is to evaluate which technology
meets your requirements. It is unlikely that a single technology will meet all
needs. My message to the Grid community, please do not see Cloud as a
threat. Virtualization and Cloud are needed to solve many of the
technical barriers for wider Grid adoption. My message to the Cloud
community, please try to take advantage of the research and development
performed by the Grid community in the last decade.

Ignacio Martín Llorente

Reprinted from blog.dsa-research.org

The OpenNebula Engine for Data Center Virtualization and Cloud Solutions

By Ignacio Martin Llorente

Virtualization has opened up avenues for new resource management
techniques within the data center. Probably, the most important
characteristic is its ability to dynamically shape a given hardware
infrastructure to support different services with varying workloads.
Therefore, effectively decoupling the management of the service (for
example a web server or a computing cluster) from the management of the
infrastructure (e.g. the resources allocated to each service or the
interconnection network).

A
key component in this scenario is the virtual machine manager. A VM
manager is responsible for the efficient management of the virtual
infrastructure as a whole, by providing basic functionality for the
deployment, control and monitoring of VMs on a distributed pool of
resources. Usually, these VM managers also offer high availability
capabilities and scheduling policies for VM placement and physical
resource selection. Taking advantage of the underlying virtualization
technologies and according to a set of predefined policies, the VM
manager is able to adapt the physical infrastructure to the services it
supports and their current load. This adaptation usually involves the
deployment of new VMs or the migration of running VMs to optimize their
placement.

The dsa-research group
at the Universidad Complutense de Madrid has released under the terms
of the Apache License, Version 2.0, the first stable version of the OpenNebula Virtual Infrastructure Engine.
OpenNebula enables the dynamic allocation of virtual machines on a pool
of physical resources, so extending the benefits of existing
virtualization platforms from a single physical resource to a pool of
resources, decoupling the server not only from the physical
infrastructure but also from the physical location. OpenNebula is a
component being enhanced within the context of the RESERVOIR European Project.

The new VM manger differentiates from existing VM managers in its
highly modular and open architecture designed to meet the requirements
of cluster administrators. OpenNebula 1.0 supports Xen and KVM
virtualization platforms to provide several features and capabilities
for VM dynamic management, such as centralized management, efficient
resource management, powerful API and CLI interfaces for monitoring and
controlling VMs and physical resources, fault tolerant design... Two of
the outstanding new features are its support for advance reservation
leases and on-demand access to remote cloud provider

Support for Advance Reservation Leases

Haizea
is an open source lease management architecture that OpenNebula can use
as a scheduling backend. Haizea uses leases as a fundamental resource
provisioning abstraction, and implements those leases as virtual
machines, taking into account the overhead of using virtual machines
(e.g., deploying a disk image for a VM) when scheduling leases. Using
OpenNebula with Haizea allows resource providers to lease their
resources, using potentially complex lease terms, instead of only
allowing users to request VMs that must start immediately.

Support to Access on-Demand to Amazon EC2 resources

Recently, virtualization has also brought about a new utility
computing model, called cloud computing, for the on-demand provision of
virtualized resources as a service. The Amazon Elastic Compute Cloudi
s probably the best example of this new paradigm for the elastic
capacity providing. Thanks to virtualization, the clouds can be used
efficiently to supplement local capacity with outsourced resources. The
joint use of these two technologies, VM managers and clouds, will
change arguably the structure and economics of current data centers.
OpenNebula provides support to access Amazon EC2 resources to
supplement local resources with cloud resources to satisfy peak or
fluctuating demands.

Scale-out of Computing Clusters with OpenNebula and Amazon EC2

As use case to illustrate the new capabilities provided by OpenNebula, the release includes documentation
about the application of this new paradigm (i.e. the combination of VM
managers and cloud computing) to a computing cluster, a typical data
center service. The use of a new virtualization layer between the
computing cluster and the physical infrastructure extends the classical
benefits of VMs to the computing cluster, so providing cluster
consolidation, cluster partitioning and support for heterogeneous
workloads. Moreover, the integration of the cloud in this layer allows
the cluster to grow on-demand with additional computational resources
to satisfy peak demands.

Ignacio Martín Llorente

Reprinted from blog.dsa-research.org

Cloud Caucusing

By Rich Wellner

Several months ago on this blog, I mused on what was meant by the term cloud computing.  At the time, it was even more difficult than it is today to get a solid definition of the concept.  Since then, many opinions have been bandied about providing plenty of fuel for the debate.  While I think the concept has solidified some, cloud computing remains a highly polysemous term where folks from different backgrounds have developed their own definitions based upon their particular worldviews.  These viewpoints come from vendors, specialists, researchers, as well as different user communities.

Although a unified definition for cloud computing has not emerged, the concept has gained a lot of traction. I believe that this is because each interested-group has found significant promise in what they call the cloud. Of course anything with this much possibility will certainly see some hype.  As I have said, before: the term invokes thoughts of transient beauty and power: even marketing folks can get excited with this one!  (Compare that to SaaS).

In any event, I thought that I would give you a quick idea of the types of discussions going on around cloud computing on the internet:

• Twenty Experts Define Cloud Computing;
• The Next Perfect IT Storm;
• Google Groups “Discussion on the-definition-of-a-cloud-of-computers”;
• Cloud Computing Promise & Reality (from which we learned, “There is a clear consensus that there is no real consensus on what cloud computing is.”  Bob Buderi, founder and CEO of Xconomy);
• Cloud Computing Hype versus Reality;
• Wiki Definition.
  

Compare these to one of the earliest usages of the term (search for cloud).  Clearly, these documents are far from a representative set of the discussions going on out there.  It just so happened that I selected a few from those I have read lately. There really is a lot going on out there.

Ultimately I expect to see many types of formalized clouds, each depending on their
operating environments and behaviors — just like I see when I look outside my
window. Once that happens, the big debates about how to interoperate between clouds of very different nature will begin. Transforming a concept into a widely accepted framework is never easy.  After all, why should I have to bend my perfect cloud so that it works with yours?

So what is the upside of all this banter? It turns out that the less often a word is used, the faster it evolves. Ironically, the hype may actually force this community into consensus.  As long as we keep this dialog going, we should expect a formalized cloud to come about in no time!!!

A Cloud by Any Other Name

By Rich Wellner

The cloud list on google has been buzzing lately about the term "Enterprise Cloud" and whether it had any significance.

I had to chuckle as history started to repeat itself again between the early days of the grid and the early days of the cloud.

In our book Pawel and I wrote a section titled "How the Market Understands Grids". We didn't try to dictate terms, we tried to document the language in place at that moment in time.

In interviewing users we gathered the following terms:

• Clusters -- Computers standing together, but accessible only to a small group of people
• Departmental grids -- Multiple clusters accessible on a common backplane, but owned by one department
• Enterprise grids -- Corporate resources available to all in the company (known today as a Enterprise Cloud)
• Partner grids -- A few companies working together on big problems and sharing resources to accomplish their goals.
• Open grids -- Many organizations making resources available to other members of that grid. A key distinction between an open grid and a partner grid is that an open grid doesn't typically have a key application or goal while a partner grid does.

We blanched a bit because to us grid computing meant only the last definition and we viewed those other ones as missing some key attributes that those of us who had been working in the grid field since its inception thought were really important.

We see the same thing happening today with the term cloud and particularly in the term Enterprise Cloud.

That said, is Enterprise Cloud really an oxymoron, as one person suggested?

First we have to get to definitions:

Here are the key characteristics from the cloud computing wiki:

• Capital expenditure minimized and thus low barrier to entry as infrastructure is owned by the provider and does not need to be purchased for one-time or infrequent intensive computing tasks. Services are typically being available to or specifically targeting retail consumers and small businesses.
  
• Device and location independence which enables users to access systems regardless of location or what device they are using (eg PC, mobile).
  
• Multitenancy enabling sharing of resources (and costs) among a large pool of users, allowing for:
  
  • Centralization of infrastructure in areas with lower costs (eg real estate, electricity)
    
  • Peak-load capacity increases (users need not engineer for highest possible load levels)
    
  • Utilization and efficiency improvements for systems that are often only 10-20% utilised.
    
• Performance is monitored and consistent but can be affected by insufficient bandwidth or high network load.
  
• Reliability by way of multiple redundant sites, which makes it suitable for business continuity and disaster recovery, however IT and business managers are able to do little when an outage hits them.
  
• Scalability which meets changing user demands quickly, without having to engineer for peak loads. Massive scalability and large user bases are common but not an absolute requirement.
  
• Security which typically improves due to centralization of data, increased security-focused resources, etc. but which raises concerns about loss of control over certain sensitive data. Accesses are typically logged but accessing the audit logs themselves can be difficult or impossible.
  
• Sustainability through improved resource utilisation, more efficient systems and carbon neutrality.
  

None of those seem to exclude the term Enterprise Cloud.

Here's the list of attributes I compiled from the cloud google group and others IRL:

• Multiple vendors accessible through open standards and not centrally
  administered
  
• Non-trivial QOS (see the gmail debate thread)
  
• On demand provisioning
  
• Virtualization
  
• The ability for one company to use anothers resources (e.g. bobco
  using ec2)
  
• Discoverability across multiple administrative domains (e.g.
  brokering to multiple cloud vendors)
  
• Data storage
  
• Per usage billing
  
• Resource metering and basic analytics
  
• Access to the data could me bandwidth/latency limitations, security,
  
• Compliance – Architecture/implementation, Audit, verification
  
• Policy based access – to data, applications and visibility
  
• Security not only for data but also for applications
  

Now here we start to see some things that aren't applicable to enterprise clouds (i.e. 1, 5, 6). But the bulk of the list still works. And it's worth noting that EC2 fails on four of those things (i.e. 1, 11, 12, 13), but people don't hesitate to allow them the use of the term cloud.

In previous technology revolutions I learned the lesson (slowly) to not care so much what things are called as much as what they do (which was why, in my early writings on this group I was trying to point out to people (mostly unsuccessfully) that there are lessons to be learned from grid computing). But claiming there is a canonical definition of cloud and that enterprise cloud is a nonsense term doesn't seem accurate on the face of things. Enterprise Cloud does, however capture the essence of what many large corporate IT groups are doing/considering. Rather than telling them they shouldn't be calling it cloud/grid/enterprise cloud/managed services/SaaS/whatever, I'm taking the approach of helping them meet their business needs, with technology wearing a variety of banners, and letting them call it whatever they like.