Among a wealth of features, Cloud computing is about replication, about managing heterogeneous workloads and direct them dynamically to the most appropriate replicas available (and creating new replicas if the current number is not enough, i.e., horizontal scalability).

Indeed, the Cloud has recently been dubbed as “what makes the Cloud something more than an outsourced service with a pretty marketing face” by Owens in ACM Queue. However, when looking back for some inspiration sources, one suddenly realizes that many of the issues he/she is facing have previously been dealt with by many others in several different aspects.

A somewhat old (2004) article by Sivasubramanian popped up this déja vu. The idea of a feedback controller to treat how VMs are replicated that we presented in FGCS a few months ago, is also used by these authors to explain how the control scalability (replication) of Web systems. The questions they pose have 100% validity in current IaaS Cloud scenarios:

1. What is the best metric to scale a set of VMs? we have added service level metrics to this, by the essence remains the same.
2. When and Where do we replicate a Web document? the shift here has  been to where do we have to place a given VM in our datacenter farm and when such replication should be triggered.
3. How do we route these requests to the appropriate replica? This question is kept unaltered for cloud systems.

Thus, metric determination, triggering replication, placement of the new replica and request routing are shared elements between IaaS clouds and web hosting replication systems. Indeed, some fresh research attempts try to solve these problems for VM allocation and physical servers resource optimization.

Once again, this proves that stopping to avoid reinventing the wheel is worth the employed time.

Claudia’s major article has been rated third in the list of top 25 hottest articles in Computer Science made by Springer.

It seems cloud elasticity is gaining more and more attention these days. More coming up soon.

IBM has recently launched its Cloud Service Provider Platform (CSPP) that is “a comprehensive set of hardware, software, and services” that will let CSPs deliver new cloud-based services to their customers.

Managing millions of VMs concurrently is a nice.have, but what happens when it comes to controlling applications (more than just collections of VMs). This is a verily long desired capability that few other systems allowed you to perform. However, there are some important features to help Cloud Service Providers actually manage their services/applications. These guys are not concerned about vCPU usage, or vMEM usage, etc (typical cloud metrics), but they want to scale and control services automatically by setting rules closer to their common mindsets. Is the user supposed to be controlling every VM individually, do they envision the abstraction of the application (as a set of VMs plus their shared context, linked deployment, entwined scaling rules attaining a whole tier, custom actions and metrics for scaling, etc.)?

Also, SLAs and security are key barriers to attract clients to your platform. How are these dealt with in this new product? Too many questions to be solved. I hope I may have the chance to work with this and find out a bit more soon.

Security has often been claimed to be the most severe concern of companies preventing them to get into the cloud. However, recent data by Compuware, reveal how the lack of appropriate performance by the cloud is also seen as a money sink by European companies. Large European organizations are estimated to lose €608,000 every year due to performance-related problems.

The need for ensuring certain Quality of Service (QoS) levels is, thus, becoming an essential feature that can no longer e deferred. Terms such as “100% Uptime” SLA, 99..997 availability, etc. offered by most big cloud players today, need to be replaced by a series of features that actually satisfy users’ needs and allow for custom SLAs. Today’s Clouds still lack the proper SLA support demanded by users: automatic SLA renegotiation, live service migration, security, semantic QoS, advanced accounting/billing and performance prediction are still missing features to be included in the SLA terms.

“84% of those questioned stated that they would expect more rigorous SLAs that go beyond simple availability metrics if they increase their use of business-critical cloud applications. 67% though believe that their IT teams have the skills needed to negotiate the more complex SLAs required for cloud services.”

A recent post by Brian Proffitt highlighted how the state of cloud standards in “amorphous and constantly changing”.

Proffitt also emphasizes how different organizations are engaged in a race for creating cloud standards, paying little attention to co-operation and redundant work being done. A clear example is the reinvention of the wheel of IaaS cloud standards with OCCI, TCloud, vCloud and Amazon’s EC2 API (the de facto standard). Is this overhead actually needed? We do not thing so… while academia and industry start a battle for the “controller of the cloud”, we believe that only those to-be standards that offer easy and detailed implementations would succeed in the race. OCCI may fall down in this, since it does not specify concrete data formats, which lets room for a variety of incompatible implementations that are, sadly, OCCI compliant.

Deltacloud has been there for a while and it is not a standard per se, just a wrapper of the underlying heterogeneity of clouds.

We also like to see OpenStack, a real open source toolkit to build your own cloud as one of the alternatives to Amazon’s API. Let’s see where the wind will take us. The battle has just begun.