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.

By Ellen Rubin

As we work with dozens of companies that are actively running pilots and doing early deployments in the cloud, it made me think about what the “new normal” will look like in enterprise IT infrastructure. A recent report from the Yankee Group shows that adoption of cloud is accelerating, with 24% of large enterprises already using IaaS, and another 37% expected to adopt IaaS within the next 24 months. It’s clearly a time of major shifts in the IT world, and while we wait for the hype to subside and the smoke to clear, some early outlines of the new paradigm are emerging. Here’s what it looks like to us at CloudSwitch:

1. Hybrid is the dominant architecture: on-prem environments (be they traditional data centers or the emerging private clouds) will need to be federated with public clouds for capacity on-demand. This is particularly true for spikey apps and use cases that are driven by short-term peaks such as marketing campaigns, load/scale testing and new product launches. The tie-back to the data center from external pools of resources is a critical component, as is maintaining enterprise-class security and control over all environments. Multiple cloud providers, APIs and hypervisors will co-exist and must be factored into the federation strategy.
2. Applications are “tiered” into categories of workloads: just as storage has been tiered based on how frequently it’s accessed and how important it is to mission-critical operations, application workloads will be categorized based on their infrastructure requirements. In the end, app developers and users don’t really want to care about where and how the application is hosted and managed; they just want IT to ensure a specific QoS and meet specific business requirements around geography, compliance, etc. The cloud offers a new opportunity to access a much broader range of resources that can be “fit” against the needs of the business. In some cases, the current IT infrastructure is over-provisioning and over-delivering production gear for lower-importance/usage apps; in other cases it’s woefully under-delivering.
3. IT becomes a service-enabler, not just a passive provider of infrastructure resources: IT is now in a position to provide self-service capabilities across a large set of resources, internally and externally, to developers, field and support teams. This requires a new set of skills, as we’ve blogged about before, but the cloud gives IT the opportunity to meet business needs in a much more agile and scalable way, while still maintaining control over who gets to use which resources and how.
4. The channel shifts from resellers to service providers: as noted by Andrew Hickey at ChannelWeb, the opportunities for resellers will need to shift as companies reduce their large hardware and software buys in favor of the cloud. The new focus will be on providing services and consulting with an opex model and monthly payments, and expertise in change management and predictive use models will become core competencies. We’ve already started to see this shift at CloudSwitch with a new crop of cloud-focused consulting/SI boutiques springing up in the market to help CIOs plan their cloud deployments.

For many enterprises, these shifts are still being discussed at a high level as CIOs formulate their cloud strategies. Other organizations are diving right in and selecting a set of applications to showcase the benefits of cloud to internal stakeholders. We’ve been fortunate at CloudSwitch to work with some of the earliest cloud adopters and with our cloud provider partners to help define some of the “new normal.”

By John Considine

We’ve been hard at work over the past two years building the underlying infrastructure for our CloudSwitch software, with the design goal of innovating rapidly on top of this architecture.  The latest release of CloudSwitch Enterprise has proven that we’re able to introduce new capabilities quickly, and provides some insight into features that are on the way.

This release contains some great features and improvements that have been driven by our early customers.  We’ve introduced a feature that has been the #1 request from customers and prospects—public IP access.  To understand the background on this feature, we have to start with the CloudSwitch security model: we’ve designed our system for maximum security when deploying applications to the cloud.  In the earlier versions of our software, this design meant that all access to the machines deployed into the cloud was routed through the data center.  This allowed the customers to utilize their firewalls and rules to govern what happens in the cloud. For many enterprises, this remains the preferred mode for deploying the CloudSwitch solution.  However, many of our customers want to deploy internet-facing applications and are looking to the cloud to help reduce bandwidth constraints within their data centers and improve performance by moving their computing closer to the customers.  By routing all traffic back to the data center, we were neither improving the bandwidth constraints nor were we letting customers take advantage of the geographical distribution of their computing.

What we needed to do was to let our customers control the internet access to their servers in the cloud—which sounds a lot like a firewall.  In keeping with our philosophy of maintaining existing enterprise policies and procedures, we did not want to introduce a new and partial firewall solution into the customer’s environment.  We wanted to allow the customers to deploy existing firewall solutions into the cloud so that they have the knowledge, trust, and control over their cloud resources.  

The new public IP access feature allows the end user to assign a public IP address to one of the interfaces on a standard firewall appliance.  The other interface can be placed on the network LAN for your servers in the cloud.  This allows the customer to define rules, services, and polices for how public internet access is granted to resources in the cloud.  This is immensely powerful – it brings services like VPN access, dhcp, dynamic DNS, proxies, full firewall rule sets, and logging to cloud deployments.  You’re no longer limited to the set of functions that a cloud provider offers for control of firewall resources or load balancers.

A second new feature is the CloudSwitch Library. This is a resource area that contains virtual machines and infrastructure elements that can be deployed to the cloud.  You may have seen the beginnings of this in the June commercial release of our product where we introduced the “Sample VMs” folder.  In the latest release, we have expanded the capabilities of this feature to allow for different types of virtual machines and appliances to be deployed to the cloud.  This release includes a “Network Appliances” folder for network-related infrastructure components –think firewalls, load balancers, and WAN optimizers.  We have included a popular open source firewall and load balancer (Smoothwall + HA proxy) to allow our customers to have access to a full feature firewall solution for the cloud.

The final improvement in this release is the addition of better geographic control over where you want to run your applications in the cloud.  Since we have customers coming not only from all over the US, but all over the world, we have made it easier to select the geography within our user interface.  Users can enable and select these regions quickly and easily to deploy workloads into data centers from Ireland to Virginia to Singapore.  What is really cool to see in our product is a single network spanning all of these data centers and allowing the virtual machines to operate seamlessly, as if they were all local.

CloudSwitch’s unique architecture and our powerful Cloud Isolation Technology™ make it possible to create and deliver these new features quickly.  We’re constantly enhancing our software to make everything “just work” for enterprises in the cloud.

By John McEleney

This weekend I participated my ninth Pan-Mass Challenge, a 192-mile benefit ride for the Jimmy Fund and The Dana Farber Cancer Institute (5,000 riders who will jointly raise $31M).  With approximately 12-plus hours of saddle time, I had plenty of time to think. What struck me, beyond the amazing logistics and incredible spirit of the riders and volunteers, was that this all started with s simple vision of one man—Billy Starr.

His Idea
He had lost his mom to cancer and decided to do an annual bike ride across Massachusetts as a fund raiser for cancer research.

His Vision
Each year we will grow the amount that we give for cancer research. His communication strategy was equally clear: cancer affects everyone, therefore, everyone should want to be involved.

Since he started this journey, he has raised over a quarter of a billion (that’s a “B” as in billion) for cancer research. Today the PMC funds 50% of the research budget at Dana Farber. So what does this have to do with cloud computing and CloudSwitch? Nothing and everything. From a technical stand point, absolutely nothing. From a business standpoint, it has everything to do with cloud computing. Let me explain.

It is easy to be confused about how the future will evolve with cloud computing.  Every day we hear and read the postulations from the optimists that everything will move to the cloud. We are equally confronted with the contrasting views of the fear mongers that nothing will move to the cloud. To get some perspective and a simple view of the cloud world, I think you need to step back and take a broader view of the transformation that is happening.

Every day, people are getting more and more comfortable with the idea that data is located somewhere else (other than on the physical device they can see). Email and facebook are two proof points. Organizations are also getting more comfortable with not having all of their data and/or applications physically in their data center. Just look at the growth of SaleForce and use of raw Amazon compute resources. We recently had a discussion with a senior IT person who pointed out that the finance team wanted to know why the IT people were buying so many books (they weren’t buying books, they were submitting their AWS charges on expense reports!).

We believe the future is clear: the public cloud WILL be part of the IT organization in the future. There may be many obstacles and objections during the adoption process, but the economics and business agility that public clouds provide are so compelling, that organizations will have to adopt them or risk losing competitive advantage.  Our mission at CloudSwitch is to help organizations extend their data centers to the cloud.

If you want to make an impact, you have to be clear about what you are trying to accomplish. Billy was clear with the PMC and he aggressively pursued that goal. At CloudSwitch we are passionate about helping companies embrace the cloud. Our vision is clear—we think that the cloud will help businesses become more agile and we think we have a role to play in making this happen.  Try CloudSwitch today.

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.

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.

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.

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:

1. Quickly start new servers and turn them off when finished;
2. Use existing, internal virtual servers or public server images; and
3. 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).