Recent Posts
P2C: A Funny Thing Happened on the Way to the Cloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Ellen Rubin
As IT organizations move forward with their virtualization initiatives, consolidating operations and shrinking provisioning times, the cloud has come along as an even more compelling option. In the cloud, companies can build capacity on-demand without having to own or manage the computing infrastructure. As companies review their application portfolios, they’ve started to realize that many of their not-yet-virtualized apps could easily be run in the cloud. In particular, applications that are characterized by spikey, cyclical, or seasonal usage could benefit the most from the cloud’s economics and scalability — but a significant percentage aren’t even getting the benefits of virtualization.
So what’s the delay in going “P2V” (physical to virtual)? As with the cloud, virtualization has typically percolated from the bottom up. In many cases it crept into organizations, led by developers and technology evangelists who recognized the efficiency and cost advantages of virtualization and simply started using it. While many enterprise customers have started expanding their virtual footprints it can be a long and complex process. Although technically it’s quite easy to virtualize an application, using a number of well-known P2V tools such as VMWare Converter from VMware or Platespin (now owned by Novell), the harder part of the process is often agreeing which applications to virtualize and understanding the inter-dependencies between these apps and other data center services.
As corporate IT has slowly adopted virtualization as a strategic imperative, the cloud has come along with paradigm-changing flexibility and elasticity. We’re now seeing enterprise customers and prospects ask what they can do with applications that aren’t yet virtualized and are still sitting on dedicated servers, recognizing that the cloud is likely to be their ultimate home. Thus we’re seeing the emergence of a new model — “P2C” (physical to cloud), with virtualization in the data center becoming a stepping stone to the ultimate destination of the cloud. As discussed in a previous blog, the cloud has become a catalyst that is prompting companies to broaden their virtualization efforts.
Customers and prospects have told us that the P2C model is far preferable to simply performing a virtualization project in a vacuum and figuring out later which applications really belong in the cloud and how to get them there. In contrast, P2C is all about planning for the cloud from the outset, starting with virtualization and moving to the cloud as a natural progression. The P2C approach can also lead enterprises to alter their virtualization strategy compared to pure P2V. In some cases, they may want to use the cloud as a temporary home for applications that need to migrate between data centers, to support satellite offices or in the case of an acquisition. In other cases, they may keep the application permanently in the cloud and be able to budget for far fewer internal resources.
Thus, we encourage customers to consider P2C as a valuable strategy, since for many applications, the cloud will deliver far greater self-service and on-demand computing power than available internally. By planning for this ultimate goal and designing their infrastructure accordingly, customers can also potentially save a great deal of time and money. Ultimately, a single integrated environment will span the virtualized data center and multiple clouds, using the same tools and providing the same simplicity of experience. CloudSwitch is working with our customers and partners to make it easy to use the cloud, regardless of the starting point.
OpenStack - Advancing Cloud Computing in the Open
By John Considine
When Rackspace first started talking with me about open sourcing their cloud software, I was truly intrigued. The idea of releasing the software behind their cloud was unexpected given that most cloud providers treat their infrastructure, and particularly their control software, as a differentiator. One of the things that make the software so valuable is the hard earned lessons from building, scaling, and maintaining a cloud. An infrastructure that has actually been deployed and scaled to cloud size has real value to everyone trying to build a cloud. So when a company that has been in the cloud business for a long time in “cloud years” decides to open up and share their software, you have to stop and look.
Last week, Rackspace held an event that brought together a veritable who’s who in cloud computing “to validate the code and ratify the project roadmap”. The sheer size of the summit was a tribute to both Rackspace and those who are looking to advance cloud computing. What I found most interesting was the number of attendees that are potential competitors to Rackspace – other cloud providers or hosters looking at getting into cloud computing. Of course, open source means that anyone can use and improve the code, but the guys at Rackspace inviting these guys and them attending says a lot about the industry. When I talked to Lew Moorman and Jim Curry about this, they said it was simple; they want to compete in the cloud the same way they compete in their hosting business -- with their service. During the design summit, the Rackspace crew stated that they are going to do everything in the open; this means that they are going to put it all out there and not hold back certain pieces as private code. Given this, I really believe that they want to compete on their “Fanatical Support”.
Rackspace and NASA are teaming up to release the source code for implementing a cloud – Rackspace is providing their Cloud Files software for building a scalable object store system and NASA is providing their Nebula code for building a Cloud Server system. The developers from both Rackspace and NASA presented details about their software, lessons learned, and future directions, and then they turned to the attendees to solicit requirements and suggestions. Hot topics included APIs, controls and methods for distributing VMs into the cloud (scheduling), and Networking.
The OpenStack project will utilize the Rackspace API, but will also support API “extensions” so that a number of APIs can be added. It is no surprise that there was desire to support the Amazon API since it is already a “standard” of sorts, and is the primary API for NASA’s Nebula component. The question here is that if the OpenStack software supports multiple APIs for controlling the clouds, what is the true API, and how will OpenStack help drive standards if it supports multiple options?
A lot of companies out there are spending a lot of money and resources to build clouds, and the biggest are rather secretive about how they do it. This is a bold move by Rackspace, NASA, and all of those supporting the effort to drive a fully open project to build the clouds to compete against proprietary solutions. We look forward to more clouds to target both inside the enterprise and in the public domain because we believe that more options will help move everyone closer to a better way of computing – Cloud Computing.
Data Center in a Box
By Damon Miller
Years ago I had the privilege of helping to grow Bladelogic from early-stage startup to a profitable organization of over 300 people. In the early days one of my first challenges was figuring out how to show our product to prospective customers effectively. I needed to show our ability to manage a large IT infrastructure but I had to do so without actually dragging a data center to each of our sales calls. (My first attempt involved renting a fleet of trucks but visitor parking turned out to be a real challenge.) As I look back on that situation now, I realize that CloudSwitch offers a perfect solution to this “data center in a box” problem. In this article I’ll walk through the use case and describe a new CloudSwitch feature, Sample VMs, which makes this possible.
The first step toward a virtual data center is to use virtualization, of course. In late 2001 VMware released the third major version of their Workstation product. Given my demonstration requirement, I bought a copy of Workstation, found the biggest “mainstream” laptop available at the time, filled it with memory, and deployed as many VMs as it would run without completely falling over. Depending on the end user’s patience, that number was somewhere between four and six. While not exactly a world-class data center, the end result served us well for demonstration purposes. It was, however, limited in capacity, slow, expensive, and difficult to maintain.
In retrospect, what we really needed was a way to:
- Quickly start new servers and turn them off when finished;
- Use existing, internal virtual servers or public server images; and
- Connect to these servers as if they were on the local network.
Fast-forward nearly ten years and the first of these points—utility capacity on demand—is all but ubiquitous courtesy of providers like Amazon and Terremark. We of course know this as “the cloud” and companies use it every day for a variety of reasons. The second two points are more interesting.
Today’s cloud providers have implemented their platforms on a particular virtualization solution—and in many cases they’ve customized these solutions to suit the needs of their product offering. This is of course perfectly natural, however one practical effect is that end users cannot simply take their own virtual machines and expect to run them within a given cloud provider’s environment. The reasons vary—different virtualization solution, different underlying hardware, different capabilities—but the end result is always the same: cloud providers will not allow end users to upload custom VMs and run them. For this, CloudSwitch is needed.
One of CloudSwitch’s fundamental benefits is the ability to run customers’ virtual servers in whichever cloud provider is most appropriate, regardless of the underlying implementation details. After deploying our appliance, users can select virtual servers within their internal VMware environment and migrate them to a public cloud provider such as Amazon or Terremark without being forced to modify those servers in any way. No additional software or configuration change is required for this to work. Users literally “point and click” to migrate virtual servers from their data center into a cloud provider.
In many cases, users want to leverage the cloud but don’t want to migrate existing servers. CloudSwitch supports this approach as well. With the recent GA release, CloudSwitch allows customers to select from a set of public “Sample VMs” for access to cloud capacity. Customers can use these sample VMs for a variety of purposes—evaluation, production, or anything in between. Further, since these machines have already been moved into the cloud, starting them is quick and efficient. Current Sample VMs include a stock Centos 5.4 base image, SugarCRM, and BugZilla running on a Windows OS. We’re expanding the list of Sample VMs based on a range of customer use cases, and have plans to include many open source and partner products.
The final point—seamless connectivity—speaks to the way cloud providers offer connectivity to their instances. Today, each provider has chosen a particular network architecture for delivery of their services. For example, if you start a Linux instance in Amazon’s EC2 service and run “ifconfig eth0” you will likely see a 10.x.x.x IP address assigned to the interface. This is because Amazon has chosen the 10.0.0.0/8 private address space for connectivity to customer instances. Other cloud providers use different addressing schemes but regardless these are different and disconnected from what customers are using within their own data centers. Further, secure connectivity to these instances is not convenient and in many cases is not possible. CloudSwitch addresses this problem as well.
As part of the deployment process, CloudSwitch automatically creates a secure overlay network within the chosen cloud provider’s environment. This overlay network extends a customer’s internal data center into the cloud so the cloud-based servers are part of the customer’s data center network. When migrating existing servers into the cloud, end users see no difference; they can SSH or RDP to migrated instances without even realizing that their servers are no longer running within the data center.
So, CloudSwitch offers a way to leverage the power of the public cloud without forcing end users to change the way their infrastructure is configured. We also offer a set of sample content customers can use if they simply want to establish a footprint in the cloud without migrating existing servers. Finally, end users connect to cloud servers just as if they were running within the data center network. The implication for my “data center in a box” use case is probably obvious: I could have installed the CloudSwitch Appliance on my sales engineers’ laptops, created a set of demo servers in the public cloud, and used these for field sales activity. We would have saved money on the laptops but more importantly my team would have been more effective.
Ultimately the cloud is about better service delivery. Better can certainly mean less expensive but in my case better would have meant more effectively expressing the value of our product to prospective customers. Regardless of the definition, CloudSwitch offers a simple, secure, and effective way to leverage the cloud. Since the early startup days in 2001 my goal hasn’t really changed much; I still want the opportunity to show you how our product can make you more effective. The difference is I finally have my “data center in a box” to prove it to you (and I don’t have to take up all of your visitor parking spots).
Is Amazon the Official Cloud Standard?
By Ellen Rubin
The Structure 2010 show was memorable for CloudSwitch, highlighted by the launch of the commercial version of our CloudSwitch Enterprise software that lets companies easily use multiple cloud providers to run their enterprise applications. With a few clicks, users run their applications where they best fit, based on their specific business and technical criteria.
So it certainly got our attention when at the Hybrid Clouds panel, Marten Mickos, CEO of Eucalyptus Systems, made a claim that Amazon’s API should be the basis for an industry standard. Marten added that the industry should orient around Amazon’s approach much as IBM’s personal computer became the standard for the PC industry. (Generations of loyal Mac users are probably glad there was still room for alternatives!)
If there were an industry standard, Amazon certainly has a strong claim for it. They’re the clear leader, with technology second to none. They’ve made huge contributions to advance cloud computing. Their API is highly proven and widely used, their cloud is highly scalable, and they have by far the biggest traction of any cloud. So full credit to Amazon for leading the way in bringing cloud computing into the mainstream. But it’s a big leap from there to saying that Amazon should be the basis for an industry standard.
It’s clear to us that the enterprise market wants options, both to avoid being locked-in and because other cloud providers have much to offer. While Amazon delivers many great benefits, other cloud providers have differentiated based on compliance, service level agreements, dedicated environments, storage capabilities, connectivity options, and support. They’ve implemented their infrastructures and APIs around these areas of differentiation. They’re unlikely to want to adopt a general industry standard since in many ways this commoditizes what they’ve built and limits their innovation.
One of the problems with any cloud standard is that making it work is fraught with controversy and technical complexity. A cloud computing “standard” involves more than a single API or format; it includes a number of elements that together define how the cloud works. For Amazon, this includes the AMI virtual machine format, their EC2 API that defines cloud operations, as well as their storage APIs, which come in two flavors: S3 and EBS. Other clouds have their own set of APIs and formats, developed to reflect their infrastructure characteristics and needs of their target market. VMware, for example, has its vCloud API as well as its own physical machine description (VMX) and storage unit (VMDK). There’s a spectrum of technologies in play that cloud providers and enterprises would first have to agree to, and then do a lot of heavy lifting in order to comply. I have yet to see a compelling reason that would justify their time and cost.
Of course, Amazon isn’t actively promoting a standard, they’re just “doing their thing” — offering their cloud services to whoever is willing to pay for them, and continuing to innovate in the cloud. I suspect they’re content to leave well enough alone and let the market take its course, and we'll continue to see innovations in everything from billing to cloud infrastructure from them.
The irony behind this standards debate is that CloudSwitch technology makes it largely irrelevant. The days when using a cloud meant binding yourself to a provider’s proprietary architecture are over. Cloud providers can innovate for their market segments, and customers can choose the best solution without fear of lock-in. Why go backwards? CloudSwitch customers know better.
