Colo Cloud: The Best of Both Worlds
If you aren’t familiar with Lydia Leong, she’s a VP Distinguished Analyst for research firm Gartner and a fellow “Top 10 Women in Cloud” who often tweets with attitude (which I enjoy). Like many others, she’s often made well-reasoned observations on the subject of cloud with respect to the enterprise. Back in 2011, she was already noting the importance of the concept we’re coming to refer to now as “colo cloud”. I won’t paraphrase, here’s what she had to say about it “back then”:
…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.
This was reality then and remains reality now: enterprises have their heads in the clouds, but their feet firmly on the ground. That reality isn’t nearly as sexy as pure cloud, and yet is what most enterprises have to live with every day.
Yes, they want to “go cloud”. No, they don’t want to sacrifice control or security, and they certainly aren’t interested in the time consuming process that is a “rewrite” of a major application to take advantage of the cloud. I have friends in enterprise IT who have spent years – literally years – of their lives rewriting major applications from one platform to another inside the enterprise. This is not a trivial undertaking. The cost alone can cause sticker-shock. Fred Brooks, in his famous “The Mythical Man Month”, gives us a simple equation with which to estimate the costs. Given an application with 100,000 lines of code, and an average developer cost per day of $500, it’ll cost a cool $4M to get that app rewritten, tested, debugged, and deployed. And rewrites of major applications are often over budget and over time and worse, according to the Standish Group, 70% of full application rewrite projects fail. It’s easy to see why in many cases organizations are embracing SaaS whenever they can to replace aging apps.
And, as has repeatedly been pointed out in the years since cloud’s inception, there are a variety of “black boxes” in the network, often security-related, that can’t be put in the cloud. Nor can they necessarily be replaced. They’re not just part of the security strategy, they’re part of the architecture, and they’re part of those checklists that go into the organization’s certifications for compliance, quality, and industry-specific requirements. They can’t be ripped out without being replaced, audited, and certified to ensure the business doesn’t lose its certification.
Really. There’s ISO 27001, which focuses on security. It requires a lot of paperwork, policies, and procedures as well as technical controls. So does ISO 9001, which is geared toward quality management. There are industry-specific certifications and standards, and all require dedication and attention to process and policies and controls. It’s not just about the code, or the architecture, it’s about the business, too. And the ephemeral aspects of business can’t always be easily ripped up, rewritten, and packaged up in an easy to deploy virtual image in a public cloud.
But, Cloud!
Organizations do want cloud, and with good reason. There are compelling uses of cloud for enterprise organizations in addition to those uses answered by the adoption of SaaS applications. Capacity, marketing, mobile, disposable apps. All are inarguably excellent workloads to be migrated to a public cloud. But some apps need more. They need app services, they need security, and they need to operate within the framework of certifications and standards the business needs to operate in its industry. And some are tethered by a multitude of integrations and dependencies. This provides impetus for the growing popularity of private cloud over public, and the acceptance that some workloads simply cannot be moved to a “public” cloud.
That’s why colo cloud turns out to be an appealing option. By establishing an environment in which a more traditional, hosting service can be provided in conjunction with cloud interconnects - fast, low-latency links into an adjoining public cloud environment that make the cloud a true extension of the data center. These colo cloud providers are able to offer a solution that addresses the needs of organizations who cannot afford to rewrite or even rehost applications to fit into a public cloud environment. This is the “lift and shift” answer, where the app, its architecture, and its processes are figuratively lifted off its foundations and shifted into a colo cloud. Those components that can be migrated into the public cloud, right next door over the lower latency cloud interconnect, can be.
Organizations realize cost savings and the agility of public cloud by being able to deploy apps in the public cloud side of the data center with confidence. That confidence comes from knowing that data security and performance will be maintained because the data sources are safely ensconced on the hosting provider’s side of the wall along with the infrastructure and services it was deployed with in the first place.
Colo cloud is a real option, and it’s one enterprise organizations should be evaluating as a means to lift not just apps but the business itself if not fully in the cloud, then at least close enough to touch them.