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
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.
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.
