Why cloud IaaS customers care about a colo option
Ben Kepes has raised some perceived issues on the recent Cloud IaaS and Web Hosting Magic Quadrant, on his blog and on Quora. It seems to reflect some confusion that I want to address in public.
Ben seems to think that the Magic Quadrant mixes colocation and cloud IaaS. It doesn’t, not in the least, which is why it doesn’t include plain ol’ colo vendors. However, we always note if a cloud IaaS vendor does not have colocation available, or if they have colo but don’t have a way to cross-connect between equipment in the colo and their cloud.
The reason for this is that a substantial number of our clients need hybrid solutions. They’ve got a server or piece of equipment that can’t be put in the cloud. The most common scenario for this is that many people have big Oracle databases that need big-iron dedicated servers, which they stick in colo (or in managed hosting), and then cross-connect to the Web front-ends and app servers that sit in the cloud. However, there are other examples; for instance, our e-commerce clients sometimes have encryption “black boxes” that only come as hardware, so sit in colo while everything else is in the cloud. Also, we have a ton of clients who will put the bulk of their stuff into the colo — and then augment it with cloud capacity, either as burst capacity for their apps in colo, or for lighter-weight apps that they’re moving into the cloud but which still need fast, direct, secure communication with interrelated back-end systems.
We don’t care in the slightest whether a cloud provider actually owns their own data center, directly provides colocation, has any strategic interest in colocation, or even offers colocation as a formal product. We don’t even care about the quality of the colocation. What we care about is that they have a solution for customers with those hybrid needs. For instance, if Amazon were to go out and partner with Equinix, say, and customers could go colo in the same Equinix data center as Amazon and cross-connect directly into Amazon? Score. Or, for instance, Joyent doesn’t formally offer colocation — but if you need to colocate a piece of gear to complement your cloud solution, they’ll do it. This is purely a question of functionality.
Now, you can argue that plenty of people manage to use pure-play cloud without having anything that they can’t put in the cloud, and that’s true. But it becomes much less of a typical scenario the more you move away from forward-thinking Web-native companies, and towards the mixed application portfolios of mainstream business. It’s especially true among our mid-market clients, who are keenly interested in gradually migrating to cloud as their primary approach to infrastructure, hybrid models are critical to the migration path.
Posted on January 7, 2011, in Industry and tagged cloud, colocation, MQ. Bookmark the permalink. 14 Comments.
CloudPundit: Massive-Scale Computing 
Lydia – appreciate the post… great that you guys are engaging with those who disagree… Let me ruminate on your points…
LikeLike
Lydia, I think it is the market definition section that creates the confusion. Colocation is called out as a line item but perhaps it isn’t clear enough on how this is factored in. You call it out as a bullet item and then say you don’t care about it in your blog. It isn’t clear to me where colocation as the bullet point actually features in the assessment. I’m also confused as to the Oracle server example in your blog. Do your clients really have dedicated servers of their own and have them connected to via web apps running in the cloud ? Sounds like an amazon VPC type approach but I have no idea who provides the service where public cloud IaaS facing the web could securely connect to on premise or collocated Oracle servers. I’ve tried to find that exact service which is why iboj
LikeLike
Oops…I meant to say which is why I kn
LikeLike
Which is why I know it doesn’t exist
LikeLike
To Confused:
Colocation isn’t formally evaluated at all in the Magic Quadrant, but we note when providers have it or don’t have it, for the sake of completeness (just as we always mention if the provider has a CDN, even though CDN services aren’t evaluated at all in the MQ). It’s in the definitions for clarity.
As for the webserver front ends plus app servers in the cloud, and a dedicated back-end database? It’s a pretty common scenario. You just use the provider’s colo and cross-connect. (Usually there’s an option to cross-connect into the managed hosting environment, too, if the provider does managed hosting.) Sometimes you can just ask to have it done — just about every cloud provider on the MQ will allow you to cross-connect on request. Sometimes they’re more formal about it (Rackspace, for instance). You’re not seeing it as a formal named product offering because it’s just a service option.
Similarly, you don’t see formally-named product offerings from other service providers that are like Amazon VPC, because pretty much all of them will do VPN on demand for no charge, or even allow you to drop private connectivity into your cloud infrastructure (like you want MPLS from your favorite carrier, great, just drop it into their data center and they’ll cross-connect you). It’s just part of the core service offering that you can get by asking.
LikeLike
Thanks Lydia. So, just for the sake of completeness, let me get this right. If I want an internet facing web server as an “Self Managed” IaaS offering from the provider (let’s call them “Bob”), I can bring one up on demand, configure it, get a public IP address once I am ready, I ask that same provider to give me a cross connect to my cage / rack in their colo space and then I’m good to connect to my “non-cloud” Oracle server ? I would have just a couple of questions on how that would work from a security perspective, assuming I don’t control the environment at the “A” end of the cross-connect, but I do control the equipment at the “B” end. In Let’s assume it were possible, as you say, then isn’t the Oracle server just being provided as part of a pure collocation provision, with a nominal charge for the cross-connect ? What would help me, is trying to figure out what this scenario would be classed as, relative to the nomenclature in the MQ. We have a fairly substantial global footprint via a mix of colo providers where we either manage our own equipment or in some cases, have managed servers (contract), but I’m yet to find a service that would do what I think I’ve interpreted above (from your reply)….
LikeLike
Yep — you have one or more VMs in the cloud, and you have some dedicated device in the same provider’s colo (in this example, a big physical server running Oracle).
Different cloud providers do this differently (and some do it very awkwardly). Most of the providers that do this give each individual customer a VLAN, and that VLAN can be used in their cloud environment, their hosting environment, and their colocation environment. Many people who cross-connect in this way do not give the back-end database server a public IP address, and for that matter, might not give their front-end webservers or app servers public IPs either — instead, the public IP goes to a load-balancer and then everything behind the load-balancer has a private IP.
In the MQ use cases, if you have self-managed cloud IaaS and you’ve got an Oracle database in colocation, we consider your whole solution to be self-managed. If you have self-managed cloud IaaS and you have an Oracle database in managed hosting, we consider your solution to be hybrid; you are “lightly managed” if the provider is just doing basic systems administration for the database server, and probably “complex managed” if the provider is giving you a lot of DBA time.
Put another way, in the Magic Quadrant, the connect-into-colo capability is just another feature — no different than having multi-factor authentication, or offering IPsec VPN tunnels, or having snapshot backups.
We call it out in the text because it’s a question that is very frequently raised by our clients who are planning their move to the cloud — “what do I do with the stuff that I’m not ready to move into the cloud yet?” and “this app needs this physically dedicated device that’s an exception to what I can virtualize, how to I deal with that?”
LikeLike
Lydia, interesting post.
A lot of cloud providers are starting to use the ‘hybrid’ word, and adding it to their core lexicon and marketing material. Makes sense; we’ve believed for a while that the escape velocity for most enterprises to go ‘all cloud’ is simply too high.
However, as always, the devil is in the details. Your example of Amazon providing a cross connect to Equinix — it’s certainly possible, but in my opinion it falls short.
True hybrid hosting breaks down the walls between the old fashioned and the new fangled. That means that your colocation and cloud can sit in the same VLAN, share IP addresses, and function as ‘one infrastructure’ behind the same set of load balancers and firewalls. Where do dedicated servers fit in? Ideally, they’re part of this holistic infrastructure.
Ideally, they should also have one overarching SLA, bandwidth commitment, API, etc.
Hybrid hosting done right is more than just being able to check off having cloud and colo products.
LikeLike
That’s certainly true, Raj. In the end, my perspective is that it’s fundamentally about capabilities. What the back-end is — dedicated servers, single-tenant virtualized servers, multi-tenant cloud virtualization, etc. — ultimately isn’t about anything more than what’s efficient for this particular customer’s budget needs and technical requirements. I am a deep believer that most customers need a holistic approach that, for the moment, needs to span all of these worlds.
LikeLike
Very strange to leave out Google as a cloud provider.. and then of course Azure…
LikeLike
@Tom Brander: We specifically mention both as not being IaaS, and thus not qualifying to be in the MQ. Google App Engine is PaaS. Azure is also PaaS (although the addition of the upcoming VM role makes it unclear whether or not it will also qualify as IaaS in the future).
LikeLike
It’s actually a great and useful piece of info. I am glad that you shared this useful
information with us. Please keep us informed like this.
Thank you for sharing.
LikeLike
Pingback: Quora’s Uptake Velocity, and Unintended Consequences
Pingback: Interesting Gartner Analyst Blog posts « The Future is…Cloudy