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.
Read Complimentary Relevant Research
Predicts 2017: Artificial Intelligence
Artificial intelligence is changing the way in which organizations innovate and communicate their processes, products and services. Practical...
View Relevant Webinars
How to Protect Mobile Apps
Securely enabling applications on corporate- or employee-owned devices is key to protecting enterprise data from misuse. From containers...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.