This is not one market, it's a hundred (or hundreds of) markets. There is no real big pattern to where the inflection points are. There are lots of little patterns.
We do not know:
- The line between what applications we will run and what we will totally outsource to SaaS
- The lines between what we will leave bare metal, what we will virtualize and what we will actually run in any cloud
- The line between what we will do on a public cloud and in a private cloud
- The degree, magnitude, and timescale of how "virtual private cloud" and "hosted private cloud" moves those lines
- The degree, magnitude, and timescale of how various approaches to cloudifying "legacy" apps via encapsulation, migration, replicating, etc., moves those lines
These lines are being drawn in different places by everyone--including similar orgs by sector or size or whatever and also by different groups within the same org.
Add to that the range of things that are called "private cloud"--everything from "I have a data center with some servers in it" to "I've built my own EC2, EBS, S3, ELB, SQS, and SNS with open source software on commodity hardware and can automate ALL THE THINGS".
Here's something I do know: any number put forth for private cloud market size, growth, or spend is utterly daft.
Last December, I gave a presentation very similar to the Enterprise + Cloud + Open one at Gartner Data Center. During the session, I asked some polling questions about how much the audience cared about "openness" and for which part of their cloud platforms. Taking a cue from Chris Wolf, here they are.
I have to assume that the audience might have been a little self selecting, since they chose to attend a session focused on open source cloud issues. There were probably some vendors or promotors of open source cloud stuff in the mix, as well. So take these with a grain of salt.
I asked about "openness" in general because I wanted to get a sense of how much the current hype around open had penetrated. The idea has taken hold amongst even the mainstream enterprise that's the bread and butter of analyst firms.
Then, more specifically, open source code and for what. Cloud management platforms and config tools being at the head are not surprising given that that's where the most options and noise are. Note that 20% didn't care.
Then a step deeper on cloud platforms. Again, pretty much in line with market noise, and arguably, momentum--OpenStack then CloudStack then Eucalyptus then OpenNebula. I was surprised that as many as 14 people had heard of and were considering OpenCloudWare, Nimbus, or OpenNode--all of which are fairly obscure.
And finally, a question about APIs because I wanted to get a sense of what people thought open APIs got them. The top response is the most reasonable. I don't think much of the portability argument, though. As I said in the presentation:
The API is not the implementation.
Just because you can write to it doesn't mean it will actually work
Last December, I gave a brief presentation at the first CloudStack Collaboration Conference on the open source cloud stuff in the enterprise.
Some salient points:
- Things that work trump things that don't
- Picking a winner is more important than picking the winner
- Speed and cost matter more than open or closed
- There are (and will be) private "clouds"
- There are (and will be) "hybrid" clouds
- Tech is easy, people and process are hard
- "Openness" can be measured, if you care to
- "Open" has been turned into a feature and marketing term
- Open doesn't save you from lock-in or vendors
- Open doesn't automagically solve portability and interoperability challenges
- Any, some, maybe all, parts of a given cloud can be open
Ethan and Greg over at PacketPushers asked me to come on the podcast to talk about what it's like to be an analyst and grill me on some topics about analyst life and perceptions of the industry. Listen at Show 137 – Gartner Is Not for Sale With @Aneel Lakhani.
With Gartner’s blessing, Aneel came on the show and answered some hard questions frankly – even bluntly. Sure, Aneel doesn’t speak for all of Gartner, but we ended up with a lot of useful insight from him.
- How does Aneel’s job work? What’s he do all day?
- Who is a Gartner “customer”?
- How does an analyst determine what products are interesting while avoiding bias?
- How technically competent are Gartner analysts?
- Most Gartner reports seems to represent the current state of affairs, but not look into the future. Why is that?
- Why is longevity at Gartner something to be proud of?
Some highlights from me:
Most of my time is inquiry with customers. Most of the customers are end users and buyers of technology. As an analyst, I am the product.
Woe to anyone who tries to turn us one way or another [vendor influence] because that goes very badly for them.If I am not factually incorrect and they [vendors] don't like what I've written about their product or marketing or behavior or whatever.. they should just do better.
In dealing with customers, I've found the reason Gartner commands the premium it does is because of the independence.
Like any large firm, Gartner has multiple divisions and business units.. serving different customers, etc. You have to know how to use analyst firms. If you want a deeply technical analyst, you should go get a deeply technical analyst.
It takes a particularly tough personality to survive the process of research and writing and getting through peer review and getting published and wading through all the information you get from vendors... it's way way way more work than I expected by easily and order of magnitude.
We'll see if I get into trouble for anything I said. :)
It’s been a little over a year since I joined Gartner and some things about startups, especially the cloud platform and management variety, stick out one anlayst-year in.
1. Many startups don't know what to do with their product.
They're pursuing the wrong market, promoting the wrong feature, using the wrong metaphor, blowing the product out of all proportion with itself, etc.
Say you have a great feature. why build a not-great product around that great feature to compete in a market full of other non-great products built around more or less interesting features of their own? Just be honest: sell your bloody feature to someone who wants it or to a bigger player who needs it. But I probably don't know what I'm talking about and this approach doesn't fit the path-to-exit models in effect.
2. The herd mentality is very much real.
In my tiny little specialization of cloud platforms and management software, there are 76 that I know of. And this number seems to grow monthly (found number 76 yesterday). Seriously, why do entrepreneurs keep entering this (very crowded) space and who are the financiers who keep throwing money at them? How many potential acquirers are there and how big could any of these folks get independently? My view is dim.
Not only are they creating a phalanx of not-likely-to-exit entities all marching towards the same cliff, but they're locking up useful talent that could be doing something that might have some kind of impact.
3. Money has to be put to work.
Lots of it. And funding startups is one way to put it to work. But I've come to the conclusion that some (more than admitted) of what goes on is a group of people in an inbred ecosystem sustaining a particular lifestyle off of someone else's cash--everyone collecting a bigger or smaller slice of that more or less free pie as befits their nominal function.
I'm familiar with this pattern. I've seen it before in the other realms of finance more dominant where I live in NYC.
It's been a little over a year since I joined Gartner and some things about cloud stick out one anlayst-year in.
1. Cloud consumption is fragmented.
I can find no single pattern or market or threshold function that tips any given organization over into using or building cloud services. If I take the aggregate of all the customers I've discussed this with--enterprises, state agencies, federal agencies, cloud service providers--it's all over the map.
There is no single cloud market. There are dozens. The interesting thing to see is whether vendors arise to serve all of them.
2. There's a small, growing huge-$$$-potential market for "real", "true", "webscale", whatever-you-want-to-call-it internal-private-not-hosted cloud.
Amazon has left that market to anyone who wants to take it. And that market is being addressed, though relatively quietly (marketing attempts notwithstanding).
3. A class of customer is leading, almost dragging, vendors into the future.
Some aren't even waiting. They're running into the future without their vendors and finding new ones there or making it up as they go along. They're spinning out companies, products, teams, open-source projects. This looks new to me, but maybe I just haven't been around long enough.
One will be Linux. One will be BSD. The rest don't matter.
San Francisco, Silicon Valley, DC, Baltimore, Chicago. I've hit most of these cities multiple times this year and one thing has started to stand out clearly: there's a talent constraint.
It stood out most at VMworld last month + Surge this month. Then I read this:
Are we reaching “peak people”?
It seems like in a lot of companies we are. There’s a shortage of talent out there, and if there’s a shortage of resources, you want to conserve those resources.
That's Jason Fried of 37signals. I've been talking to technology companies, enterprises, startups, state agencies, federal agencies, defense organizations and this is becoming a recurring refrain. "How do we move the organization forward? What kind of people do we need? Where do we get them?" That's not even what I cover or talk about, yet the question keeps coming up.
I don't think it's a fundamental technology skill supply problem, though. I think it's an allocation problem. Too much money is chasing too few problems spread out over too many organizations all employing the same kinds of people to do the same kinds of things. And that's how it'll stay--until things move on + the field is decimated.
Peak people.
P.S. I do think there's a supply problem for a particular skillset: systems people who understand applications + vice-versa. But that has most (in my opinion) to do with the fact that the kind of education that takes seems to have dropped off the general computer science curriculum.
There are physical limits to observation and action. Given equally matched adversaries with access to the same data and tools, both will hit absolute limits to how fast they can observe the environment or act on it.
But realistically, adversaries are not equally matched. They gather different amounts + kinds of data. They act slower or faster.
Observe - instrumentation, monitoring, data collection, etc.
Orient - analytics in all its forms, correlation, visualization, etc.
Decide - modeling, scenarios, heuristics, etc.
Act - provision, develop, deploy, fail, iterate, etc.
What does cloud speed up? And who has the advantage?
The proximate answer is obvious: operating in cloud models accelerates action. But the real benefit of being faster to act is upstream. It's so you can spend more time figuring out what's going on out there in the world and come up with the best--not the fastest--response and act on it at the optimal--not the fastest--time.
Because Connors and Evert needed less time to hit a return, they had more time to gather and process information. They saw, they prepared, and finally, only after they had processed as much information as possible, they hit. Their preconscious time management—what their brains did during the “prepare” period—was crucial to their success. Their talent enabled them to stretch out a split-second and pack in a sequence of interpretation and action that would take most of us much longer.
And also:
Sometimes there is a first-mover disadvantage. Sometimes the second mouse gets the cheese.
Which is what I was talking about in [
pacing]:
It's not at all clear...that it's uniformly better to be functioning at a faster pace than competitors at all things.
Being fast to provision + market.. is only worth anything if you can use that speed to deliver something better.
Act faster. Observe greater. Orient longer. Decide truer.
Deliver better.
In [change the game], I wrote:
With each iteration, you move further ahead in time.
What you iterate and how often, your pacing, is a big question. And not all paces are created equal.
What-- there's pace of: marketing, product, strategy, back office, ecosystem growth, ecosystem cannibalization.
How often-- there's pace relative to: competitors, customers, technology advance, commoditization, ecosystem.
It's not at all clear that all of these things should be the same or that it's uniformly better to be functioning at a faster pace than competitors at all things. For example, consider what happens when your strategy changes too quickly and your products change ever so slowly (this happens more often than you'd think).. constant changes of direction, executives, board members, etc., all the while without anything new being brought to market, any changes being made to the portfolio, any response being made to competition. Dysfunction in the extreme.
It's also not clear that you should be moving at the same speed (or with the same strategy) throughout a particular business, product, or ecosystem cycle.
Eventually, people will realise that activities evolve and you need to use different methods depending upon the state of evolution.
— swardley (@swardley) August 14, 2012