fantasy vc - metacloud

Kicking off a series about bets I would've placed if I had the money. This is something I very much wanted to do--very much could not do--when I was at Gartner.

I don't know the numbers on "real" (read: revenue generating) OpenStack adoption, growth, etc. . 

I do know there's real traction. 

Suspicion: it's with very very few vendors. Money is being made but success is concentrated.

There are only two startups in the space I would bet on. One, I have a conflict of interest regarding. The other is Metacloud. Both aren't really OpenStack companies. OpenStack is just a vehicle for the thing they actually do.. In Metacloud's case, what they do is remote ops (as a service!)

Put these things together:

• There is a market for private cloud (whatever that is)
• There is a market for AWSish public cloud
• There is a market for AWSish private cloud (Eucalyptus are still in business, aren't they?)
• There is an existing use case for AWSish private cloud in most enterprises (web, mobile, dev)
• There is a fundamental our-bottom-line-at-stake use case for AWSish private cloud in some subset of enterprises (a few hundred?) today
• There is a general lack of operational skill for AWSish private cloud
• One of the core things public cloud provides is a managed service
• There is a market for on-prem remote-managed AWS (the three letter agency thing is a public example)
• The Metacloud guys are ops guys who understand enterprise, scale, web, mobile, open source, AWSish cloud
• There just aren't a lot of hats (big or small) in this particular ring right now 

That's not to say that they're guaranteed success. Or won't get crushed by an incumbent or other party. Or even scooped up before they become too successful. Just that I would've placed that bet.

Disclosure: They're in my former coverage area. But I believe with some certainty that I'd come to the same conclusion without that background. I have no financial interest in Metacloud. I really like them. Would have a beer with that crew any day. 

provided vs exposed

If you're offering infrastructure as a service, you have to have infrastructure to offer and it has to be exposed.

But if you're offering something else, then:

The infrastructure doesn't need to be exposed, THUS you don't need to have it.

Examples:

• You offer VMs, so you need to expose VMs, a management console for VMs, and (hopefully) APIs to connect to and operate them
• You offer a runtime, so you may or may not have VMs--but who cares since what you need to expose is the runtime, a management console for that runtime, and (hopefully) APIs to connect to and operate it
• You offer an application, so you may or may not have VMs or a particular runtime--but who cares since what you need to expose is the application, a management console for that application, and (hopefully) APIs to connect to and operate it

It gets a little more complicated when someone wants to build something else on top of what you offer. Then they probably want and/or need more exposure to, and more control knobs for, the underlying stuff.

Basically, this is what makes IaaS (specifically VMaaS) different in kind from anything else. 

What you provide guides what you expose dictates how you can build.

What you've built limits what you can expose dictates what you can provide.

generating signal

Courtesy @epc, I went to the July New York Tech Meetup. For the most part, consumer/social/mobile/web/fashion startups aren't my bag. But here's something interesting..

@NYTM: Deliver the right message to the right person. @Knodes http://t.co/AWLrqdjOiO #NYTM 

The same technology used to sell our eyeballs to advertisers is flipped into a tool for us to reach deep into our own networks with the backing of our personal social credit. This flips the noise generating system into a signal generating system.

Instead of us filtering out all the noise to find the signal, the signal filters out everyone to whom it is noise. The signal finds you.

the value of feature velocity

We don't put a value on feature velocity. Not our own, but the public cloud's.

Maybe we should. Being on a public cloud like AWS exposes us to new capabilities faster than most internal IT departments can begin to provide. We may not need any given capability, or even want it. But here's the thing: you will never know what you could do with it if you're not exposed to it. 

There's some inherent value to that. To being exposed. 

And there's an opportunity cost to not being exposed. 

Are you putting a value on that? 

the misogyny in technology

Maybe it's cause I was raised by a single mother.

Maybe it's cause I've worked under managers, directors, vice presidents, general managers, and senior vice presidents who happen to be women. Maybe it's cause I've worked with engineers and technologists with advanced degrees who were experts in their fields who happen to be women. Maybe it's cause I know CEOs, CMOs, COOs, and CIOs who happen to be women.

Maybe it's cause I'm secure in my person and don't find anyone else's success as a threat to my own. Maybe it's cause I don't think life is a zero sum game.

But…

• Walking into a room and telling the first woman you see to get you a cup of coffee IS NOT OK.
• Drunkenly texting "your room or mine" to the woman CEO of a successful company whose business you can impact IS NOT OK.
• Rewriting the history of an organization to cut out the women leaders and founders in order to aggrandize the men IS NOT OK.
• Attempting to put down a woman who has obviously kicked your ass in a technological argument by calling her ___ or ___ IS NOT OK.

I come from a culture that is historically not good to women and I don't seem to have a problem with this.

Mr. Senior _____, Mr. VC, Mr. Distinguished _____, Mr. CxO--what's your excuse?

conservation of lock in

Every hardware, software, runtime, programming language, database, management tool, cloud, etc ad nauseam decision involves lock in. The idea that you can do away with lock in is utterly bogus. All we do is shove it around from one layer to another. 

Every decision comes with a switching cost (even when that switch is an undo). The extent of that cost is your lock in. And ultimately you cannot remove lock in. The total lock in you are under is the cumulative cost of switching every last thing. Or even simpler, changing. This is also the beginning of technical debt. This is also why ultimately things end up getting thrown out and we start from scratch. This is also one reason why composing systems and operations of smaller units of deployment/consumption/operation/failure is useful.

You cannot eliminate lock in. But maybe we can minimize the scope of any given piece of lock in (and change costs).

And any vendor who sells freedom from lock in which does not also include freedom from that vendor ("go ahead, we'll make it easy for you to replace us") is just playing on your failure to accept the simple reality that there is always lock in.

Lock in is conserved. Conservation of lock in.

the three cloud questions you have to answer

The bit about 3 lines in "what we don't know about private cloud" seems to be making sense to everyone I discuss it with (end users, vendors, investors), so I've reformulated it as a set of questions.

Taking an application portfolio perspective.. looking across the entire set of apps you run, you have three decisions to make:

1. Of that set, what do you NOT want to develop or run, period?
2. Of the remaining set, what do you NOT want to develop or run on your own infrastructure?
3. Of the remaining set, what do you NOT want to manually provision and have manually requested?

The consensus on these questions, if one ever emerges, will produce the actual (vs pick-your-pundit's projected) terraforming of the tech landscape.

what we don't know about private cloud

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.

open source cloud platforms grain of salt

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

enterprise + cloud + open

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