Public Cloud
OpenStack - Advancing Cloud Computing in the Open
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy 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).
Private Clouds: Old Wine in a New Bottle
By John McEleney
I recently read a Bank of America Merrill Lynch report about cloud computing, and they described private clouds as "old wine in a new bottle." I think they nailed it!
The report points out that a typical private cloud set-up looks much the same as the infrastructure components currently found in a corporate data center, with virtualization added to the mix. While the virtualization provides somewhat better server utilization, the elasticity and efficiency available in the public cloud has private clouds beat by a mile.
In short, the term "private cloud" is usually just a buzzword for virtualized internal environments that have been around for years. By replicating existing data center architectures, they also recreate the same cost and maintenance issues that cloud computing aims to alleviate.
Despite their limitations, there is still a lot of industry talk about creating internal private clouds using equipment running inside a company’s data center. So why do people consider building private clouds anyway?
To answer this question, you have to step back and examine some of the fundamental reasons why people are looking to cloud computing:
- The current infrastructure is not flexible enough to meet business needs
- Users of IT services have to wait too long to get access to additional computing resources
- CFOs and CIOs are tightening budgets, and they prefer operational expenses (tied directly to business performance) vs. capital expenses (allocated to business units)
In every case, the public cloud option outperforms the private cloud. Let’s examine each point:
- Flexibility – the ability to access essentially unlimited computing resources as you need them provides the ultimate level of flexibility. The scale of a public cloud like Amazon’s EC2 cannot possibly be replicated by a single enterprise. And that’s just one cloud – there are many others, allowing you to choose a range of providers according to your needs.
- Timeframes – to gain immediate access to public cloud compute resources, you only need an active account (and of course the appropriate corporate credentials). With a private cloud, users have to wait until the IT department completes the build out of the private cloud infrastructure. They are essentially subject to the same procurement and deployment challenges that had them looking at the public cloud in the first place.
- Budgets – everyone knows that the economic environment has brought a new level of scrutiny on expenses. In particular, capital budgets have been slashed. Approving millions of dollars (at least) to acquire, maintain and scale a private cloud sufficient for enterprise needs is becoming harder and harder to justify — especially when the "pay as you go" approach of public clouds is much more cost-effective.
There are many legitimate concerns that people have with the public cloud, including security, application migration and vendor lock-in. It is for these reasons and more that we created CloudSwitch. We’ve eliminated these previous barriers, so enterprises can take immediate advantage of the elasticity and economies of scale available in multi-tenant public clouds. Our technology is available now, and combines end-to-end security with point-and-click simplicity to revolutionize the way organizations deploy and manage their applications in public clouds.
Sir Isaac Newton may not have dreamed about clouds, but his first Law of Motion, "a body at rest tends to stay at rest", has been a good harbinger of cloud adoption until now. It is fair to expect that people will grasp for private clouds simply because it’s more comfortable (it’s the status quo). However, the rationale for public cloud adoption is so compelling that a majority of organizations will choose to embrace the likes of Amazon, Terremark, and other clouds. As adoption increases, private clouds will be used only for select applications, thus requiring far fewer resources than they currently demand. We’re also seeing the emergence of “hybrid” clouds that allow customers to toggle compute workloads between private and public clouds on an as-needed basis.
In the end, we will have new wine and it will be in a new bottle. With CloudSwitch technology, 2010 is shaping up to be a great vintage.
True Isolation Makes the Public Cloud Work Like a Private Cloud
By Ellen Rubin
Security is always mentioned as a key factor limiting cloud adoption, but what does “security” really mean in the cloud? To understand the potential risks of cloud computing—and how to address them—we need to be more specific. Once we’ve accurately defined the problems, we can address them with the right technology and processes.
When you get into specifics with CSOs and risk managers, security concerns in the cloud can essentially be boiled down to two main issues:
- It’s a shared environment: In a multi-tenant public cloud, you’re sharing resources—servers, cloud networks, and storage—with other companies (possibly even a competitor). Obviously you don’t want them to get access to your data and applications. In this shared environment, data needs to be encrypted, which means you have to develop and deploy an encryption solution that can span the data center and cloud services, and run across a range of operating systems and applications — something that many IT managers and CSOs find outside their comfort zone.
- It’s outside enterprise control: You have to depend on the cloud provider’s security measures, policies, and assurances that your data will not fall into the wrong hands. This can be a non-starter especially given that some aspects of cloud environments are opaque. Loss of control also has another aspect: the cloud provider can make changes to their environment (kernels, storage, software, etc.) that could disrupt the trusted security processes and models that you already have in place.
These are the potential risks that enterprises are anxious to avoid. Therefore they make compromises that allow them to gain at least some cloud capabilities, while maintaining an acceptable level of security. They may choose to partner with a managed service provider to build and manage a dedicated environment for their applications. Or they may pull back completely and build an internal cloud, with applications sharing a pool of resources inside the corporate firewall. But these private cloud models only hint at the agility, efficiency, and on-demand performance available within a public cloud.
Isolation in the Cloud
So how can you incorporate a multi-tenant public cloud in your IT computing strategy without taking a big risk? For an application to run safely in a public cloud, it needs to be isolated from the environment around it at all times. This isolation is not just a matter of keeping things in (protecting data and applications from threats or prying eyes), but also keeping things out (unwanted changes by the cloud provider that could compromise your existing security processes). With our Cloud Isolation Technology, CloudSwitch provides the two-way protection that makes the cloud safe for enterprise use.
How does this isolation layer work? CloudSwitch software automatically builds a secure envelope that extends from the data center to a target cloud that encompasses your entire cloud deployment. Within this envelope, applications and data are encrypted end to end, from inside the corporate firewall, across the Internet, and within the cloud environment—in storage (at rest), during processing, and in transit through the cloud network. Encryption keys are stored within the enterprise data center and are securely transmitted to the cloud only when they are needed and are completely contained within the isolation layer. Control of encryption keys, and thus, control of the data, stays with the customer at all times. Cloud providers have no access to enterprise data at any point—and neither does anyone else.
Inside the secure envelope, the isolation layer maps cloud resources (processors, memory, storage, etc.) to match the execution requirements of the original server. Using this approach, servers and applications run in a cloud “as is” without requiring modification or redesign, and without having to worry about the cloud provider’s configuration or changes to their environment. Further, since all data entering the cloud provider’s environment is encrypted with customer-controlled keys, the data is isolated from processes and changes implemented by the cloud provider. The cloud becomes an integral part of the enterprise IT environment, while the cloud provider sees only an encrypted connection running into one of its servers, and encrypted data flowing to the storage devices.
Agility + Security: Taking Control in the Cloud
Using CloudSwitch technology, the same level of privacy and control that you would expect in a dedicated environment now becomes available in a multi-tenant public cloud. Companies can take full advantage of cloud elasticity and cost savings without being exposed to the inherent risks. True isolation lets you have your cake and eat it too—reaping the benefits of cloud computing (agility and reduced cost) while maintaining enterprise security and control.
The Hidden Costs of Internal Clouds
By Ellen Rubin
A public cloud can provide access to computing resources that many companies would otherwise never be able to afford. The arguments for the cloud are well-known by now, but remain compelling—no up-front costs, virtually unlimited computing power on demand, and highly efficient pricing where customers pay only for resources used. There’s also less pressure on corporate IT departments that are charged with managing the infrastructure and budgeting for new equipment to keep up with demand.
But concerns about security and loss of control in public clouds have led to an alternative model—the internal cloud—that replicates the cloud environment inside the corporate firewall. Within these boundaries, enterprise users can provision computing resources as needed, using the cloud’s self-service capabilities while leveraging data center services. Internal clouds are often referred to as private clouds, but since private clouds can also be found in external environments, the “internal” designation is a more precise term for what we’re talking about here. (RightScale's blog post provides helpful definitions of the different cloud variants.)
With servers, applications and data within the enterprise walls, internal clouds can provide many of the benefits of cloud computing without the potential risks when the computing environment is provided by a third party. Unfortunately, the economics of internal clouds makes them inherently less efficient than the public cloud, especially as new technology makes the public cloud safer and more reliable. Here are some of the reasons why:
- Infrastructure costs: Deploying an internal cloud requires building out the infrastructure to support the needs of all enterprise users. In addition to acquiring the necessary hardware and software, this includes things like configuring the network, allocating storage, paying the electric bill, and providing square footage for the equipment. Plus, all of this infrastructure has to be managed and supported on an ongoing basis.
- Over-provisioning: Just as with traditional IT infrastructure, anticipating resource requirements for an internal cloud is difficult since applications run at varying usage levels. Some applications consume resources fairly steadily while others require occasional bursts of massive computing power. Companies may have no choice but to over-provision, where some equipment sits idle most of the time in order to have resources available for peak periods. (Meeting these short-term usage needs is one example where the elasticity of public clouds really pays off.)
- Building the management plane: As Jon Brodkin points out, building an internal cloud is about more than just virtualization. One of the key benefits of cloud computing is the self-service aspect, where users can access resources as needed via a self-service portal, which then execute in the cloud automatically without administrator intervention. Building this control plane is another substantial step when implementing an internal cloud.
For all of these reasons, the internal cloud carries a cost overhead compared to leveraging the resources and self-service framework already provided by public clouds. Ironically, much the same protection and control offered by internal clouds is becoming increasingly available in an external public environment. So enterprises may find that a public cloud may provide a more cost-effective home for many (or even most) of their applications.
Internal clouds can make sense for the most business-critical requirements or those that need specialized hardware or have regulatory compliance issues. Focusing internal resources on these types of applications would greatly reduce the investment required to build, sustain and grow enterprise infrastructures. While some applications may always need to run internally, many companies have dozens of others that could run more cost-effectively today in a public cloud, providing computing power on demand along with required security, agility and scalability.
At CloudSwitch, we provide technology that allows companies to take full advantage of the resources and savings that the public cloud has to offer, while integrating seamlessly with their internal environments. Applications deploy automatically, are free from lock-in, and stay tied into internal data center services. In short, the enterprise gets the protection and control formerly found only behind the firewall, and can combine the best of internal and external cloud offerings with maximum agility and value.
