Cloud Computing

You are currently browsing the archive for the Cloud Computing category.

A paper titled “Hey, you, Get Off of My Cloud: Exploring information Leakage in Third-Party Compute Clouds” soon to be released at CCS’09 is exploring the threats resulting from sharing physical compute resources in public clouds.
After demonstrating that despite the likely large number of physical machines in any given public cloud, it is possible to place hostile VMs next to targeted VMs; the authors are listing methods that are taking advantage of information leaking out through shared physical resources.

The paper concludes that the only foolproof solution is to limit sharing with potentially hostile tenants:

A user might insist on using physical machines populated only with their own VMs and, in exchange, bear the opportunity costs of leaving some of these machines under-utilized. For an optimal assignment policy, this additional overhead should never need to exceed the cost of a single physical machine, so large users — consuming the cycles of many servers — would incur only minor penalties as a fraction of their total cost.
Regardless, we believe such an option is the only foolproof solution to this problem and thus is likely to be demanded by customers with strong privacy requirements.

I have one issue with this recommendation: the colocation of many VMs from the same tenant on fewer physical hosts is increasing the risk of having single points of failure. Assuming 8 small instances per physical machine (based on the document estimates), and given the default limit of 20 active VMs per account, most accounts will need less than 3 physical servers, limiting the spread across the availability zones. At that point the tradeoff will be between availability, security and cost.

A while back I listed the open source configuration automation projects: bcfg2, cfengine, puppet and lcfg. Since then, three major things happened:

The puppet community has split

There was a split in the puppet community and a new project saw life as a result: Chef. Chef is describing itself as :

Chef is a systems integration framework, built to bring the benefits of configuration management to your entire infrastructure. With Chef, you can:

  • Manage your servers by writing code, not by running commands. (via Cookbooks)
  • Integrate tightly with your applications, databases, LDAP directories, and more. (via Libraries)
  • Easily configure applications that require knowledge about your entire infrastructure (”What systems are running my application?” “What is the current master database server?”)

More details about the Chef differentiators can be found here.

In a future post, I’ll explore in more details the challenges around configuration automation, and the procedural approach.

Reductive Labs received funding

Reductive Labs, the company responsible for Puppet, has received  $2 Million in funding. Puppet has been gaining traction against cfengine, but it will be interesting to see how Reductive Labs uses its funding, and how the new Chef solution is impacting this progression.

Cloud Computing brought configuration automation in the spotlight

One of the cornerstones of Cloud Computing is the automation of the infrastructure configuration. Either because you want to build a highly automated infrastructure supporting cloud users, or you are putting your application in the cloud. In both cases, infrastructure and applications configuration has to be captured, maintained and automatically provisioned. This will enable rapid scale out, fail over, or in general deployment and redeployment of the managed components.