CloudSwitch is a Boston-based cloud computing start-up that raised $15.5 million in two rounds from Matrix Partners, Atlas Venture, and Commonwealth Capital Ventures. The company generated quite a buzz after convincingly winning launch pad competitions at the Cloud Connect Conference
in Santa Clara back in March and then again at the Structure 2010 ConferenceD in San Francisco a few weeks ago.
CloudSwitch’s innovative software solution enables enterprises to on-ramp their existing applications to the right cloud computing environment securely, simply and without changes. The company spent the past year testing its software with a number of paid Beta engagements and officially launched the commercial version of their enterprise software at the Structure 2010 Conference.
Ellen Rubin is the Founder and Vice President of Products at CloudSwitch. Prior to founding CloudSwitch, Ellen headed Marketing and third party technology partnerships at Netezza. Ellen’s 6+ years of experience at Netezza spanned right from the prototyping/conceptual phase, through to the launch phase of a high-performance, low-cost data warehousing product, all the way to a successful IPO of the company. Along the way, she learned first-hand all about the complexity of managing data-center infrastructure and the associated operational challenges of IT people in mid-tier companies and in the world’s largest global enterprises. In early 2008, Ellen realized cloud computing has the potential to solve some of the pressing productivity and cost issues facing data center people and worked with Matrix Partners on the idea of starting a new company in this space. Matrix introduced Ellen to John Considine
(Founder, CTO) who was Director of the Platform Products Group at Sun Microsystems, where he delivered a number of advanced virtualized storage systems. At Sun, John had seen first-hand the early cloud computing infrastructure being developed and realized there was a huge opportunity for the enterprise market. Ellen and John joined hands to incubate CloudSwitch, brought in series A funding and the initial team, then added John McEleney to scale out the company — and the rest is history.
I spoke with Ellen about the drivers behind the evolution of the Infrastructure-as-a-Service (IaaS) model (the layer of the cloud stack CloudSwitch currently addresses) and about customer concerns and pain points as they make the switch to IaaS and the Cloud. Ellen also shares valuable insights about what types of workloads customers are moving to the cloud, the target markets they are going after, interoperability and cloud standards, and some lessons learned on their journey towards building a cloud computing company from the ground-up.
Here are some excerpts from the conversation:
What were the driving factors behind the evolution of the IaaS industry and where do you see this market heading?
From a market perspective, I think we are at a very interesting time. There’s been clearly an evolution over the past decade in terms of companies becoming more comfortable with outsourcing and the hosted model. Companies are also steadily growing their virtualization footprints (which we believe is a key enabler for the cloud) within enterprise data centers. But the biggest breakthrough happened at the service management layer which enabled greater efficiencies, scalability, on-demand self-service, and measurement and billing for resources consumed.
Building all of this service management capability is complicated and takes a lot of technical wizardry behind the scenes. We have seen in the past couple of years IaaS providers wrestle with gaps and strains in their underlying architecture as a consequence of giving control and hands-on access to customers. For example, these providers discovered that the way they designed their storage architecture may be constraining for some customer use cases or the choice of their hypervisor may be causing scalability issues and so on. So it is an iterative learning process and the cloud providers are rapidly reducing these gaps and responding to market and customer needs.
What problem(s) is your technology solving for customers?
We focused on solving the three key problems in the founding days of CloudSwitch:
Security Security isn’t the reason that people will go to the cloud, but it certainly is a good reason why they won’t go to the cloud. When we got funded, we went out and talked to a number of enterprises and we found that we got very quickly engaged with the Chief Security Officer. Clearly, Security is a #1 concern. The customer is expecting that the security of the cloud is at least equivalent to the security they get in a colocation (“colo”) environment since they already accepted the fact that colo security is good enough for them.
Keeping applications and management systems unchanged Customers don’t want to change anything when they move to the cloud. The ideal scenario is when applications in the cloud look and behave exactly like their counterparts within the datacenter. We wanted to tackle the key question: How do I make it possible that customer’s applications and management tools don’t have to change at all? Customers should be able to use all of their existing infrastructure tools, networking architecture, security policies, active directories, firewalls, CDN systems, identity management systems, load balancers, and so on to interoperate seamlessly — and securely — with the applications in the cloud as if they are running locally.
Lock-in We also wanted to squarely address the lock-in issue and make it easy for customers to bring back the application to their data center or move it to a different cloud, should they choose to do so. Customers may want to do this for a variety of reasons: they may not be happy with the service or cost structure of their cloud provider, or perhaps they are a point in their lifecycle where they want to run their production applications with specific security controls and/or on specific hardware within their own data centers.
We set out to solve the above problems at the basic fundamental level and built our core Intellectual Property (IP) such that customers can run what they have in the cloud so that it appears as if it is still running in the data center while being completely agnostic to the cloud provider or the hypervisor technology.
Performance and Latency More recently, we also started hearing with increasing urgency concerns about performance and latency, particularly from customers who are running production systems in the cloud. These customers are looking for solutions around load balancing and WAN optimization in the cloud. We have been focusing pretty intensely on these issues now and are in discussion with load balancing, firewall, and WAN optimization vendors about how to take their software solutions and deliver them in the cloud through CloudSwitch. Stay tuned for more news from us in this area. Again, this goes back to what I said earlier, most companies have standardized their load balancing, firewall, and WAN technologies, and vendors don’t want to change these for applications moving to the cloud.
As we started working with real customer implementations, we made numerous tactical changes based on their input. Customers told us which public clouds they were willing to use for what types of workloads. We found that it is very important to strategize with customers about that. Most customers were interested in Amazon; many customers were also interested in cloud offerings, which are VMware-based (such as Terremark, Savvis, Bluelock, etc.), because they are a VMware shop. This input helped us prioritize which public clouds we were going to support in the near term. However, we haven’t made any changes to the underlying vision or the basic architectural direction with which we started.
What is your target market? What type and size of company benefits most from your solution?
Our target market is a mix of mid-tier companies and very large enterprises. On the very large enterprise side, we already have customers in the pharmaceuticals and financial services industries that are transitioning with us from Beta to our commercial offering.
On the mid-tier side, we tend to segment these companies less based on revenue and more based on what their infrastructure looks like. We look for companies that have a fair amount of investment in infrastructure (hundreds of servers and tens and low hundreds of applications) and are looking to “bridge” with external cloud offerings in a hybrid scenario.
We are all about the “hybrid” model and believe that will be model of choice for many of the companies we are targeting. We’ve spoken to hundreds of these companies and got a definite sense that they are not going to move all of their servers to the public cloud any time soon. In order to maintain control over their own data centers, they will continue to run a set of mission- and business-critical applications. What they are focused on is how not to increase the data center footprint they already have and how to consolidate and shrink it down. This leads them to think of ways to “burst” out to public cloud during peak demand seasons, dates, and/or times so that the footprint they have to maintain is much smaller. Infrastructure and applications that are already in colo spaces are potentially great candidates for the cloud.
Another key conversation we have with customers is around virtualization. The journey to the cloud is enabled and in many ways catalyzed by virtualization. Our software today works with virtualized applications and workloads. We find that almost every enterprise out there is carrying out virtualization initiatives. While the percentage of virtualization in any single enterprise may be low (between 5 and 15% on average), we still have a large addressable market when you look horizontally across all enterprises and vertical industries. We believe that the virtualization footprint will only increase in the next several years.
What type of workloads are your customers moving to the cloud?
We found that in many companies over 50% of the data center footprint is devoted to development and test environments. The demand on these systems tends to be cyclical with peak loads and idle times driven by product development, test, and release cycles. This is the development migration use case. Companies are moving these environments to the cloud, thus freeing up in-house resources for running more critical and steady production workloads.
Another related use case is around QA scaling. As an example, at CloudSwitch, we run our entire development cycle in the cloud. On any given night and particularly during a peak QA testing cycle, we might potentially spin up several hundred servers in the cloud to do our scale testing. In a traditional environment, we would not be able to do that quickly, easily and cost efficiently.
The third type of workload is more on the production side typified by consumer-facing web applications (could be revenue generating or marketing or promotional type) or employee collaboration applications. What’s common with these applications is that the customer is building colo space for the infrastructure to run these apps and they provision these resources for peak traffic demand. Therefore, the customer ends up paying for the colo footprint even though it remains idle for a vast amount of time. With the cloud, the customer maintains a small internal footprint for normal workloads and “bursts” out to the cloud during peak times, paying only for resources consumed.
Since you work with multiple cloud providers, where do you see cloud interoperability standards headed?
We are engaged with most cloud providers out there in terms of business relationships and interacting with technology and product groups. Having worked with about a dozen of these providers, what we found was interesting and revealing: every cloud provider has some kind of differentiation whether it is their level of service and support, the choices they made about the hypervisor, the way they make their networking available, the way they architected their storage, the way they provide scalability, the hardware they are running, and so on. It’s a very diverse market out there. We believe that the chances of that standardizing in the near future are slim to none. Even those service providers that use VMware and vCloud API are quite diverse.
What all this means is that every single cloud is its own island different from other clouds and different from what the customer has in their datacenter. Our whole reason for being is that we abstract the customer from all this diversity and make the migration and interoperability a seamless experience. Adding support for new cloud providers is an incremental effort for us since we have already done all the heavy lifting architecturally and built the abstraction into our core IP, which we call the “cloud isolation technology.” We have an isolation layer than runs on top of the cloud hypervisor layer and below the operating system. The customer application runs on top of our isolation layer abstracting all the diversity and complexity of the underlying cloud provider system.
[Note: Ellen's most recent blog post touches on this topic in greater detail. Check it out here: http://www.CloudSwitch.com/blog]
What’s your advice to other start-ups and established companies in this space?
These are early days at all levels. It’s certainly early for customers but it’s also early for cloud providers. The technology is still maturing and vendors are learning as real-world customer implementations bring a dose of reality. What’s going on right now on the customer side is that they are deep in cloud strategy efforts including POC’s and vendor evaluations. A lot of those customers are looking for cloud computing expertise around mapping out their application landscape and to identify the right applications, workloads, vendors, and other technologies needed to have a successful cloud implementation. There is an opportunity here for cloud consulting and integration companies, which seem to be popping up all over the place.
Kamesh Pemmaraju heads cloud research at Sand Hill Group. He welcomes your comments, opinions, and questions. Drop in a line to firstname.lastname@example.org.