Category Archives: Marketing
In cloud IaaS, developers are face of business buyers
I originally started writing this blog post before Forrester’s James Staten made a post called “Public Clouds Prove I&O Pros Are From Venus And Developers Are From Mars“, and reading made me change this post into a response to his, as well as covering the original point I wanted to make.
In his post, James argues that cloud IaaS offerings are generally either developer-centric or I&O-centric, which leads to an emphasis on either self-service or managed services, with different feature-set priorities. Broadly speaking, I don’t disagree with him, but I think there’s a crucial point that he’s missing (or at least doesn’t mention), that is critical for cloud IaaS providers to understand.
Namely, it’s this: Developers are the face of business buyers.
We can all agree, I’m sure, that self-service cloud IaaS of the Amazon variety has truly empowered developers at start-ups and small businesses, who previously didn’t have immediate access to cheap infrastructure. Sometimes these developers are simply using IaaS as a substitute for having to get hardware and colocation. Sometimes they’re taking advantage of the unique capabilities exposed by programmatic access to infrastructure. Sometimes they’re just writing simple Web apps the same way they always have. Sometimes they’re writing truly cloud-native applications. Sometimes they really need to match their capacity to their highly-variable needs. Sometimes they have steady-state infrastructure. You can’t generalize about them too broadly. But their reasons for using the cloud are pretty clear.
But what’s driving developers in well-established businesses, with IT Operations organizations that have virtualized infrastructure and maybe even private cloud, to put stuff in the public cloud?
It’s simple. They’ve asked for something and IT Operations can’t give it to them in the timeframe that they need. Or IT Operations is such a pain to deal with that they don’t even want to ask. (Yes, sometimes, they want programmatic infrastructure, have highly variable capacity needs, etc. Then they think like start-ups. But this is a tiny, tiny percentage of projects in traditional businesses, and even a small percentage of those that use cloud IaaS.)
And why do they want something? Well, it’s because the business has asked the applications development group to develop a thingy that does X, and the developer is trotting off to try to write X, only he can’t actually do that until IT Operations can give him a server on which to do X, and possibly some other stuff as well, like a load balancer.
So what happens is you get a developer who goes back to a business manager and says, “Well, I could deliver you the code for X in six weeks, except IT Operations tells me that they can’t get around to giving me a server for it for another three weeks.” (In some organizations, especially ones without effective virtualization, that can be months.) The business manager says, “That’s unacceptable. We can’t wait that long.” And the developer sighs and says, “Don’t worry about it. I’ll just take care of it.” And then some cloud IaaS provider, probably one who’s able to offer infrastructure, right now, gets a brand-new customer. This is what businesses mean when they talk about “agility” from the cloud.
Maybe the business has had this happen enough that Enterprise Architecture has led the evaluation of cloud IaaS providers, chosen one or more, set down guideliens for their use, and led the signing of some sort of master services agreement with those providers. Or maybe this is the first sign-up. Either way, developers are key to the decision-making.
When it comes to go into production, maybe IT Operations has its act together, and it comes back into the business’s data center. Maybe it has to move to another external provider — IT Operations has sourced something, or Enterprise Architecture has set a policy for where particular production workloads must run. So maybe it goes to traditional managed hosting, hybrid hosting, or a different cloud provider. Maybe it stays with the cloud the developer chose, though. There’s a lot to be said for incumbency.
But the key thing is this: In SaaS, business buyers are bypassing IT to get their own business needs met. In IaaS, business buyers are doing the same thing — it’s just that it’s the developer that is fronting the sourcing, and is therefore making the decision of when to go cloud and who to use when they do, at least initially.
So if you’re a cloud provider and you say, “We don’t serve individual developers” (which, in my experience, you’ll generally say with a sneer), you are basically saying, “We don’t care about the business buyer.” Which is a perfect valid sales strategy, but you should keep in mind that the business controls two-thirds of cloud spending (so IT Operations holds the purse-strings only a third of the time), according to Gartner’s surveys. You like money, don’t you?
There are many, many more nuances to this, of course (nuances to be explored in a research note for Gartner clients, naturally, because there’s only so much you get for free). But it leads to the conclusion that you must be able to sell to both developers and IT Operations, regardless of the nature of your offering, unless you really want to limit your market opportunity. And that means that the roadmaps of leading providers will be convergent to deliver the features needed by both constituencies.
The Global Internet Speedup Initiative
The rather prosaically-named, if accurately and precisely named, IETF draft specification, “Client Subnet in DNS Requests” (“edns-client-subnet”), has gotten some breathless marketing spin as the Global Internet Speedup Inititative.
I blogged about this about a year and a half ago: “Google’s DNS protocol extension and CDNs“. See that post for a deeper analysis. (I also previously blogged about the problem with using DNS as the CDN vantage point.)
My opinion on this hasn’t changed. In the intervening time, various DNS service providers and CDN providers have contributed to the draft, and the end result seems to be pretty reasonable. The extension solves a common problem for the CDNs — returning appropriately close CDN servers to an end-user who is using a DNS resolver that’s not close to his own location (common for users on some ISP networks, along with those who use resolvers from OpenDNS, Neustar, etc., and potentially for some users in enterprise networks).
But I am impressed with the amount of hype that the vendors involved have managed to generate about a fiddly little technical detail that ordinary users have probably never thought about and shouldn’t ever really need to think about.
New gTLDs require a business case
Recently, I’ve been deluged with client inquiries about the new gTLDs that ICANN finally approved last month. (That’s three years after they first accepted the gTLD stakeholder recommendation, and two years after they said they expected to start taking applications… which they now say they won’t do until January 2012.)
Tonight, I decided to write a research note, in hopes of persuading clients to read the note rather than trying to talk to me. I sat down at 5 pm to write it. I figured it’d be a quick little note. I finished at 3 am, with an hour break for dinner. It’s not a short note, and I’m not convinced that it’s really as complete as it should be, so it’s not done per se, and it still needs peer review…
I’ll throw out a couple of quick thoughts on this blog, though, and invite you to challenge my thinking:
- If you’re going to get a gTLD, you should start with the business plan, driven by your business / marketing guys, not IT security guys nattering about defensive moves. Lots of organizations won’t be able to come up with reasonable business plans, especially given the cost.
- A gTLD is valuable to a business with many affiliates or affinity sites. That includes companies that franchise or have agents, companies with partner networks, and companies that have big fan communities. It may also include companies that have a ton of unique names that need to be associated with a domain, for some reason, or which otherwise need a namespace to themselves.
- Most companies won’t become .brand rather than brand.com; among other things, nobody knows what second-level domains are going to be logical, in many cases. Global companies currently operating under a mess of country-specific domains may usefully consolidate under a .brand, though.
- Government entities are facing a ton of hype, especially from consultants selling gTLD-related services. But most governments won’t significantly benefit from a gTLD for their locale, and the benefits to residents of a geographic-name gTLD are pretty limited. (That doesn’t mean that you can’t make a successful business out of a geographic name, though; at the very least you’ll get the obligatory defensive registrations.)
- Defensive registrations of gTLDs are relatively pointless. Nobody’s going to cybersquat for the kind of money that a gTLD costs to apply for and operate, and the dispute process is so expensive that people aren’t going to go spend money applying for a gTLD that’s likely to be contested on trademark grounds.
- There will be some contention for generic terms, both by companies associated with those terms, trade associations, and registry businesses that want to operate general-public registries for those terms.
- The proliferation of new gTLDs is going to multiply everyone’s defensive registration headaches for domain names. Many new gTLD registries will probably make most of their money off defensive registrations, and not active primary-use domains. This is very sad and creates negative value in the world.
I’m a fan of the digital brand management guys — companies like MarkMonitor, Melbourne IT, and NameProtect (Corporation Services Company, the “other CSC”), to name a few. I think they have a lot of specialized knowledge and I tend to recommend that clients who need in-depth thinking on this stuff use them. If you really want to dive into gTLD strategy, they’re the folks to go to. (Yes, I know there are tons of other little consultancies out there that now claim to specialize in gTLDs. I don’t trust any of them yet, and what my clients have told me about their interactions with various such shops hasn’t made me feel better about their trustworthiness. Beware of consultants who either try to scare you or make your eyes light up in dollar symbols.)
Watch the rhetoric
A number of years, an executive at a vendor made a very honest and very funny comment to me during a briefing. The gist of it was this: For years, they’d disdained the technologies that Generation X was interested in — Linux, open source, and so forth. They had, in fact, been generally contemptuous of them, and of the up-and-coming young’uns in corporate IT who were interested in those technologies. And then, ten years passed, and those Gen Xers that they’d been so dismissive of began getting promoted to director-level in corporate IT. And so now they were in charge of sourcing — and they hated that vendor.
That vendor ended up having to spend a lot of money on a marketing campaign that was targeted at Gen X, but I don’t think they’ve ever fully recovered from those years. Even though they’re now perfectly capable of managing the new generation of technology, they are still perceived as stodgy, and not a vendor to look to for innovation (despite actually being pretty innovative, compared to their competitors).
Over the last two years, I’ve been seeing a lot of echoes of that in my conversations with vendors, including service providers. (The naysayer rhetoric around public cloud sometimes sounds a lot like the naysayer rhetoric around Linux in the 1990s.) Cloud naysayers talk about how the enterprise will never trust outside providers or shared environments, be willing to give up most if not all customization in order to drive cost and agility, and so forth. But even if at least part of this generation of IT leadership feels that way, the next generation is highly unlikely to. Digital natives will soon reach crucial levels of IT decision-making even in the traditional enterprise, and there’s a truly cloud-native generation entering the workforce, as well, who will start exerting corporate purchasing power in a few years. The entire mindset of an organization and its approach to sourcing ultimately often hinges on individuals, and generational turnover in IT management shouldn’t be ignored.
Vendors who dismiss the significance, importance, and reality of public cloud computing risk silently alienating future IT leaders. There’s a difference between a realistic immediate approach to the market, which has to acknowledge enterprise concerns and ways of doing business and create a path to migrate to the cloud, and conveying the sense that cloud isn’t for real businesses.
Getting on an analyst’s radar screen
I’ve been spending about a quarter of my time in the Bay Area for the better part of this year, a lot of my vendor-facing time has been with start-ups, and I spent much of my HostingCon time with start-ups whose executives have never interacted with analysts in the past, so a couple of FAQs are top of mind at the moment.
Emerging technology companies often ask me, “How do I get on your radar screen?” and sometimes, “How do I get you to write about our company?” (Venture capitalists often ask the same questions on behalf of their portfolio companies, too.)
I wrote a post about making a briefing request before; if you haven’t read it, I’d encourage you to do so, before continuing on with this post. So let’s assume that you’ve gone and asked for a briefing, and now you’re wondering what you should be doing to use that time to make a convincing case for why an analyst should continue to follow you.
Gartner analysts, as a matter of policy, do not take client relationships into account when deciding whether or not to follow a company. We choose which briefing requests we do or don’t take, and which companies we write about, solely based on whether or not we and our clients find a company to be of interest. If you’re a vendor client, you are always entitled to make an inquiry, tell us about your business, and ask specific questions — i.e., whether or not we find you worthy of covering in general, we are required to fulfill such requests — but it doesn’t get you any other special privileges with regard to coverage.
So, what makes a vendor interesting?
Client interest. If our end-user (IT buyer) clients are calling and asking about you, we want to know as much about you as possible, so that we can intelligently answer questions. If competitors and investors are calling and asking about you, ditto.
Unique vision or technology. If you’re doing something cool and different, either in implementation or the way you’re thinking about the market, that’s always of interest to us. We’re always interested in market mavericks, as well as people along the bleeding edge who might be tomorrow’s market leaders. We’re also hugely interested in blue-ocean companies, doing something that nobody else is.
Meaningful differentiation. Even if you’re not doing something that’s really unique, you should be able to articulate the things that meaningfully differentiate you from the competition, both in terms of where you see your company going, and the actual features and roadmap of your product or service.
Rapid growth. Evidence of market traction in terms of customer wins, especially enterprise customer wins, and fast revenue growth, is an indicator that we need to pay attention to you, because you’re clearly growing in importance. We like metrics, by the way. Knowing how many customers you have, how much you’ve grown recently, and the ballpark of your revenues, lets us know where you are adoption-wise.
Management team track record. If we know your management team from previous successes, we are much more likely to believe that your new venture will succeed, and will exhibit interest accordingly. (Also, if we have a prior relationship with you, our interest in interacting is likely to carry across between the companies you work for.) First-rate investors help, too; they’re usually a sign that some very smart people think you have a clue.
In short, your goal, if you’d like me to cover you, is to try to convince me that I need to know about you, because you’re going to be successful, my clients are going to want to know about you, and you’re going to be doing something interesting that’s worth my time to learn about. In other words, convince me that spending time researching you is not a waste — that I won’t be filling my brain with information that won’t translate to eventual client value.
Smoke-and-mirrors and cloud software
On my more cynical, read-too-many-press-releases days, I wonder if there’s some hapless, tortured PR gnome at Amazon whose job consists solely of vetting one empty cloud fluff piece after another, proclaiming how such-and-such a vendor is now offering deployments on EC2, and how this therefore gives them an on-demand cloud offering (“please think of me as hip and visionary!”), when in reality, the vendor is doing nothing other than packaging up its software as an AMI (an Amazon machine image, basically a disk image of a server with the application installed).
Packaging something up as an AMI doesn’t make it a cloud service. It doesn’t make it massively scalable, automatically scalable, transparently scalable, on-demand, multi-tenant, or any one of a vast number of other terms that get fatuously lavished on anything with a whiff of cloudiness. If a piece of software doesn’t have any cloud traits when it’s deployed in your data center, it won’t have them when it’s deployed on EC2 (or any other cloud infrastructure service), either.
![[the cake is a lie]](https://cloudpundit.files.wordpress.com/2009/03/cake_lie.jpg?w=150&h=150)
Cloud infrastructure services today, whether EC2 or from one of Amazon’s competitors, are basically servers in the sky. They are almost always a hypervisor-virtualized server with a normal operating system installation, on top of which you install normal applications. There is no magic cloud pixie dust that settles on these instances and turns them into application faeries of scalability and joy.
Building massively and horizontally scalable, multi-tenant software with elastic economics is hard. It’s even harder if you’re trying to take some legacy software package and re-engineer it. This is why practically no one does that kind of re-engineering, and why software vendors have to resort to puffed-up “yes, we run on EC2!” claims, rather than genuinely delivering on-demand cloud services.
Don’t be fooled.
Marketing and PR folks at software vendors: I forgive you for these releases because I know you’re under pressure to put something out, but every time I read them, I cringe on your behalf, and hope that you’re not genuinely entertaining the belief that releasing an AMI meaningfully moves you forward along the cloud path.
IT folks: When your CEO / CFO / CIO comes to you and asks you why you aren’t taking advantage of your software vendor’s awesome new money-saving cloud service, you can tell him it’s because the PR release is just artfully painting a unicorn — a mythical beast everyone talks about but doesn’t actually exist.
The (temporary) death of premium
We’re in the midst of a fascinating discontinuity in IT purchasing patterns. Even the dot-com crash didn’t cause this kind of disruption. Practically everyone is scrambling to save money immediately, and some organizations are looking at long-term belt-tightening.
The most obvious immediate impact is that buyer tolerance for paying a premium is rapidly diminishing. Quality is suddenly being eyed with greater objectivity, as businesses stop feeling like they need to have “the best” and start actively considering what services and service levels they really need and can cost-justify. It doesn’t matter (enough) if they love their current vendor and feel they’re getting excellent value for the money. It’s about absolute dollar amounts and aligning spend with needs rather than want-to-haves. Risks are being taken in the name of the bottom line.
Google Federal
I heard a radio ad today for Google Federal. It sounded like every other “please, government IT purchasing person, buy our stuff” ad that you hear on news radio in Washington DC. It was a far cry from the sort of ad that one expects to hear from Google, and to hear a federal-targeted ad from them, period, was sort of fascinating.
The Federal government can still afford stuff (and is probably one of the few bright spots in purchasing this year, period). It’s the states that are screwed, and seriously thinking about alternatives to traditional IT.
Predictably Irrational
If you deal with pricing, or for that matter, marketing or sales in general, and you’re going to read one related book this year, read Predictably Irrational: The Hidden Forces That Shape Our Decisions, by Dan Ariely. (I mentioned an article by him in a previous post on the impact of transparent pricing for CDNs, and I’ve finally had time to read his book.)
The book deals with behavioral economics, which can be summed up as the science of the way we perceive value and make economic decisions. It’s an entertaining read, describing a variety of experiments, their outcomes, and the broader conclusions that can be drawn. The book does an excellent job of demonstrating that we do not make such decisions in a fully rational manner, even when we think we are — but because there’s a predictable pattern to this irrationality, you can market and sell accordingly.
Two thoughts, among many others that I’m mulling over as a result:
Ariely asserts that people don’t know what new things ought to cost — they have no basis for comparison. Thus, establishing a basis for comparison creates the sense of value, and can be used to manipulate people’s mental pricing baselines and influence their decisions. For instance, given a thing, an inferior version but cheaper version of that thing, and some other less-similar thing, people will generally choose the thing. That’s relevant when you think about the way people compare CDN services, especially first-time enterprise buyers.
Ariely also shows that given a useful but brand-new thing, people might not know whether it’s a good value and thus may choose not to buy it — but establish a comparison in the form of a bigger but much more expensive form of that thing, and people will see the original as a good value and buy it. This is hugely relevant in the emerging cloud computing market, where people aren’t yet certain what the billing units should be and what they should cost.
Relating this to my usual topics of interest: Amazon has essentially established a transparent baseline in both the cloud computing and CDN markets, with clearly-articulated, readily-available pricing, and as a result, they have implicit control of the conversation around pricing. Broadly, any vendor who puts a public stake in the ground on prices is going to exert influence over a customer’s perception of not only their value, but every other comparable vendor.
Peer influence and the use of Magic Quadrants
The New Scientist has an interesting article commenting that the long tail may be less potent than previously postulated — and that peer pressure creates a winner-take-all situation.
I was jotting this blog post about Gartner clients and the target audience for the Magic Quadrant, and that article got me thinking about the social context for market research and vendor recommendations.
Gartner’s client base is primarily mid-sized business to large enterprise — our typical client is probably $100 million or more in revenue, but we also serve a lot of technology companies who are smaller than that. Beyond that subscription base, though, we also talk to people at conferences; those attendees usually represent a much more diverse set of organizations. But it’s the subscription base that we mostly talk to. (I carry an unusually high inquiry load — I’ll talk to something on the order of 700 clients this year.)
Normally, I’m interested in the comprehensive range of a vendor’s business (at least insofar as it’s relevant to my coverage). When I do an MQ, though, my subscriber base is the lens through which I evaluate companies. While I’m interested in the ways vendors service small businesses at other times, when it’s in the context of an MQ, I care only about a vendor’s relevance to our clients — i.e., the IT buyers who subscribe to Gartner services and who are reading the MQ to figure out what vendors they want to short-list.
Sometimes, when vendors think about our client base, they mistakenly assume that it’s Fortune 1000 and the largest of enterprises. While we serve those companies, we have more than 10,000 client organizations — so obviously, we serve a lot more than giant entities. The customers I talk to day after day may have a single cabinet in colocation — or fifty data centers of their own. (Sometimes both.) They might have one or two servers in managed hosting, or dozens of websites deployed via multi-dozen-server contracts. They might deliver less than a TB of content per month via a CDN, or they might be one of the largest media companies on the planet, with staggering video volumes.
These clients span an enormous range of wants and needs, but they have one significant common denominator: They are the kinds of companies that subscribe to a research and advisory firm, which means they make enough tech purchases to justify the cost of a research contract, and they have a culture which values (or at least bureaucratically mandates) seeking a neutral outside opinion.
That ideal of objectivity, however, often masks something more fundamental that ties back to the article that I mentioned: namely, the fact that many clients have an insatiable hunger to know “What are companies like mine doing?“. They are not necessarily seeking best practice, but common practice. Sometimes they seek the assurance that their non-ideal situation is not dissimilar to that of their peers at similar companies. (Although the opening line of Tolstoy’s Anna Karenina — “Happy families are all alike, but every unhappy family is unhappy in its own way” — quite possibly applies to IT departments, too.)
This is also reflected in the fact that customers often have a deep desire to talk to other customers of the same vendor, on an informal and social basis. That hunger is sometimes satisfied by online forums, but the larger the company, the more reluctant they are to discuss their business in public, although they may still share freely in a one-on-one or directly personal context.
IBM was the ultimate winner-take-all company (to use the New Scientist phrase) — the company that everyone was buying from, thus guaranteeing that you were unlikely to get fired buying IBM. Arguably, it and its brethren still are at the fat forefront of the outsourced IT infrastructure market share curve, while the bazillion hosting companies out there are spread out over the long tail. Even within the narrower confines of pure hosting, which is a highly fragmented market, and despite massive amounts of online information, peer influence has concentrated market share in the hands of relatively few vendors.
To quote the article: Which leads to a curious puzzle: why, when we have so much information at our fingertips, are we so concerned with what our peers like? Don’t we trust our own judgement? Watts thinks it is partly a cognitive problem. Far from liberating us, the proliferation of choice that modern technology has brought is overwhelming us — making us even more reliant on outside cues to determine what we like.
So I can sum up: A Magic Quadrant is an outside cue, offering expert opinion that factors in aggregated peer opinion.
CloudPundit: Massive-Scale Computing 