Monthly Archives: January 2011
Amazon recently released a new offering called the Elastic Beanstalk. At its heart, it is a simplified interface to EC2 and its ancillary services (load-balancing, auto-scaling, and monitoring integrated with alerts), along with an Amazon-maintained AMI containing Linux and Apache Tomcat (an open source Java EE application server), and a deployment mechanism for a Java app (in the form of a WAR file), which notably adds tighter integration with Eclipse, a popular IDE.
Many people are calling this Amazon’s PaaS foray. I am inclined to disgree that it is PaaS (although Amazon does have other offerings which are PaaS, such as SimpleDB and SQS). Rather, I think this is still IaaS, but with a friendlier approach to deployment and management. It is developer-friendly, although it should be noted that in its current release, there is no simplification of any form of storage persistence — no easy configuration of EBS or friendly auto-adding of RDS instances, for example. Going to the database tab in the Elastic Beanstalk portion of Amazon’s management console just directs you to documentation about storage options on AWS. Almost no one is going to be running a real app without a persistence mechanism, so the Beanstalk won’t be truly turnkey until this is simplified accordingly.
Because Elastic Beanstalk fully exposes the underlying AWS resources and lets you do whatever you want with them, the currently-missing feature capabilities aren’t a limitation; you can simply use AWS in the normal way, while still getting the slimmed-down elegance of the Beanstalk’s management interfaces. Also notably, it’s free — you’re paying only for the underlying AWS resources.
Amazon exemplifies the idea of IT services industrialization, but in order to address the widest possible range of use cases, Amazon needs to be able to simplify and automate infrastructure management that would otherwise require manual work (i.e., either the customer needs to do it himself, or he needs managed services). I view Elastic Beanstalk and its underlying technologies as an important advancement along Amazon’s path towards automated management of infrastructure. In its current incarnation, it eases developer on-boarding — but in future iterations, it could become a key building-block in Amazon’s ability to serve the more traditional IT buyer.
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.)
A little change of pace today, back to some CDN market news…
Rackspace forms a strategic alliance with Akamai. Today, Rackspace’s Cloud Files storage service is integrated with Limelight’s CDN. The new alliance means that Akamai will be replacing Limelight as the CDN, and some new features will be offered as the integration is done. (While those features are things that Limelight does for its regular customers, they were not integrated into the Rackspace cloud CDN service.) Rackspace currently uses Limelight as its CDN partner for regular hosting deals, as well, and intends to offer Akamai in the future. (Most hosters have channel deals of that sort with one or more CDNs.) What makes this interesting is that it marks the first significant integration of Akamai as a wholesale CDN to a cloud CDN — and that you’ll be able to get Akamai delivery for cloud CDN prices. (Gartner clients only: Is a Cloud CDN Right For You?)
Tata Communications buys BitGravity. Video CDN BitGravity was pretty cool and promising when it first came to market. A number of my clients in traditional media and established online companies really loved what they had to offer in the live-streaming space when they launched. Unfortunately, they never really manage to break out beyond that space. I always thought it was a bit weird for Tata to choose to license their technology as the basis for Tata’s own CDN, given Tata’s customer base and use cases that I’d expected to see Tata be successful at selling. Tata’s investment in them at the time seemed outrageously large to me — for what they paid, you’d have thought they could have just bought the company outright (especially given the rumored valuation of Panther Express when it was acquired by CDNetworks). I’d speculate that this was a desperation buyout for BitGravity, but there are lots of questions about the long-term value of this to Tata.
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).
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.
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.)
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.
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.
Let me start by saying that I have drunk the cloud Kool-Aid. I am a believer in its transformative power, and in the business models that it is enabling. I believe that the IT world will look very different in 10 years, and the 5-year differences will be noticeable. I believe in the success stories of the fresh young cloud-native companies.
But I also believe that you’ve got to get there from here. While I have the privilege of working with many smaller technology companies, including cloud-based start-ups, the vast majority of Gartner’s clients are mid-sized businesses and enterprises. Those clients have a vast array of existing IT investments, in both infrastructure and applications, as well as people, process, policies, and the like. Most of our clients are excited by the possibilities that the cloud is offering, and they’re interested in adopting all of it — SaaS, PaaS, IaaS. But they’ve got to figure out how to do it, how to make a sensible, risk-controlled move from what they’ve got today, including, importantly, the mindset and culture of what they have today, to the cloud future.
Our clients are looking for solutions to business needs. Many of them are also explicitly looking for an opportunity to use cloud for the sake of using cloud — to get their feet wet, to learn things, to satisfy the demands of a CEO or CFO, and so forth. As an analyst, my goal is to help my clients find solutions that they’ll be successful with. That’s not just purely about technology; I need to help clients find solutions that also work for their culture, their appetite for risk, their ability to manage change, the way they budget, the way they approach operations and applications and governance, the way they source solutions and manage vendors, their available personnel and their ability to learn new things, their timeframes and business needs, and so forth.
IT buyers are slowly transforming the way they think about cloud, as hype begins to give way to reality. We see people doing very sensible, pragmatic things with cloud IaaS, these days. For most organizations, it will be a five to ten year gradual transformation. The successful blending of old and new models, and the transitional models, are both critical parts to that transformation.
I think my feeling on these things is: Get excited, but don’t get excitable. Most of my research is pitched to people making decisions right now, which is typically about IT buyer immediate needs, and vendor one-year and two-year plans. With cloud, I often look at three-year and five-year scenarios, and we’re doing some ten-year scenarios as well, but that also involves having to think about the sequence and timeline for how things occur in the market.
Fast-evolving markets create and destroy new approaches, and there will always be transitional approaches, artifacts of “what tech is available at this stage” and “what customer mindset exists at this point”. The desires of customers at any given point should not necessarily be taken as the future direction of the market and what will lead to vendor success (or even customer success, ironically). Frankly, some of the things customers will ask for during the transition will be flat-out wacky and wrong. But it won’t change the fact that they want them.
As expected, the Magic Quadrant for Cloud IaaS and Web Hosting is stirring up much of the same debate that was raised with the publication of the 2009 MQ.
Derrick Harris over at GigaOM thinks we got it wrong. He writes: Cloud IaaS is about letting users get what they need, when they need it and, ideally, with a credit card. It doesn’t require requisitioning servers from the IT department, signing a contract for any predefined time period or paying for services beyond the computing resources.
Fundamentally, I dispute Derrick’s assertion of what cloud IaaS is about. I think the things he cites above are cool, and represent a critical shake-up in thinking about IT access, but it’s not ultimately what the whole cloud IaaS market is about. And our research note is targeted at Gartner’s clients — generally IT management and architects at mid-sized businesses and enterprises, along with technology start-ups of all sizes (but generally ones that are large enough to have either funding or revenue).
Infrastructure without a contract? Convenient initially, but as the relationship gets more significant, usually not preferable. In fact, most businesses like to be able to negotiate contract terms. (For that matter, Amazon does customzed Enterprise Agreements with its larger customers.) Businesses love not having to commit to capacity, but the whole market is shifting its business models pretty quickly to adapt to that desire.
Infrastructure without involving traditional IT operations? Great, but someone’s still got to manage the infrastructure — shoving it in the cloud does not remove the need for operations, maintenance, patch management, security, governance, budgeting, etc. Gartner’s clients generally don’t want random application developers plunking down a credit card and just buying stuff willy-nilly. Empower developers with self-provisioning, sure — but provisioning raw infrastructure is the easy and cheap part, in the grand scheme of things.
Paying for services beyond the computing resources? Sure, some people love to self-manage their infrastructure. But really, what most people want to do is to only worry about their application. Their real dream is that cloud IaaS provides not just compute capacity, but secure compute capacity — which generally requires handling routine chores like patch management, and dealing with anti-virus and security event monitoring and such. In other words, they want to eliminate their junior sysadmins. They’re not looking for managed hosting per se; they’re looking to get magic, hassle-free compute resources.
I obviously recognize Amazon’s contributions to the market. The MQ entry on Amazon begins 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. But I think Amazon represents an aspect of a broad market.
Cloud IaaS is complicated by the diversity of use cases for it. Our clients are also looking for specific guidance on just the “pure cloud”, self-provisioned “virtual data center” services, so we’re doing two more upcoming vendor ratings to address that need — a Critical Capabilities note that is focused solely on feature sets, and a mid-year Magic Quadrant that will be purely focused on this.
I could talk at length about what our clients are really looking for and what they’re thinking with respect to cloud IaaS, which is a pretty complicated and interesting tangle, but I figure I really ought to write a research note for that… and get back to my holiday vacation for now.