Profiling the Public Cloud Buyer

Cloud Buyer – The key question is cloud service is the right fit for your specific jobs, whether today or in a few years, and what you should do to prepare. by Alex Veytsel, Steve Lerner and Tony Greenberg As published by Microsoft TechNet In the 10+ years that RampRate has advised buyers of IT infrastructure services, few technology options have been as polarizing as “the cloud.” In some organizations, a public cloud deployment is viewed as an immature technology if not a passing fad, with any cloud outage eliciting a chorus of “I told you so.” In others, it is a panacea that appears at the end of every strategic roadmap for every application. The true position is at neither extreme.

Public cloud computing is a tool for a job, which fits some buyers and projects today, and will fit more of them as both cloud technologies and application development practices continue to mature. It is the heir to many technologies that were initially viewed with an equal measure of skepticism and enthusiasm in the past – from co-location to content delivery networks to virtualization technologies rebranded by some vendors as “private clouds”. The key question is not whether it is a great technology or a flawed one – it’s both, particularly flawed when misapplied – but what cloud service is the right fit for your specific jobs, whether today or in a few years, and what you should do to prepare.

Public Cloud in the Big Picture

Public cloud infrastructure is a trendy label that has been applied (and misapplied) to many services along the spectrum of managed hosting. For the purposes of this article, the cloud services we are addressing are:

• Infrastructure as a Service (IaaS) – open architecture public cloud platforms such as Amazon EC2
• Platform as a Service (PaaS) – development platforms such as Microsoft Azure
• Software as a Service (SaaS) – application delivery such as salesforce.com

· · ·Figure 1 Hosting Spectrum for Cloud and Non-Cloud Deployments. Source: RampRate· · ·

At a minimum, the Public Cloud solution must exhibit the following features:

• Most key design decisions belong to the vendor
• Automatic provisioning
• On-demand scaling or elasticity, often with charge-back reflecting per-hour rather than per-month charges

Public Cloud Buyer Profile

As part of getting buyers towards an optimal decision, we use a scorecard mechanism to weight priorities vs. solution strengths. Historically, public cloud buyers — whether starting new projects or attempting to migrate legacy applications — have shown the following attributes compared to their colleagues that opt for other forms of managed hosting:

• Higher risk tolerance. Moving into the cloud does entail some early adopter operational risk. It is a market where several of the top providers have a history of outages, and customer service standards are not always enterprise class. public cloud buyers are all too aware of the risk and seek to hedge it in other ways – whether through application resiliency or provider diversity.
• More emphasis on price. The TCO on a public cloud platform may not always be lower, but the sticker price usually is, and it does attract the cost-conscious buyer.
• More emphasis on scale up than out. Buyers of public cloud services want one thing — on-demand compute capacity/storage — done at scale, rather than a broad portfolio of infrastructure and telecommunications offerings.

Figure 2 Priorities of cloud buyers

Heir to Multiple Legacies

The profile of the cloud infrastructure buyer bears many similarities to early adopters of other infrastructure approaches as well. However, crucial differences remain, based largely on alternatives to each technology available at the time of its initial uptake:

Co-location

• Similar to public cloud, early fears with regards to outsourced shared data centers often focused on security concerns that were largely, though not always, overblown
• However, unlike public cloud, the adoption of early data centers was less about scale and price than about operational health (i.e. uptime) – to be precise, a specific mix of resiliency and cost that found a sweet spot in the market. Yet it was still not a solution for all buyers. A closet with an air conditioner served for the buyer with minimal uptime concerns, while true Tier IV data centers for the maximalist were (and remain) rare and expensive, and are still built as often as rented.

Content Delivery Network (CDN)

• CDN adoption was similar to today’s public cloud infrastructure in the role of scale. Steep and unexpected demand on the infrastructure is a key driver for both services. CDN was also similar in offering usage-based billing in place of capacity-based charges of alternatives – supplanting the traditional per-Mbps charge model with a cost per gigabyte transferred.
• However, unlike public cloud, CDN adoption during its early days was less often a price driven decision, and more often a question of technical fit and performance. Questions like “Does the CDN support a specific streaming media format?” “Does the increased price for bandwidth increase my revenue from my website?” “Can it generate unique URLs to keep my content secure?” “Is it faster than my own servers?”, and even more mundane concerns like “Will the caching mechanism blow up if my file size is too big?” were more top of mind than, say, support for a specific OS version is on a public cloud infrastructure.

Implications for the Public Cloud Buyer

For both co-location and CDN – now mainstream and mature services – the same growing pains of unexpected outages, indifferent customer service from market leaders, and the prospect of smaller providers winking out of existence kept the initial risk profile high. Yet, when the dust cleared, the key attributes of choosing each one — operational health for data centers and technology fit / performance for CDNs — remained as key guides to the core value. Similarly, buyers who put scale and price first will eventually drift to the public cloud. Risk tolerance only determines where in the technology maturity cycle they will make the leap. If on-demand growth at a low cost is your primary goal, then the public cloud should be somewhere on your roadmap now. If your top of mind concern is ability to control and fine-tune the performance profile or retain backwards compatibility with retained legacy components, it may be best to proceed more cautiously, building private cloud competencies that can be extended to public cloud services in the future.

Between Two Clouds: The Soul of the New Machine

The digital sky above us is no longer empty. It is filled with clouds, not of water and air, but of data and light, vast, churning server farms that hold the ghost of our age. We are caught between worlds, between the earth-bound certainty of owned iron and the ethereal promise of the public cloud. This is not a technical choice; it is a spiritual one. It is a question of what we trust, where we place our faith, and how we build the future.

I remember the hum of the server room, a low thrum that vibrated through the soles of my feet. The air, thick with the smell of ozone and chilled to a constant sixty-eight degrees, was a physical presence. You could lay a hand on a server rack and feel the pulse of the machine, the heat of its labor. That physical connection, that tangible reality, is what we trade for the frictionless abstraction of the cloud. We have traded the forge for the formula, the engine for the incantation.

This shift is not merely a technological evolution; it is a restructuring of power. The public cloud is the new leviathan, a centralized system of control dressed in the language of liberation. It promises infinite scale at a negligible cost, a siren song for the cost-conscious and the growth-obsessed. But this convenience comes at a price. We surrender control, we accept the risk of catastrophic failure, and we become dependent on a handful of colossal entities that govern the digital commons. The sticker price is a lure, a down payment on a future where the architecture of our world is rented, not owned.

I confess, I have been seduced by the siren's call. I have chased the illusion of infinite scalability, the promise of a business that could grow without limits. I have felt the pull of the new, the desire to be at the vanguard of a technological revolution. But I have also felt the chill of uncertainty, the fear of building on a foundation that I do not own and cannot control. I have stood in the digital cathedral and wondered if I am a builder or merely a supplicant.

The future is not a destination; it is a choice we make every day.