Blog Archives
Gartner research related to Amazon’s outage
In the wake of Amazon’s recent outage, we know we have Gartner clients who are interested in what we’ve written about Amazon in the past, and our existing recommendations for using cloud IaaS, and managing cloud-related risks. While we’re comfortable with our current advice, we’re also in the midst of some internal debate about what new recommendations may emerge out of this event, I’m posting a list of research notes that clients may find helpful as they sort through their thinking. This is just a reading list; it is by no means a comprehensive list of Gartner research related to Amazon or cloud IaaS. If you are a client, you may want to do your own search of the research, or ask our client services folks for help.
I will mark notes as “Core” (available to regular Gartner clients), “GBL” (available to technology and service provider clients who have subscribed to Gartner for Business Leaders or a product with similar access to research targeted at vendors), or “ITP” (available to clients of the Burton Group’s services, known as Gartner for IT Professionals post-acquisitions).
If you are specifically concerned about this particular Amazon outage and its context, and you want to read just one cautionary note, read Will Your Data Rain When the Cloud Bursts?, by my colleague Jay Heiser. It’s specifically about the risk of storage failure in the public cloud, and what you should ask your provider about their recoverability.
You might also be interested in our Cloud Computing: Infrastructure as a Service research round-up, for research related to both external cloud IaaS, and internal private clouds.
Amazon EC2
We first profiled Amazon EC2 in-depth in the November 2008 note, Is Amazon EC2 Right For You? (Core). It provides a brief overview of EC2, and examines the business case for using it, what applications are suited to using it, and the operational considerations. While some of the information is now outdated, the core questions outlined there are still valid. I am currently in the process of writing an update to this note, which will be out in a few weeks.
A deeper-dive profile can be found in the November 2009 note, Amazon EC2: Is It Ready For the Enterprise? (ITP). This goes into more technical detail (although it is also slightly out of date), and looks at it from an “enterprise readiness” standpoint, including suitability to run certain types of workloads, and a view on security and risk.
Amazon was one of the vendors profiled in our December 2010 multi-provider evaluation, Magic Quadrant for Cloud Infrastructure as a Service and Web Hosting (Core). The evaluation is focused in the context of EC2. This is the most recent competitive view of the market that we’ve published. Our thinking on some of these vendors has changed since the time it was published (and we are working on writing an update, in the form of an MQ specific to public cloud); if you are currently evaluating cloud IaaS, or any part of Amazon Web Services, we encourage you to call and place an inquiry.
Amazon S3
We did an in-depth profile for Amazon S3 in the November 2008 note, A Look at Amazon’s S3 Cloud-Computing Storage Service (Core). This note is now somewhat outdated, but please do make a client inquiry if you want to get our current thinking.
The October 2010 note, in Cloud Storage Infrastructure-as-a-Service Providers, North America (Core), provides a “who’s who” list of quick profiles of the major cloud storage providers.
An in-depth examination of cloud storage, focused on the technology and market more so than the vendors (although it does have a chart of competitive positioning), is given in the December 2010 note, Market Profile: Cloud-Storage Service Providers, 2011 (ITP).
The major cloud storage vendors are profiled in some depth in the June 2010 note, Competitive Landscape: Cloud Storage Infrastructure as a Service, North America, 2010 (GBL).
Other Amazon-Specific Things
The June 2009 note, Software on Amazon’s Elastic Compute Cloud: How to Tell Hype From Reality (Core), explores the issues of running commercial software on Amazon EC2, as well as how to separate vendor claims of Amazon partnerships from the reality of what they’re doing.
Amazon was one of the vendors who responded to the cloud rights and responsibilities published by the Gartner Global IT Council for Cloud Services. Their response, and Gartner commentary on it, can be found in Vendor Response: How Providers Address the Cloud Rights and Responsibilities (Core).
Amazon’s Elastic MapReduce service is profiled in the January 2011 note, Hadoop and MapReduce: Big Data Analytics (ITP).
Cloud IaaS, in General
A seven-part note, the top-level note of which is Evaluating Cloud Infrastructure as a Service (Core), goes into extensive detail about the range of options available in cloud IaaS provider, and how to evaluate those providers. You are highly encouraged to read it to understand the full range of market options; there’s a lot more to the market than just Amazon.
To understand the breadth of the market, and the players in particular segments, read Market Insight: Structuring the Cloud Compute IaaS Market (GBL). This is targeted at vendors ho want to understand buyer profiles and how they map to the offerings in the market.
Help with evaluating what type of data center solution is right for you can be found in the framework laid out in Data Center Sourcing: Cloud, Host, Co-Lo, or Do It Yourself (ITP).
Help with evaluating your application’s suitability for a move to the cloud can be found in Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace? (ITP), which takes an in-depth look at the factors you should consider when evaluating your application portfolio in a cloud context.
Risk Management
We’ve recently produced a great deal of research related to cloud sourcing. A catalog of that research can be found in Manage Risk and Unexpected Costs During the Cloud Sourcing Revolution (Core). There’s a ton of critical advice there, especially with regard to contracting, that make these notes a must-read.
We provide a framework for evaluating cloud security and risks in Developing a Cloud Computing Security Strategy (ITP). This offers a deep dive into security and compliance issues, including how to build a cross-functional team to deal with these issues.
We take a look at assessment and auditing frameworks for cloud computing, in Determining Criteria for Cloud Security Assessment: It’s More than a Checklist (ITP). This goes deep into detail on risk assessment, assessment of provider controls, and the emerging industry standards for cloud security.
We caution about the risks of expecting that a cloud provider will have such a high level of reliability that a business continuity and recoverability are no long necessary, in Will Your Data Rain When the Cloud Bursts? (Core). This note is specifically primarily focused on data recoverability.
We provide a framework for cloud risk mitigation in Managing Availability and Performance Risks in the Cloud: Expect the Unexpected (ITP). This provides solid advice on planning your bail-out strategy, distributing your applications/data/services, and buying cyber-risk insurance.
If you are using a SaaS provider, and you’re concerned about their underlying infrastructure, we encourage you to ask them a set of Critical Questions. There are three research notes, covering Infrastructure, Security, and Recovery (all Core). These notes are somewhat old, but the questions are still valid ones.
Cloud IaaS special report
I’ve just finished curating a collection of Gartner research on cloud infrastructure as a service. The Cloud IaaS Special Report covers private and public cloud IaaS, including both compute and storage, from multiple perspectives — procurement (including contracting), governance (including chargeback, capacity, and a look at the DevOps movement), and adoption (lots of statistics and survey data of interest to vendors). Most of this research is client-only, although some of it may be available to prospects as well.
There’s a bit of free video there from my colleague David Smith. There are also links to free webinars, including one that I’m giving next week on Tuesday, March 29th: Evolve IT Strategies to Take Advantage of Cloud Infrastructure. I’ll be giving an overview of cloud IaaS going forward and how organizations should be changing their approach to IT. (If you attended my data center conference presentation, you might see that the description looks somewhat familiar, but it’s actually a totally different presentation.)
As part of the special report, you’ll also find my seven-part note, called Evaluating Cloud Infrastructure as a Service. It’s an in-depth look at the current state of cloud IaaS as you can obtain it from service providers (whether private or public) — compute, storage, networking, security, service and support, and SLAs.
Contracting in the cloud
There are plenty of cloud (or cloud-ish) companies that will sell you services on a credit card and a click-through agreement. But even when you can buy that way, it is unlikely to be maximally to your advantage to do so, if you have any volume to speak of. And if you do decide to take a contract (which might sometimes be for a zero-dollar-commit), it’s rarely to your advantage to simply agree to the vendor’s standard terms and conditions. This is just as true with the cloud as it is with any other procurement. Vendor T&Cs, whether click-through or contractual, are generally not optimal for the customer; they protect the vendor’s interests, not yours.
Do I believe that deviations from the norm hamper a cloud provider’s profitability, ability to scale, ability to innovate, and so forth? It’s potentially possible, if whatever contractual changes you’re asking for require custom engineering. But many contractual changes are simply things that protect a customer’s rights and shift risk back towards the vendor and away from the customer. And even in cases where custom engineering is necessary, there will be cloud providers who thrive on it, i.e., who find a way to allow customers to get what they need without destroying their own efficiencies. (Arguably, for instance, Salesforce.com has managed to do this with Force.com.)
But the brutal truth is also that as a customer, you don’t care about the vendor’s ability to squeeze out a bit more profit. You don’t want to negotiate a contract that’s so predatory that your success seriously hurts your vendor financially (as I’ve sometimes seen people do when negotiating with startups that badly need revenue or a big brand name to serve as a reference). But you’re not carrying out your fiduciary responsibilities unless you do try to ensure that you get the best deal that you can — which often means negotiating, and negotiating a lot.
Typical issues that customers negotiate include term of delivery of service (i.e., can this provide give you 30 days notice they’ve decided to stop offering the service and poof you’re done?), what happens in a change of control, what happens at the end of the contract (data retrieval and so on), data integrity and confidentiality, data retention, SLAs, pricing, and the conditions under which the T&Cs can change. This is by no means a comprehensive list — that’s just a start.
Yes, you can negotiate with Amazon, Google, Microsoft, etc. And even when vendors publish public pricing with specific volume discounts, customers can negotiate steeper discounts when they sign contracts.
My colleagues Alexa Bona and Frank Ridder, who are Gartner analysts who cover sourcing, have recently written a series of notes on contracting for cloud services, that I’d encourage you to check out:
- Four Risky Issues When Contracting for Cloud Services
- How to Avoid the Pitfalls of Cloud Pricing Variations
- Seven Ways to Reduce Hidden Upfront Costs of Cloud Contracts
- Six Ways to Avoid Escalating Costs During the Life of a Cloud Contract
(Sorry, above notes are clients only.)
Open invite for public cloud IaaS Magic Quadrant
As I alluded to in some earlier posts, we are doing a mid-year Magic Quadrant for public cloud IaaS. Specifically, this is for multi-tenant, on-demand, self-provisioned, compute services (with associated storage, networking, etc.). That would be services like Amazon EC2 and Terremark Enterprise Cloud. The intended context is virtual data center services — i.e., environments in which a business can run multiple applications of their choice — as they would be bought by Gartner’s typical IT buyer clients (mid-market, enterprise, and technology companies of all sizes).
Vendors invited to participate will see a formal research-initiation email sometime in the next week or two (or so I hope). This is just an early heads-up.
If you are a public cloud compute IaaS provider and you didn’t participate in the last Magic Quadrant (i.e., you did not do a survey for qualification last year), and you are interested in trying to qualify this year, please feel free to get in touch with me, and I’ll discuss including you in the qualification survey round. (Anyone who got a survey last time will get one this time.) You do not need to be a Gartner client.
Of late, I’ve seen some enthusiastic PR folks sign up executives at totally inappropriate companies to talk to me about qualifying for MQ inclusion. Please note that the MQ is for service providers, not enablers (i.e., not software or hardware companies who make stuff to build clouds with). Moreover, it is for public cloud (i.e., multi-tenant elastic services), not custom private clouds or utility hosting and certainly not colocation or data center outsourcing. And it is for the virtual data center services, the “computing” part of “cloud computing” — not cloud storage, PaaS, SaaS, or anything else.
Gartner’s cloud computing surveys
My colleague Jim Browning, who is focused on SMB research, has just published a survey of mid-sized businesses in North America. If you’re a vendor client, I encourage you to check out his Survey Analysis: North American Midsize Businesses Cite Cloud Intentions.
Also, I want to draw your attention to some research that you might not have noticed before.
Back in 2010, Gartner fielded a huge global survey — 7,300 respondents in the United States, Western Europe, and China — with the goal of looking at cloud adoption trends. Out of them, 650 correctly answered a bunch of screening questions about what constitutes cloud computing, and got to answer the rest of the survey.
The results show:
- Why people called something cloud
- Adoption patterns by type of service
- Key drivers of adoption
- Key stakeholders in driving adoption
- Whose budget is it?
- Key concerns
- Influential factors when selecting a provider
- Project IT budget allocated to cloud
- Impact on the IT organization
If you haven’t looked at this data, I’d highly encourage you to.
Gartner clients only, sorry. (US data has not been consolidated into a publishable form, i.e., turned from big tables of raw numbers into pretty graphs.)
Gartner is NOT dissing Amazon’s cloud
I’ve now seen a number of press reports and some related writing, about the Magic Quadrant for Cloud Infrastrucure as a Service and Web Hosting, that I feel mischaracterize statements made on the MQ in ways that they were certainly not intended to be taken, and in some cases, mischaracterize the nature of a Magic Quadrant itself. I feel compelled to try to attempt to make some things explicitly clear. Specifically:
This is not just a Cloud IaaS MQ. As the title says, this is a Cloud IaaS AND Web Hosting MQ. You should not interpret a vendor who is a Leader in the MQ as necessarily being a “cloud leader”, for instance; they are simply a leader in the context of the overall market, of which we have forecasted 25% of the revenue to be cloud IaaS by the end of 2011. You should look at the execution axis as favoring vendors whose positioning fits well with the immediate, relatively conservative needs of typical Gartner clients, and the vision axis as favoring vendors whose strategy makes them likely to succeed in a more cloud-oriented future.
The Magic Quadrant is not tiered. Specifically, the Challengers quadrant is not “better” than the Visionaries quadrant, nor is the reverse true. Indeed, Visionaries may be better positioned to succeed in the future than Challengers are, since they tend to be companies who have good roadmaps and are evolving quickly. (And Niche Players might be highly focused and fantastic at what they do, note.)
The Magic Quadrant rates relative positions of vendors in an overall market. Importantly, it does not rate products or services; these are only a component of the overall rating (in this particular MQ, about a third). You should never judge a vendor’s position as indicating that it necessarily has a better service, especially with respect to your specific use case. It’s especially important in this particular MQ because most of the vendors are not pure-plays, and their cloud IaaS service might be much better or much worse than their portfolio as a whole.
Strengths and Cautions are statements about a vendor, not the reasons for their rating. The statements are things that we think it is important for a prospective customer to know when they’re thinking about working with this vendor. They are distinct from the criteria scores that underly the graph. In many cases, the vendor has not lost or gained points specifically for the thing that is called out, but it’s something distinctive, or that readers might not be aware, or is a common misunderstanding from readers, or is even just simply pointing out a best practice when dealing with a particular vendor.
At no point do we say that Amazon’s cloud service is unproven. Amazon is positioned as a Visionary, and as a category, Visionaries are typically companies who have a relatively short track record in the evaluated market as a whole (yes, the boilerplate language for the category uses “unproven”). Pure-play cloud vendors are still emerging, which makes this characterization fit pretty well. While Amazon has obviously been at the pure-cloud-IaaS business longer than any other vendor on the Magic Quadrant, they are newcomers to the overall market assessed by the MQ, which is now about 15 years old. MQ Visionaries are pioneering new territory. That shouldn’t be regarded as a bad thing.
We are not “dissing” Amazon. Some writers have been trying to imply that we don’t think much of Amazon’s cloud service. Nowhere does the report state this. The report certainly attempts to present meaningful strengths and cautions for Amazon, as it does for every vendor. Amazon has by far the highest rating on vision. Its execution score is based on its ability to serve the whole host of evaluated enterprise use cases in the Magic Quadrant, which, if you think about it, indicates that Amazon must have scored well on the self-managed IaaS use case, since that is the only one of the three evaluated use cases that are considered by the Magic Quadrant, and Amazon doesn’t serve the other two use cases at all. Use of Amazon or any other vendor should be considered in light of your use case and requirements.
Obviously, there are plenty of people who are interested in understanding more about the thinking and market observations that led to this Magic Quadrant, and possibly some substantial confusion on the part of people who don’t have access to the larger body of research as to Gartner’s views on cloud IaaS and so forth. I’ve blogged a fair amount recently to try to clear up some points of confusion. However, I am mindful of Gartner’s policies for social media use by analysts, and believe that it would be inappropriate for me to methodically blog about market evolution, market segmentation, and the use cases and adoption patterns that we are seeing from our clients — the things that would be necessary in order to fully lay out an explanation of our market view and how it led to this particular MQ. Instead, I should be writing research notes for paying clients, and I intend to do exactly that.
If you are a Gartner client, you are welcome to place an inquiry to discuss the Magic Quadrant and any other related matters; I’m happy to discuss these at length. And do please read the full Magic Quadrant and related research. (Non-clients can only read the non-interactive document.)
The cloud and customized contracts
Continuing the ongoing debate about the Cloud IaaS and Web Hosting Magic Quadrant, Bob Warfield has made a blog post called “Gartner: The Cloud is Not a Contract“. I want to address a number of points he made in his post. I’m going to address them out of order, starting with the points that I think are of more general interest, and then going into some of the MQ-quibble-specific stuff.
Bob goes into detail about why customized contracts can destroy what a customer was hoping to get out of the cloud in the first place. Bob writes something that I agree with but want to nuance in a number of ways. He says: How do we avoid having a contract destroy Cloudness? This is simple: Never sign a contract with your Cloud provider that interferes with their ability to commoditize through scale, sharing, and automation of operations.
I think that a cloud provider has to make decisions about how much they’re willing to compromise the purity of their model — what that costs them versus what that gains them. This is a business decision; a provider is not wrong for compromising purity, any more than a provider is right for being totally pure. It’s a question of what you want your business to be, and you can obtain success along the full spectrum. A provider has to ensure that their stance on customization is consistent with who and what they are, and they may also have to consider the trade off between short-term sales and long-term success.
Customers have to be educated that customization costs them more and may actually lower their quality of the service they receive, because part of the way that cloud providers drive availability is by driving repeatability. Similarly, the less you share, the more you pay. (These points are usually called out in gigantic bold caps in my conference presentations.) The cloud creates some harder choices for customers, because the cloud forces IT buyers to confront what “having it your way” is costing them, and will cost them in the future. The cloud is not, as it were, Burger King. The ability to take advantage of commodity cloud services will be a key factor in IT efficiency going forward.
But I believe that customers will continue to make choices along that spectrum. Most of them will walk into decisions with open eyes, and some will decide to sacrifice cost for customization. They are doing this today, and they will continue to do it. Importantly, they are segmenting their IT portfolios and consciously deciding what they can commoditize and what they can’t. Some will be better at embracing Smart Control than others, but ultimately, the most successful IT managers will be the ones who be the ones that manage IT to business goals. They are looking for cloud solutions that fit those goals, and many of those solutions are impure.
A significant percentage of my job is helping an IT buyer client talk through his requirements, challenging the reasoning for those requirements, explaining to him what his options are, and what vendors are likely to be good shortlist candidates — but also noting explicitly where his choices are preventing him from deriving greater value. I want him to consciously understand the trade-offs that he’s making, both short-term and long-term. And it’s also critical to understand their expectations of the future, so they can be advised on how to get there from here. Most organizations will transform gradually, not immediately or radically.
Bob wrote: The easy thing is to cave to your clients since they’re paying the bills and concoct a scenario where the clients get what they think they want. The hard thing is to show some leadership, earn your fees, and explain to the client, or at least to the vendors slighted, why your recommendation is right.
It is critical to understand that the MQ shows how vendors map in an overall market, which, as this MQ is titled, is, “Cloud IaaS and Web Hosting”, an impure market. As we repeatedly tell people, you should choose a solution that fits your use case — your technical and business needs. You should not read the MQ as saying that we don’t recommend Amazon (or other pure-plays) to clients. We recommend them plenty. And in fact, the MQ strengths text for Amazon is highly complimentary. (It starts with “Amazon is a thought leader; it is extraordinarily innovative, exceptionally agile and very responsive to the market. It has the richest cloud IaaS product portfolio, and is constantly expanding its service offerings and reducing its prices.” When I presented that bit of writing to my peers, some people thought it sounded too effusive for the usual Gartner tone of neutral objectivity!)
Any Gartner client trying to make a decision about the cloud is entitled to make an inquiry, and we’re happy to dive into the details of what they’re looking for, tease out what they need, and help them choose something that will be right for them. I did more than a thousand client phone inquiries during 2010. That’s a lot of people; each one represents a sourcing decision, and that number doesn’t include my conference one-on-ones, roundtables, sales visits, email exchanges, and so forth. I’m pretty confident about what our clients want to buy because I’ve talked to an awful lot of them. Most of those conversations are conducted without reference to the MQ, although many clients do look at the MQ first, and come prepared with questions about specific vendors.
But my job isn’t to tell clients the benefits of an “objectively right” decision. I’m not in the business of telling him what he should want, although I can tell him what other companies do as a best practice. And frankly, clients don’t need me to tell them to go be more innovative. In most cases, they want to be able to venture boldly into the benefits of cloud computing, but there are many business and technical circumstances that they need to factor into their decision-making, and most have serious needs for risk mitigation. Ihave to help a client come to a decision that will work for him. He’s going to pay for it, he’s going to be the one defending it to his management, and he’s going to be the one who pays the price if it goes all pear-shaped. I wrote previously about our IT buyer audience, and my belief that my formal research writing should highly pragmatic for their needs, not a reflection of what I think the market should want, so I won’t go into that again here — see that post instead.
By the way, on Bob’s “you ought to explain to the vendors slighted” gripe: Every single vendor on the MQ was entitled to a phone call with me — it’s a mandatory Gartner courtesy extended to all participants, regardless of client status, when they receive a draft for their review. I had long conversations on the phone, as well as in email, with many vendors (regardless of placement), about the MQ, their own placements, and the placements of other vendors. I assure you that they understand why things are the way they are (even if they don’t necessarily agree).
Bob wrote: It is obvious and absurd not to rank Amazon Web Services at least among the leaders. If youre going to take that step, it’s a bold one, and needs to be expressed up front with no ambiguity and leading with a willingness to have a big discussion about it. Gartner didn’t do that either. They just presented their typical blah, blah, blah report.
As I explained in my earlier post about the MQ process, we don’t position vendors arbitrarily. We decide scoring criteria, and we score vendors on those criteria, and they come out where they come out. In this case, we looked at the resulting MQ and the placement of the pure-plays and decided we should do a mid-year update that focused on purely self-managed cloud IaaS, in addition to the Critical Capabilities note due to be published soon, which is also pure-play focused. (I think much will become clearer once the Critical Capabilities is out, and I wish we’d been able to publish them near-simultaneously.)
We do not call out commentary about specific vendors in a Magic Quadrant, as a matter of policy; the document follows a very strict format. However, we’re always happy to discuss anything we write with our clients. Moreover, even though Gartner considers social media engagement (whether blogging or otherwise) for analysts to be personal time and not actual work, I think I’ve been pretty thoroughly engaged with people in discussing the MQ both in the blogosphere and on Twitter (@cloudpundit). I’m not sure how Bob is concluding that there’s not a willingness to have a big discussion about it (although I am specifically refraining from going into detail on Amazon’s rating on my blog, since it is against Gartner policy to do so).
The cloud/hosting Magic Quadrant audience
Simon Ellis over at LabSlice has posted a blog entry in which he notes that the recent Cloud IaaS and Web Hosting Magic Quadrant has, in his words, “an obvious bias towards delivering ‘enterprise’ cloud services“. He goes on to say, “Security, availability and professional services — Gartner is clearly responding to dot-points mentioned to them by the large corporates that consume their material. And I daresay that these companies may not be needing cloud IaaS, but just want to be part of the hype.”
I think his point is worth addressing, because it’s true that the MQ is written to an audience of such companies and is very explicit in the fact that we are rating enterprise-grade services, but not true that these companies just want to be part of the hype. That seems to be part of the confusion over what cloud IaaS is about, too. At Gartner, we’re excited by the whole consumerization-of-IT trend that intertwines with the cloud computing phenomenon. But we’re not writing for the individual dude, or the garage developers, or the rebels who want IT stuff without IT people. We’re writing for the corporate IT guy.
Our target audience for a Magic Quadrant is IT buyers — specifically, our end-user clients. They typically work in mid-sized businesses and large enterprises, but we also serve technology companies of all sizes. However, the typical IT buyer who uses this kind of research is the kind of person who turns to an analyst firm for help, which means that they are somewhat on the conservative and risk-averse side. It’s not that they’re not willing to be early adopters or to take risks, mind you. And they’ve embraced the cloud with a surprising enthusiasm. But they’re cautious. Our surveys and polls show that overwhelmingly, security is their top cloud concern, for instance — far and above anything else.
We expect that the IT buyer in our client audience is typically going to be sourcing cloud IaaS on behalf of his organization. He is not an individual developer looking to grab infrastructure with a credit card; in fact, he is probably somebody who is explicitly interested in preventing his developers from doing that. He might work for a start-up that’s looking for a cost-effective way to get infrastructure with no capex, but chances are he’s post-funding or post-revenue if his company can afford to be a Gartner client, so he he shares many so-called “enterprise” concerns — security, availability, performance, and so forth. Managed services options play into a lot of thinking, too — for established companies more in an “offload my hassle” way, and for start-ups more in a “I don’t have an operations team, really, so I’d like to deal with ops as little as possible” way. And yes, professional services can be a help — tons of our clients are head-scratching figuring out what’s the best way to move their infrastructure into the cloud.
Simon Ellis seems to think, from his blog post, that these corporate guys don’t actually need cloud, they just want to be a part of the hype. I think he’s wrong. The sheer number of actual sourcing discussions we’re having with our IT buyer clients — vendor short-listing, requirements, RFPs, contracts, etc. — make it very clear that they’re buying, right now. And they’re buying for real. Production websites / SaaS / etc., production “virtual data centers”, large-scale test-and-development virtual lab environments, cloud-based disaster recovery… This is real business, so to speak.
It’s not an overnight revolution. This is a transition. It usually represents only a portion of their overall IT infrastructure — usually a tiny percentage, although it grows over time. They usually don’t want to make any application changes in the process. They almost certainly aren’t designing to fail. Most of them aren’t building cloud-native apps — although an increasing number of them are beginning to deliberately try to build new applications with cloud-friendly design in mind. Few of them are really taking advantage of the on-demand infrastructure capabilities of the cloud. What they are doing, in other words, is not especially sexy. But they are spending money on the cloud, and that’s what matters in the market right now.
And so in the end, the Magic Quadrant is written to emphasize what we see our clients asking about right now. It’s not cloudy idealism, that’s for sure. And most deals contain some level of managed services, which is why there’s significant weighting on them in the Magic Quadrant. (Fully self-managed is nevertheless a crucial market segment that deserves its own MQ, later this year, although I think the interesting note there will turn out to be the upcoming Critical Capabilities, which is wholly focused on feature-set. Though it should be noted that even a cloud-only MQ is going to emphasize an enterprise-oriented feature-set, not a developer-centric one.)
When we were setting the evaluation criteria for this most recent MQ, we decided that the Execution axis would be wholly focused upon the things we were hearing our clients demand right now, and the Vision axis would be primarily focused upon where we thought cloud services would be going.
The immediate demands are probably most easily summed up as “improved agility at a comparable or lower cost, with no change to our applications, limited impact on IT operations, and limited risks to our business”. The ultimate compliment that one of our clients can give a cloud IaaS provider seems to be, “It works just like my virtualized infrastructure in my own data center, but it’s less hassle.” That’s what they say to each other at our end-user roundtables at conferences when they’re trying to convince non-adopters to adopt.
I’m a pragmatist in most of my published research. I think that as an analyst, it’s fun to prognosticate on the future, but ultimately, I’m cognizant that what ultimately pays my salary is an IT buyer coming to me for advice, and feeling afterwards like I helped him think through making the choice that was right for him. Not necessarily the ideal choice, almost certainly not the most forward-thinking choice, but the choice that would deliver the best results given the environment he has to deal with. Ditto for a vendor who comes to me for advice — I want to reflect what I think the market evolution will be and not what I think it should be.
I’m not here to cheerlead for the cloud. It doesn’t mean that I don’t believe in the promise of the cloud, or that I’m not interested in the segments of the market that aren’t represented by Gartner’s IT buyer clients (I’ve certainly been keeping an eye on developer-centric clouds, for instance), or that I don’t understand or believe in the fundamental transformations going on. But we’ve got to get there from here, and that’s doubly true when you’re talking to corporate buyers about what cloud-like stuff they want now.
The process of a Magic Quadrant
There’ve been a number of ongoing dialogues on Twitter, on Quora, and various people’s blogs about the Magic Quadrant. I thought, however, that it would be helpful to talk about the process of doing a Magic Quadrant, before I write another blog post that explains how we came to our current cloud-and-hosting MQ. We lay this process out formally in the initiation letters sent to vendors when we start MQ research, so I’m not giving away any secrets here, just exposing a process that’s probably not well known to people outside of analyst relations roles.
A Magic Quadrant starts its life with a market definition and inclusion criteria. It’s proposed to our group of chief analysts (each sector we cover, like Software, has a chief), who are in charge of determining what markets are MQ-worthy, whether or not the market is defined in a reasonable way, and so forth. In other words, analysts can’t decide to arbitrarily write an MQ, and there’s oversight and a planning process, and an editorial calendar that lays out MQ publication schedules for the entire year.
The next thing that you do is to decide your evaluation criteria, and the weights for these criteria — in other words, how you are going to quantitatively score the MQ. These go out to the vendors near the beginning of the MQ process (usually about 3 months before the target publication date), and are also usually published well in advance in a research note describing the criteria in detail. (We didn’t do a separate criteria note for this past MQ for the simple reason that we were much too busy to do the writing necessary.) Gartner’s policy is to make analysts decide these things in advance for fairness — deciding your criteria and their weighting in advance makes it clear to vendors (hopefully) that you didn’t jigger things around to favor anyone.
In general, when you’re doing an MQ in a market, you are expected to already know the vendors well. The research process is useful for gathering metrics, letting the vendors tell you about small things that they might not have thought to brief you on previously, and getting the summary briefing of what the vendor thought were important business changes in the last year. Vendors get an hour to tell you what they think you need to know. We contact three to five reference customers provided by the vendor, but we also rely heavily upon what we’ve heard from our own clients. There should generally not be any surprises involved for either the analysts or the vendors, assuming that the vendors have done a decent job of analyst relations.
Client status and whatnot doesn’t make any difference whatsoever on the MQ. (Gartner gets 80% of its revenue from IT buyers who rely on us to be neutral evaluators. Nothing a vendor could pay us would ever be worth risking that revenue stream.) However, it generally helps vendors if they’ve been more transparent with us, over the previous year. That doesn’t require a client relationship, although I suspect most vendors are more comfortable being transparent if they have an NDA in place with us and can discuss these things in inquiry, rather than in the non-NDA context of a briefing (though we always keep things confidential if asked to). Ongoing contact tends to mean that we’re more likely to understand not just what a vendor has done, but why they’ve done it. Transparency also helps us to understand the vendor’s apparent problems and bad decisions, and the ways they’re working to overcome them. It leads to an evaluation that takes into account not just what the vendor is visibly doing, but also the thought process behind it.
Once the vendors have gone through their song and dance, we enter our numeric scores for the defined criteria into a tool that then produces the Magic Quadrant graph. We cannot arbitrarily move vendors around; you can’t say, well, gosh, that vendor seems like they ought to be a Leader / Challenger / Visionary / Niche Player, let’s put them in that box, or X vendor is superior to Y vendor and they should come out higher. The only way to change where a vendor is placed is to change their score on the criterion. We do decide the boundaries of the MQ (the scale of the overall graph compared to the whitespace in the graph) and thus where the axes fall, but since a good MQ is basically a scatterplot, any movement of axis placement alters the quadrant placement of not just one vendor but a bunch.
Once the authoring analysts get done with that, and have done all the write-up text, it goes into a peer review process. It’s formally presented in a research meeting, any analyst can comment, and we get challenged to defend the results. Content gets clarified, and in some cases, text as well as ratings get altered as people point out things that we might not have considered.
Every vendor then gets a fact-check review; they get a copy of the MQ graphic, plus the text we’ve written about them. They’re entitled to a phone call. They beg and plead, the ones who are clients call their account executives and make promises or threats. Vendors are also entitled to escalate into our management chain, and to the Ombudsman. We never change anything unless the vendor can demonstrate something is erroneous or unclear.
MQs also get management and methodologies review — ensuring that the process has been followed, basically, and that we haven’t done anything that we could get sued for. Then, and only then, does it go to editing and publication. Theoretically the process takes four months. It consumes an incredible amount of time and effort.
(Please note that per Gartner’s social media policies for analysts, I am posting this strictly as an individual; I am not speaking on behalf of the company.)
The impurity of cloud
I’ve already agreed that people would find it useful to see a Magic Quadrant that is focused solely on a particular segment of the market — “pure” cloud IaaS. That’s why we’re going to be doing one in the middle of this year, as I noted previously. It’s also why our upcoming Critical Capabilities note, which focuses solely on product features, is cloud-only. (A Magic Quadrant, on the other hand, is about overall markets, which means we factor in sales, marketing, etc. — it’s not about fitness for use, whereas the Critical Capabilities are.)
However, I still think it’s important to understand the inherent messiness of this market, which is why we currently have an MQ that covers not just cloud IaaS, but also the hosting market.
I’ve previously talked about how customers have different levels of desire for managed services with the cloud. In that blog post, I also touched on the difference between trying to source cloud for a single important application (or a tightly-related group of apps), and sourcing cloud for a bunch of multiple less-critical applications.
Customers who are trying to source cloud for a single important application are essentially looking at hosting; the cloud is offering them on-demand, elastic resources. That’s why cloud has impacted the hosting industry so strongly — people want the flexibility and agility, but it doesn’t change the fact that they have traditional hosting requirements. As always with hosting, customers run the gamut from those who just want infrastructure, to those who want it fully managed. Customers often don’t know what they want, either, as I described in a blog post a while back, called, “I’m thinking about using Amazon, IBM, or Rackspace…” — which is how you get a weird mix of vendors in an RFP, as a customer tries to explore the possibilities available to them.
Customers who are trying to source cloud for multiple, less-important applications — essentially, the first steps towards replacing a traditional data center with a cloud IaaS solution — have different needs. Their requirements are distinct, but many of the provider capabilities that are useful for hosting are also useful for delivering these solutions, which is why so many Web hosters have expanded into this market.
You can cross “single app or multiple app?” with “what level of managed services?” to derive a set of distinct market segments — in fact, I’m in the midst of writing a research note on market segmentation that does exactly that. I believe it’s still all one market, and that most providers will end up serving multiple segments of that market. I believe that all of those segments are important, not just the ones closest to the cloud pure-play model.
I think, as an analyst, that it can be tempting to follow only the most compelling, fast-growing, quickest-evolving pieces of a market — to get caught up in the excitement, so to speak. My IT buyer clients force me to be balanced, though, because they care about a lot more than just what’s hot. Clearly, right now, they need more help sourcing in specific segments, which is why we’re doing some narrower vendor ratings focused on a more “pure cloud” tilt — but that shouldn’t be taken as an indication that the other segments aren’t important.