A MetaCloud Journey

A MetaCloud Journey


Carnival_CCCC9214-M

Congratulations to the team at MetaCloud. The acquisition by Cisco was announced today. I am obviously very proud to have been involved with the company. It’s something special to have seen the team make it happen since the very first day. It was an incredible journey with the team – as anyone would expect. There is something to be learned from failure, but success at times comes with even more lessons to be learned. And successes certainly are more fun to reflect on and write about for a post.

As a venture investor, I try to constantly learn, improve and do better as a partner. Ultimately, my job is to generate returns for our investors – the endowments, pensions and others that believe in our collective ability at Storm to invest in early stage enterprise companies. My ultimate goal is to make the companies I invest in successful. If I help make our companies successful, good things should and will happen with time. So from that perspective, understanding the how and the what that made MetaCloud a success as a company is an interesting story. Looking back many of the elements that made MetaCloud so successful are universal – like the quality of the team. Sure there are exceptions, but all of these elements make up what every successful company does (it’s certainly my experience) – but each one in a slightly different way. That is what is interesting.

I also want to give a nod to Chris Hipp. I was introduced to one of the founders of MetaCloud, Steve Curry, by our mutual friend Chris. Chris passed away in 2009 unexpectedly – Ashlee Vance (who was at The NYT at the time now Businessweek) did a nice obituary. I wish Chris was still around to see all that was created. It would have made him very happy. Thank you Chris.

 

 

So what attributes have contributed to make MetaCloud a success?

 

  1. Not being wed to the original idea

Sean Lynch and Steve Curry had the original idea of acting like a sort of cloud broker of compute resource. Sean had experienced first hand the excess compute capacity that often sits idle behind large corporate firewalls. If there was a way to enable others to leverage that capacity – and enable a large enterprise with capacity to sell that capacity back to the “grid”, amazing things could happen. Steve Curry and I met many times at the Dutch Goose in Menlo Park to brainstorm about the idea before funding – even pulling in an occasional customer into the discussion. We spent a lot of time going over the idea, talking with potential customers but it quickly became clear to us that the idea of a broker model was just too early for the market. Mostly because if you think about it, the prerequisite for being able to enable this compute brokering is for enterprises to already have effectively what we would call today a private cloud. Those private clouds did not exist then and we are just starting to see them get deployed today. The broker model has merit and likely will exist when the market is ready. You heard it hear first

 

 

  1. Build what customers want

The team was very smart to recognize the broker model was flawed early and adjust the plan – otherwise we would have failed.  I am not sure I would call what happened next a pivot so much as carefully listening to customers. Customers wanted a private cloud. The team built what customers wanted – it sounds obvious but building the broker concept technically was interesting and at the time seemed more disruptive than just standing up and managing private clouds for customers. But customers wanted private clouds and needed help designing and operating them. The team decided to deliver OpenStack as a service. Deliver a fully functional OpenStack cloud behind a corporate firewall where the cloud would be fully managed so that there would be no need to have any internal OpenStack expertise. One thing we learned early – and this was critical – was that we needed to make a promise to the customer, if at any time they want to take over managing the cloud themselves, they could do so without cost. MetaCloud would give them a license to everything. Everything. No cost. Zero. This put the proverbial monkey on our back to deliver a solution that never made that choice relevant. It focused the development efforts on managing scale, deployment and operations as well as contributing code back to the OpenStack community. MetaCloud had little incentive to deliver anything proprietary since customers could in theory take it at any time. Poof.  We struggled to explain what this meant to the market and to customers. Is it a consulting business? – no. Is it a distribution I can buy support for?- no. What is it?  The best answer:  it’s a solution.

 

 

  1. Delivering a solution not a product

OpenStack as a service. We were able to get a lot of traction in an early market by delivering the right solution versus the right product. Customers ultimately want to get their problems solved so they can focus on their own business. Sometimes products are good enough to deliver against that value proposition or customers may be well equipped to buy just products (think copy machine). The MetaCloud team realized early on that many customers needed a solution around OpenStack. Customers either didn’t have the resources to execute an implementation themselves or didn’t view placing internal resources against a problem as the best use of their own teams. MetaCloud enabled those teams to do even more – focus on the harder problems and scale way beyond what they were able to do on their own. MetaCloud in many ways became part of their customer’s team and we treated the customers as if they were part of our team. It paid off.

 

 

  1. Execute. Execute. Execute

The team could execute. If they got the opportunity to sit down with a technical leader, it usually led to a serious sales discussion. I cannot think of a single instance where MetaCloud was the contributor to the issue when standing up a cloud with a customer. We struggled sometimes to get hardware delivered on time or projects got pushed out based on a customer’s new timeline but the team executed. Sean Lynch hired an amazing team of people to help him execute. Customers asked us to get OpenStack running with their NetApp filers? – no problem. Want it to run with EMC arrays? – we can do that. And this was long before EMC, HP and others committed fully to OpenStack. We did a little custom work for sure but we could do it because this team could execute with confidence.

 

 

  1. Team had technical credibility with customers

MetaCloud had a tough problem to solve in most sales situations. Infrastructure is not like a sales tool that someone can just try out, roll it out to the team and if it works great, if not it was just some wasted spends. For MetaCloud’s customers, they were making a huge bet not only on OpenStack but also on MetaCloud’s ability to deliver. The team had some technical credibility with some of the early customers by virtue of having worked with some of those team members side by side in other companies but existing relationships doesn’t scale. Technical credibility was critical to success (and I probably underestimated it at the beginning) simply because it was such a major infrastructure decision. I am biased, but I would guess there is not a better technical team on the planet.

 

 

  1. Financial prudence and sequencing

When we launched OpenStack as a service, we didn’t have customers banging down the door. The team wasn’t well known outside of the companies that they had worked at before and OpenStack was viewed as an immature project with little hope of success. We had to figure out what OpenStack as a service really meant for customers – how much were they willing to pay? what was the right way to charge? – per core, cpu, server or some other metric? OpenStack was early and as a startup we were not going to move the project forward by ourselves – we knew we couldn’t move much faster than the community. As a result, the company was very careful with our spend until first we really understood what it was we were selling. Then with the first sales hire, Bert, we were very careful to figure out how we were going to sell repeatedly before investing more in terms of sales and not until recently have we really started to ramp up the marketing team. The team was also thoughtful about raising equity.They operated on a shoestring for two years from the start when we wrote the seed check in summer 2011 to the A round which was done in June 2013 with Canaan and Maha Ibrahim. She is a great partner at a great firm. The team then raised a Series B financing last spring and it made sense since we knew what to scale and how to scale.

 

 

I am grateful to have worked with such an outstanding team and wish them well in their next chapter of success with Cisco.

 

 

3 Comments

Add yours
  1. 2
    Jamie Costello

    Congrats on the exit. However, while it was successful from the point of view of the investors, I think it is too early to call the product or business successful. That will come when the product makes money for the company. There are a number of large numbers that have not been able to get going in the cloud and will buy startups to try to get something going. But real success will be when the product does well in the market and returns back at least as much as Cisco’s pruchase price. I would love to read a post about success at that point, too early now imo.

    • 3
      ryanfloyd

      Well I agree from a fundamental perspective. Cisco has bought one of the very best OpenStack teams in the world. What is that worth in your calculus? I have little doubt that Cisco will be returned its purchase price 2-3x over but you are right – only time will tell. The last company that I was involved with was Sandforce. We solve to LSI for $400m. The business will do over $200m in revenue this year and that is something we are proud of – fundamentally.

+ Leave a Comment