ICT Capacity Building: Build Your Own Cloud
Originally Published: Tue. Oct. 07, 2008
" Today Dell launched an exciting new service: Dell Remote Access. One might ask: "Is this a cloud service?" On its own, no, it’s not. Is it cloudy? Absolutely, because for the digital nomads out there, DRA represents an opportunity to BYOC: Build Your Own Cloud… 
This might sound a bit far-fetched, but stay with me. Most definitions of cloud computing include the notion of compute and storage resources accessed remotely by users over the network. Typically this refers to massive, centralized power like that found in search platforms or compute services; tens or hundreds of thousands of servers and Petabytes of disk bound together to power the platform. Another concept in cloud computing is the notion of multi-tenancy of the platform; resources shared amongst users. BYOC employs these concepts on a human scale: a private cloud of your own, where light edge devices used anywhere can leverage the power of heavier centralized resources at the home.
For example: in my home (where I hold both “CTO” and “Support Queue Tech, Level 1” titles), we have several laptops and also share file storage on a NAS device hooked up to a wireless router. With Dell Remote Access I can tap into the processing and storage power of these devices remotely – from my phone, a browser at an internet café, or a laptop at the airport. I can run my applications with the horsepower and security I have built into my home environment. I can access gigs and gigs of our photos and music… all via the network… from “the edge.” (The edge being wherever I happen to be, with whatever device I happen to have at hand) Further, by sharing access to the folders on the various systems and the NAS drive amongst my users (aka, family), one might say there is multi-tenancy at play here as well.
Now I realize this is a bit tongue-in-cheek in the context of an enterprise computing blog. There is no demand-driven dynamic allocation of processing or storage as might be found in a true cloud. I do not have raised floor in my home office (although that would be cool), and I’m not charging my daughters by the core/hr or byte of data transferred (maybe I should). But I think much of the analogy really applies.
So the next time someone tells you to get off their cloud - go build your own…. "
Source: http://direct2dell.com/cloudcomputing/archive/2008/10/07/byoc-build-your...
Re: ICT Capacity Building: Build Your Own Cloud
Given enough hardware, you can now build your own Amazon Elastic Cloud or similar platform. And all in Open Source.
A group of developers from the Department of Computer Science at the University of California, Santa Barbara has recently released a tool that can make your personal Cloud dreams come true!
Eucalyptus has been developed in the MAYHEM Lab within the Computer Science Department at the University of California, Santa Barbara, primarily as a tool for cloud-computing research. It is distributed as open source with a FreeBSD-style license that does not restrict its usage much. Eucalyptus 1.0 targets Linux systems that use Xen (versions 3.*) for virtualization.
Eucalyptus is based on the Rocks cluster management platform. In the future, the EUCALYPTUS team will offer a source release along with other methods of deployment.
Being API compliant with Amazon EC2 means you can reuse the tools you already wrote for Amazon and effectively build your own while not having to change your applications. EUCALYPTUS also opens the door for other organizations with spare CPU cycles to offer Virtual Machines instances at a competitive price
http://virtualization.com/guest-posts/2008/06/06/build-your-own-cloud/
Re: ICT Capacity Building: Build Your Own Cloud
Defining what cloud computing is in itself a tough job, the lack of common cloud methodologies and best practices is making the job even harder. Trying to find experienced people with knowledge on how to build out a 30,000 machine cloud is nearly impossible, and finding someone who's deployed hundreds is proving to be almost as difficult.
There is an old saying in the venture capital world that consulting doesn't scale. As an entrepreneur I'm continually walking the line between making the short term buck (consulting revenue) versus the long tail (recurring revenue on product based licensing and support). Given that our platform is open source, consulting is typically a major part of our revenue model. The dilemma is a fairly straightforward one. I'm in business to make money, in our case, from as many different opportunities as possible.
Lately it seems everyone is in need of assistance with their clouds, from architecture, setup and deployment - there seems to be real need for the "Cloud Consultant". For us these jobs range from your dedicated hosting firms and large telecoms looking to create EC2-like utilities to software & traditional enterprises looking to deploy their new "as a service" offerings in a scalable way. A lot of people talk about the cloud killing the traditional system administrator's job, but in my opinion there has never been a better time to be working in IT. Those who see this paradigm shift toward cloud computing will prosper.
Defining what cloud computing is in itself a tough job, and the lack of common cloud methodologies and best practices is making the job even harder. Trying to find experienced people with knowledge on how to build out a 30,000 machine cloud is nearly impossible, and finding someone who's deployed hundreds is proving to be almost as difficult. We the pioneers in the cloud computing space must take steps to create an open development ecosystem, one where we share our failures and successes so others can learn the trade.
One way may be to create a common cloud specification. David Young over at Joyent, attempted to do this, he has called for a common cloud specification called "Cloud Nine". In his modest proposal, he calls for an open specification based on nine core components.
1) Virtualization Layer Network Stability
2) API for Creation, Deletion, Cloning of Instances
3) Application Layer Interoperability
4) State Layer Interoperability
5) Application Services (e.g. email infrastructure, payments infrastructure)
6) Automatic Scale (deploy and forget about it)
7) Hardware Load Balancing
8) Storage as a Service
9) “Root”, If Required
Although I'm not sure about the need for root access or hardware based load balancing his post raises some interesting ideas. In particular he says "a developer should be able to move between Joyent, the Amazon Web Services, Google, Mosso, Slicehost, GoGrid, etc. by simply pointing the “deploy gun” at the cloud and go." I think he nailed it dead on with this statement
http://virtualization.sys-con.com/node/584130