Virtualization
Top 5 Questions Asked by CloudSwitch Customers
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Dave Armlin, Director of Customer Support
New CloudSwitch customers and prospects are coming up to speed every week and there are a number of questions that show up frequently enough that I thought it would be helpful to cover them in a blog. When we work with customers, our goal is to make their experience getting started in the cloud fast and easy, and to make sure they feel comfortable with the ongoing simplicity and security of the CloudSwitch model.
Here are their top 5 questions:
1. How do I move applications to the cloud?
CloudSwitch literally makes moving an application to the cloud a simple drag-and-drop operation. A virtual machine (or group of VMs) is selected from a VM location (vCenter,ESX machine, or CIFS share) in the CloudSwitch user interface, the target public cloud region/zone/location is selected, and the machine is moved over a secure tunnel to the cloud. Storage for the virtual machine in the cloud is automatically allocated and encrypted, and keys are kept under the customer’s control.
Virtual machines that are moved to the cloud retain their MAC and IP addresses, since the CloudSwitch appliance acts as a layer-2 bridge allowing these machines to appear as if they are running in the data center behind your firewall.
2. What applications should I move to the cloud?
A wide variety of apps are good candidates to be moved to the cloud. As Ellen Rubin blogged about recently, legacy applications are certainly great candidates for offloading from your internal data centers. Web servers and web applications like SharePoint, .NET, J2EE/SOA, Drupal, Wordpress, Wikis, corporate intranets, or batch processing applications are all good candidates as well.
When selecting applications for the cloud, you need to be aware of latency between the data center and the cloud. Latency is a function of physical distance between the data center and the cloud region you’ve selected. For instance, a data center on the East Coast in the US should see around 20ms latency between the various public cloud regions on the East Coast.
Select applications and place them in closest proximity to the virtual machines and data center services that are accessed most by these applications. For instance, a web application that utilizes a database heavily may perform best if the web tier and the database are both deployed to the same cloud and region. A web application that utilizes a database infrequently and caches results may perform well with the database in the data center and the web tier in the cloud.
3. What changes to my network do I have to make to use CloudSwitch?
Minimal. Outbound port 443 to the Internet has to be opened for the CloudSwitch appliance to create a secure encrypted connection to the cloud. This is outbound traffic only, nothing inbound. There are no changes to your network configurations.
The CloudSwitch appliance requires promiscuous mode and forged transmits set to “Allow” on the Virtual Switch or Port Group for the network adapter assigned to CloudSwitch in your virtual environment. For more information, check out this blog article on networking and ESX.
4. Can I get a virtual physical console to my machine in the cloud?
Yes. CloudSwitch provides a virtual console accessible from the CloudSwitch user interface via a browser that allows you to interact with the base system to make network changes or other tasks one might perform at a physical console. Access to this console can be secured to specific users or groups using Role-Based Access Controls (RBAC) in the CloudSwitch user interface.
5. Can I allow traffic from the Internet reach my machines in the cloud directly as opposed to going through my corporate firewall?
Yes, CloudSwitch supplies a cloud firewall that allows you to assign a public IP to a virtual machine and control access to VMs in the cloud from the Internet. Pavan Pant, our Director of Product Management, blogged about this a while back. You have full configurability for permissions/access to all cloud resources through this firewall.
Cloud Wars Heat Up
By John Considine
Last week I wrote about the Cloud.com acquisition and what it means for Citrix, Rackspace, OpenStack and the industry. Next, I’d like to dig into the VMware announcement about their cloud infrastructure suite. Citrix clearly wanted to announce their news just prior to VMware’s, and for a good reason – Citrix is hitting VMware in a weak spot of their cloud strategy. It’s pretty clear that VMware is not getting the vCloud adoption they were anticipating from service providers and even enterprises.
In Paul Maritz’s presentation, he mentioned that VMware “…has been working closely with service providers because you need the same stacks on both sides [the private cloud and public cloud] to be able to ‘slide’ applications to the cloud…and back again.” At CloudSwitch we are dedicated to the notion that you don’t have to have identical infrastructure stacks between the data center and the cloud. You have to expect that what a cloud provider chooses will not necessarily be the same as what the enterprise has chosen, or that they will work together in lock-step. VMware seems committed to the strategy that they will provide the complete solution on both sides of the cloud, and that all parties will work together to stay coordinated. This is very different from Citrix’s positioning around more open and heterogeneous solutions.
Citrix and VMware have been competing in the virtualization space for years with a battle of features (mostly Citrix catching up with VMware and trying to gain share in the enterprise virtualization market), but the scope of the competition has been growing thanks to cloud computing. Cloud computing expands the server virtualization fight from hypervisor features to integrated stacks for deploying/managing infrastructure. The hypervisors remain important, but the new frontier contains everything from core networking to storage management, to large scale deployments to self-service IT. In this new battle, Citrix has some real strength in networking (Netscaler, etc.) and application delivery, and with their Cloud.com acquisition, they are capturing some proven orchestration technologies.
VMware is investing huge resources to expand their cloud offerings (Maritz claims a million man hours). Their focus is on adding features to their hypervisor and layers to their stack (vSphere+vCenter SRM+vCenter Operations+vShield+vCloud Director). They have lots of expertise in this area and direct interaction with enterprise customers and requirements. On the service provider side, they are dependent on feedback from VMware-based partners to provide input and learn how to build and run large-scale infrastructure clouds. We’ll have to see how this approach plays out vs. Citrix’s CloudStack.
In the end, this competition is great for all of us as well as for CloudSwitch specifically. The competition in the cloud space will continue to drive innovation, new features, and simplification of deployment for this great new platform called cloud computing. CloudSwitch is all about choice and giving enterprises control and flexibility in their cloud architectures. As the world of cloud computing evolves, we love to see different options, technologies, and capabilities – because a world filled with different cloud choices needs a CloudSwitch to connect all of the pieces.
Now Everybody Wants a Cloud Gateway
Part 1 of a 2-Part Series
By Ellen Rubin
In our discussions with industry insiders, we’re hearing more and more about the need for a cloud gateway — technology that provides a bridge between an organization’s internal environment and one or more public clouds. It’s a message we’re also hearing with growing frequency from enterprise customers and potential partners alike as their cloud architectures mature. In the first post of this series, I’d like to look at what’s behind this trend, and why different stakeholders are making the cloud gateway a top priority.
First of all, it’s another clear signal that cloud computing is becoming mainstream. We’re well past the stage where every cloud deployment is a one-off reengineering project to enable an enterprise application to run in a public cloud. Organizations are no longer willing to tolerate the delays and costs in order to reap the benefits, and now they don’t have to. The gateway simplifies the integration and management of cloud resources so people can get on with using the cloud rather than struggling to make it work.
It’s also connected to the emergence of hybrid clouds that allow enterprises to use cloud resources while leveraging their internal infrastructure. There’s broad consensus that the hybrid model, with pools of internal and external resources federated together, is the best way for large and mid-size enterprises to do cloud computing. Now they’re urgently looking for efficient ways to bring the hybrid cloud to life. They want to be able to turn resources on and off for spiky apps or short-term projects, and a multitude of use cases where workloads flow where they best fit when a threshold is reached. By enabling on-demand access to public clouds with tight integration to data center services, the cloud gateway does the heavy lifting so enterprises can work across these different environments.
We’re also seeing growing momentum from technology vendors, who recognize that the cloud provides an opportunity to move beyond the internal data center, which has become highly commoditized. Much of the demand is coming from network technology companies that provide things like load balancing, firewalling, WAN optimization, and storage optimization — all those capabilities that are normally part of a company’s internal infrastructure. Dozens of established and emerging vendors in this space are looking for ways to move beyond this traditional market, and see the cloud as unclaimed territory. A cloud gateway opens up an exciting new market for these vendors while allowing them to leverage internal technologies (preferably theirs) that customers already have.
A cloud gateway has also become a top priority for providers of virtualization solutions, for many of the reasons mentioned above. The hypervisor has become a commodity as the market has matured and more vendors have introduced competing hypervisor offerings, sometimes for free. Most virtualization players now realize they can’t win with their hypervisor alone. The focus has shifted, and they’ve been trying to move up the virtualization stack by promoting their higher-level management capabilities — competing on things like self-service, charge-back, fault tolerance, resource scheduling, load balancing, etc.
For virtualization vendors, the cloud represents an opportunity, but also a direct threat to their on-premise footprints. They’re urgently exploring how to extend their management functionality into the cloud so they can preserve and capture market share. The ability to span the data center and multiple public clouds, orchestrating between internal and external worlds, is where the new virtualization battles are being fought, and where the cloud gateway is one of the leading weapons.
The cloud gateway has become essential as companies incorporate cloud computing into their business and IT strategies. It’s a message we hear over and over in our discussions with corporate CIOs as well as with executives from technology firms. The next post will examine what characteristics different stakeholders should look for in a cloud gateway in order to be successful.
Coming Up Next: What to Look For in a Cloud Gateway
Image Conversion and VM Imports in Amazon
By John Considine
Yesterday Amazon announced another important tool in their ongoing platform innovation for EC2 – the VM Import tool. This converter allows you to “bring your VMware images to the cloud.” As we’ve seen extensively at CloudSwitch, this is a primary use case for most enterprises – the ability to take images you’ve already built (likely in VMware) and migrate them into the cloud. It’s great to see Amazon continue to innovate around these gaps in their offering, as this continues to drive the overall market growth and enterprise adoption. But it’s important to understand what this means for enterprises as they begin to move their workloads.
Enterprises do not want large engineering projects to be required as a step to the cloud. They want solutions that “just work” and allow them to focus on their applications and business – NOT their VM’s. They also need their cloud-based resources to remain completely unmodified in terms of the application stack (down to the lowest level of operating system) because their fundamental goal is for all the business processes around the application to continue to run independent of location.
Here are some critical requirements for image migration that we address TODAY at CloudSwitch – that can’t be addressed by simple image conversion:
- Maintaining the fundamentals of your operating system:
- No changes to the content of your operating system or applications
- No changes to the system registry
- Full system security:
- Automatic encryption of all data and communications
- No disabling of anti-virus, intrusion detection, or other protection systems
- No enabling of remote services (e.g., RDP) that potentially expose your apps to attackers
- Simple, enterprise-standard management:
- Management of all VM attributes (e.g., VMX, OVF, vApp…)
- No additional software in your OS images
- No changes to internal processes for building and managing VM’s
- No re-architecting of your networking or storage configurations
- No dependence on a cloud provider for your operating system selection, upgrades and patches
So where does this position the new VM Import converter from Amazon? It’s an important step along a much larger process of making EC2 become “enterprise-class,” or at the least, “enterprise-viable.” What’s needed is for the partner ecosystem around EC2 to build out the missing elements based on a deep, long-standing knowledge of enterprise needs and processes. At CloudSwitch, given our intense focus on enterprise requirements and team of experts in enterprise complex systems and software, we believe there is a very high bar to truly meeting the needs of the enterprise in the cloud. Beyond the underlying physical security, compliance and legal/procurement processes that cloud providers must address to be widely adopted, there are “tactical” issues around things like image migration that turn out to be far more complex than you’d think at first glance.
The key understanding of true enterprise needs is this: even small changes at the VM level can have major implications for application deployment, management, security and compliance. Enterprises care deeply about these issues and don’t want to adapt their processes to the cloud – they want the cloud to adapt to their needs. The Amazon VMware converter broadens the platform for developers in the cloud – this is good for the entire cloud industry. But if you want to run your enterprise applications in the cloud securely and without any modification or changes to your internal processes then you need CloudSwitch.
CloudSwitch Enables True Cloud Federation
By Pavan Pant
As with any transformative technology that is new to the market, both public and private clouds have generated massive amounts of hype, bold predictions, a whole lot of confusion and raging debates amongst the cloud cognoscenti. Opinions vary across the spectrum with some experts claiming that data centers will be rendered obsolete by the public cloud, while others are dismissive of the public cloud but support private clouds. It’s clear to us at CloudSwitch that a more likely scenario lies squarely in the middle of those two extremes. This week at VMworld (where we were exhibiting with our partner, Terremark), we were pleased to hear that VMware believes that “hybrid cloud is the tide coming in.” From Paul Maritz’s keynote through many sessions and product announcements (including the release of the long-awaited vCloud Director), the message was all about hybrid clouds.
One of our previous blog posts discussed the notion of hybrid clouds and the fact that most enterprises will follow such an approach in the future. Amazon, Terremark, Rackspace, Savvis, Blue Lock and other public cloud providers give customers elasticity, better service delivery and low CapEx costs. Meanwhile, there are solutions such as Eucalyptus and VMware’s vCloud Director that provide the interface and management tools to help organizations build private clouds while interfacing with public clouds to create hybrid cloud models.
Both use different APIs for their hybrid models with Eucalyptus delivering tight integrations for EC2 using Amazon’s APIs and VMware vCloud Director working with vCloud DataCenter Services (VMware’s terminology for public cloud providers) such as Terremark that leverage vCloud APIs. However, these technologies do not assist with creating an environment that spans hypervisors and cloud providers without changing the applications. If customers build private clouds that are not using the same virtualization infrastructure as their preferred public clouds then what does it really mean to hybridize their clouds?
Consider a scenario where a customer builds a private cloud using Eucalyptus or VMware vCloud Director. That private cloud still ends up being different from your data center (much like a public cloud) - the networking may be different, versions of virtualization technology may be different and the storage infrastructure may be different. All this means that applications in the data center will need to be changed before moving to the private cloud. As an example, if your QA team runs servers on their own subnet in the data center how can this be transitioned to a private or public cloud without incurring additional costs to change those servers?
CloudSwitch’s core value proposition lies in the ability to securely transport a customer’s existing virtual infrastructure to the cloud provider of their choice, independent of the provider’s underlying virtualization infrastructure (VMware, Xen, etc.). This effectively allows customers to securely move and operate servers from their data center across hypervisors to private cloud providers without requiring them to make any modifications to their application – we maintain the same IP address, MAC address, storage controllers, subnet information, etc. Once customers have moved their servers to the cloud they can operate and manage them just as they would in their data center. CloudSwitch has an intuitive web based interface which gives customers server lifecycle management options such as start, stop and clone.
Similarly, if customers have a private cloud which uses either Eucalyptus or VMware vCloud Director CloudSwitch can speak to those APIs and facilitate the transfer and management from these private clouds to public clouds. This enables a hybrid model where private clouds leverage public clouds for spikes in usage (cloudburst), or lab-on-demand use cases for training and POCs. CloudSwitch does all the work of integrating the environments across these private and public cloud hypervisors, merging networks and transferring servers without modifying them in any way.
Many years ago, I had the privilege to work on the first iterations of RSA’s identity federation product both as an engineer and as a product manager. Federated single sign on enabled the portability of identities across security domains and allowed for the secure exchange of sensitive data outside the firewall without requiring any changes to the identity itself.
While the markets for Identity Management and cloud computing are unambiguously different, the notion of federation to make portability and interoperability easier for enterprises is a common theme. CloudSwitch is in a unique position to help enterprises with true cloud federation by moving workloads seamlessly from the data center to the cloud (private or public), between private and public clouds (hybrid), across public clouds and back to the data center without requiring customers to make any changes to their applications. Regardless of the starting point, CloudSwitch offers customers an easy, effective method to leverage the benefits of the cloud while ensuring portability across clouds.
Do VMs Still Matter in the Cloud?
By John Considine
There’s a long running debate about the true role of Virtual Machines (VMs) in cloud computing. In talking with CTOs at the large vendors as well as the “Clouderati” over the last two years, there seems to be the desire to eliminate the VM from cloud computing. A colleague of mine, Simeon Simeonov, wrote a blog a couple of weeks ago that made the case for eliminating the VM. While the argument is appealing, and there is growing support for the idea, I’d like to argue that there are compelling reasons to keep the Virtual Machine as the core of cloud computing.
Virtual Machines encompass “virtual hardware” and very real operating systems. VMs drive the economics and flexibility of the cloud by allowing complete servers to be created on-demand and in many cases share the same physical hardware. The virtual machines provide a complete environment for applications to run – just like they would on their own individual server, including both the hardware and operating system.
Sim and other cloud evangelists would like to see applications developed independent of the underlying operating systems and hardware. Implied in this argument is that developers shouldn’t be constrained anymore by an “outdated” VM construct, but should design from scratch for the cloud and its horizontal scalability. This reminds me of early conversations I had when we were just starting CloudSwitch that went something like: “If you just design your applications to be stateless, fault tolerant, and horizontally scalable, then you can run them in the cloud.” The message seemed to be that if you do all of the work to make your applications cloud-like, they will run great in the cloud. The motivation is cost savings, flexibility, and almost infinite scalability, and the cost is redesigning everything around the limitations and architectures offered by the cloud providers.
But why should we require everyone to adapt to the cloud instead of adapting the cloud to the users? Amazon’s EC2 was the very first “public cloud” and it was designed with some really strange attributes that were driven from a combination of technology choices and a web-centric view of the world. We ended up with notions of “ephemeral storage” and effectively random IP address assignment as well as being told that the servers can and will fail without notice or remediation. These properties would never work in an enterprise datacenter; I can’t imagine anyone proposing them, much less a company implementing them.
But somehow, and this is what disruption is really about, it was OK for Amazon to offer this because the users would adjust to the limitations. The process began with customers selecting web based applications to be put in the cloud. Then a number of startups formed to make this new computing environment easier to use; methods of communicating the changing addresses, ways to persist storage, methods of monitoring and restarting resources in the cloud, and much more.
As cloud computing continued to evolve, the clouds started offering “better” features. Amazon introduced persistent block storage (EBS) to provide “normal” storage, VPC to allow for better IP address management, and a host of other features that allow for more than just web applications to run in the cloud. In this same timeframe a number of cloud providers entered the market with features and functions that were more closely aligned with “traditional” computing architectures.
The obvious question is what is driving these “improvements”? Clearly the early clouds had captured developers and web applications without these capabilities – just look at the number of startups using the cloud (pretty much all of them). I’d assert that the enterprise customers are driving the more recent cloud feature sets – since the enterprise has both serious problems and serious money to spend. If this is true, then we can project forward on the likely path both the clouds and the enterprises will follow.
This brings us back to the role of the Virtual Machine. Enterprises have learned over the years that details matter in complex systems. Even though we want to move towards application development that doesn’t touch the hardware or operating systems objects, we must recognize that there is important work done at this level – hardware control, the creation and management of sockets, memory management, file system access, etc. No matter how abstract the applications become, there is some form of an operating system that works with these low level constructs. Further, changes at the operating system level can affect the whole system – think Windows automatic updates, Linux YUM updates, new packages or kernel patches have caused whole systems to fail; this is the reason that enterprises tightly control these updates. This means in turn that the enterprise needs to have control of their operating systems if they want to use their software and management policies, and the way that you control your operating system in the cloud is with VMs.
Enterprise requirements are driving the evolution and adoption of the cloud and this will make the use of VMs even more important than it has been to date. Cloud providers know that enterprise customers are critical to their own success and will make sure that they deliver a cloud model that feels familiar and controllable to enterprise IT and developers.
P2C: A Funny Thing Happened on the Way to the Cloud
By 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.
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.
Hubs, Spokes and WANs
By Ellen Rubin
Recently, we’ve had a number of discussions with enterprises about how they’d like to use the cloud. The basic use case is around capacity on-demand (not surprisingly), but the specifics have raised some interesting issues. The companies have distributed branch offices that need the capacity for a range of applications, including dev/test environments as well as back-office and web apps. Today, these distributed groups are relying on corporate IT to meet their scaling and infrastructure needs, and they are frequently bottlenecked. This is both in terms of overall challenges in getting new capacity approved in a timely way, but also from a network bandwidth perspective. At a panel this week at Interop, Riverbed noted that 2/3 of their enterprise customers have a hub and spoke model that requires the “spokes” to backhaul to the “hub” for connectivity to the internet, and thus to cloud computing services. Only the remaining 1/3 have direct connections. At the same panel, Blue Coat agreed with the stats but commented that the branch sites are trending towards a direct-connect model as new sites are added.
All this is interesting to us at CloudSwitch since we have been hearing more and more frequently from enterprises that want more “edge” computing, and to empower the branch offices to add capacity on-demand in a controlled but self-service way. This creates a set of new requirements around cloud computing, in terms of both networking and security. In the hub and spoke model, corporate IT maintains control over all access to the cloud, which has benefits on the security and permissions side, but creates potential bottlenecks – both in terms of the need for self-service management tools to increase agility, as well as in bandwidth constraints where the backhaul traffic starts to strain the corporate networks. Backhauling also creates strain on the branch offices since it often adds significant latency to their internet connections.
Most of the vendors at the Interop panel (including Akamai, Riverbed, Ipanema and Blue Coat) claimed to be developing or are already offering WAN optimization products – increasingly in the form of virtual appliances and/or software versions – to help alleviate these bottlenecks. These will surely help, but will become even more important as the branch offices start to have more direct connectivity to the cloud. WAN optimization offerings at the “edge” will be increasingly needed, and cloud service providers are focused on building out these capabilities at their end of the network. Security in a more distributed model will also require some new thinking, since users in the branches will want to maximize flexibility and agility, while corporate IT will still need a way to limit potential threats and exposure created by opening these direct connections.
Underlying all these discussions is the fundamental issue of the laws of physics. As enterprises start to embrace the cloud model, they’ve realized that the major choke-point will be their network bandwidth. Innovation around addressing these issues, especially in the virtualized world of the cloud, will definitely be required. At CloudSwitch, we’re staying closely involved in discussions around customer requirements and vendor offerings to increase performance for workloads moving to the cloud.
