I spent a day in San Francisco recently, meeting a couple of potential customers and one new one. Interestingly enough, they all wanted to talk about Amazon, and they all had used Amazon EC2 at one point. [Side note: One of them is moving to Carpathia from Amazon to reduce their costs – more specifically, moving from EC2 to a private hosted cloud.]
The common question was, "so what do you think about the outage?" This would be a great time to bash on Amazon, but in reality, the responsibility here really needs to be shared with the users. Check out the Cloud DR or DR for Cloud blog I wrote last year for more information. Just because you are running on a resilient platform like a cloud, doesn't mean you can forget all about good old fashion DR. The discipline is still alive and well and needs thought, but enough on that topic :)
Twice during the month of April, Equinix and Carpathia hosted a webinar on "hybrid" clouds. Equinix is a company that understands that most of the value of cloud is realized through the network. In fact, the name "cloud" actually came from the clouds we all drew on whiteboards over the past 10 years to show the resources being outside the boundaries of the customer. Without the network, cloud is just a captive computing cluster. Just a few years ago, Grid Computing was the cool thing -- something these days we rarely talk about. If you’re interested in listening to the webinar, you can access it here.
During the webinar, I outlined three kinds of hybrid blueprints we think about. Most cloud pundits really tend to think about just one.
1. On-prem to public cloud – the “one” that cloud pundits think about – is really the poster child for cloud. It provides burstable capacity or agile computing for a customer’s existing onsite resources. The connection is typically layer3-based (sometimes layer2 over layer3 using solutions like Vyatta. While this gets the most discussion, it’s actually the one form that we see least of in our world of enterprise/government customers for a couple of reasons; if you can split your application up in this way, you tend to hit latency issues and bandwidth costs for the Internet portion. Often, you are paying twice for the bandwidth - when it leaves your on-prem location and when it enters/leaves the public cloud.
2. Inside the data center – This is the one that we are seeing most of today. A customer in a data center has colo or managed services and wants to use cloud for projects, programs, overflow capacity, etc. With some clouds within the data center, you can avoid the bandwidth charges (Equinix provides a cross connection service for this purpose), very low latency, as in the case of our cloud support for layer2 connections. Just plumb it in, and provision VMs from our cloud directly onto your vlans. A majority of our cloud customers are doing or looking at doing this very model.
3. Exchange-based solution – This model has the biggest potential and excitement from customers. It’s providing what’s really a “many-to-many” connection. The customer hooks up to the ethernet exchange via whatever carrier they work with. The ethernet exchange has a variety of cloud providers with different capabilities and focuses. The customer can then take advantage of a connect-once/use-many kind of approach to reach multiple cloud providers also on-net with the exchange.
Judging by the questions we received during the webinar, points 2 and 3 had the most interest. Whichever solution you chose, don’t forget to take into account the total cost of ownership for your cloud, and include the network. One of my former employers had the tag line "the network is the computer” -- this is turning out to be even more true then when they coined it in 1982!