Blog Post

Structure 08 Recap: Yo Founders! There's Gold in Them Clouds!

GigaOM’s Structure 08 event offered a terrific opportunity to survey the changing landscape of computing infrastructure. But as with all technology shifts, innovation won’t just belong to the big established players like VMWare, Amazon, Google, Sun Microsystems, and NetSuite. With that in mind, Found|READ asked a panel of conference participants to share their thoughts via email on some of the more compelling business opportunities for startups in the cloud computing space. Specifically, we asked them:

F|R: Let’s say you’re about to start, or fund, a new business. Considering the changing landscape for computing architecture, what emerging or ignored problem in cloud computing would you target? What business or service would you launch to try to address it?

Arnie Berman, Chief Technology Strategist, Cowen and Co.:

Since Structure 08, I’ve been mulling over the following conundrum: How to give those that sign up for cloud computing services a sense of just how big (or small) their bills will be. In the wireless handset world, the advent of “bucket pricing” greatly helped the cause of mobile adoption. With “per-minute” pricing plans, charges were unpredictable – and occasionally very painful for active callers. “Bucket pricing” removed the fear of getting stuck with a ridiculously large bill.

In enterprise software, the advent of monthly subscription pricing from SaaS vendors likewise disrupted the license and maintenance pricing model of conventional software. But now companies like Amazon are threatening to disrupt the monthly pricing model with a “by-the-drink” model, where users only pay for the computing or storage capacity they use. While the economics of a pay-as-you-go approach are extremely compelling for most users, the approach actually reintroduces an element of uncertainty, because it’s very hard to predict what your computing consumption, and therefore your spending, is going to be. In wireless handset terms, it’s like going backwards from the safe harbor of “bucket pricing” to risky “per-minute” plans again.

Here’s a graphic:

Users like saving money. But they also like predictability. This suggests that what the world needs now is a monitoring and provisioning tool: a service (or a ware) that allows users to forecast their likely usage of computing infrastructure resources that they’ll purchase “by the drink.” Such a tool would also help predict their likely savings, as compared to the traditional on-premises software or SaaS models. Think of this tool as a tech innovation to help measure, and manage, the business model innovation that is cloud computing.

Luke Lonergan, co-founder and CTO of Greenplum, a maker of database management software:

The hype of cloud computing is huge with promise, and there are a lot of companies trying to explore what they can do with it. It is creating a market for services around putting applications into Amazon EC2 (leased computing infrastructure) and S3 (online storage) quickly and easily. If I were a VC in the market for a cloud company right now I’d look for something that makes the path from “application” to “cloud application” much quicker — basically I’d sell shovels and alcohol to the gold miners.

As far as the characteristics required: It would be off-the-shelf service for quick experimentation, something like “put your code or job stream here, dial in the number of units, push button to run, back comes a monitor that watches over execution, when done you get stats about efficiency, etc.” I think the current Amazon interface is more about the rental of assets and less about the execution of the experiments themselves.

Ken Elefant, General Partner, Opus Capital:

The most successful startups will identify enterprise computing needs that are not core to their customer’s business, but are still required to support it. This means targeting companies where a business buyer is eager to bypass IT. And founders should be going after cyclical businesses with predictable spikes. These are the kinds of potential customers that can benefit the most from overflow IT provisioning offered by a cloud computing startup. For example, search companies would want their large amounts of data to be in the cloud (pictures, videos, etc.) but only if they have low latency, low cost and high availability.

But don’t be too narrow in your pursuit of suitable verticals. Small companies still need to prove they have broad market applicability — and, specifically — enterprise customers who are willing to pay. The verticals need to be large enough to warrant a venture investment. An example might be financial services, where the provisioned service or function that a cloud computing startup might offer would be risk calculations, where lots of data, low latency and high availability is essential. Financial services is also a good example of a vertical of willing buyers. I believe technology will continue to trend in favor of talented, visionary entrepreneurs, especially those who can move fast.

5 Responses to “Structure 08 Recap: Yo Founders! There's Gold in Them Clouds!”

  1. Why do I get the feeling that it is inevitable even for core? It will not be as quick as those for non-core but experience and economics will probably drive it that way.


  2. Andrew

    Berman may have missed it, but a mature pricing and price management model exists in the network operator industry. A working and debugged proof of concept exists there that will mostly map to the cloud, so this is essentially a solved a problem.

    To give the simplest model that works very well in practice for companies big and small, there is a contracted price-service floor (“commit”) that will be billed regardless of service usage, usually at a discounted rate. There is a 95th percentile billing on all resource usage over the commit (“burst”), which both allows organic growth up to the capacity of the underlying resource (best effort) *and* allows transient peaks to not generate any additional billing activity (32 hours worth in a month), usually billed at a premium over the commit rate (typically around 50% plus or minus). Lastly, there is resource cap such that burst billing can never exceed a certain value specified by the customer, allowing them to put a hard limit on their cost even if radical growth does cause them to go way over their commit rate. In short, it lets the customer set the minimum and maximum bill, with a substantial discount for resources that are committed.

    Percentile based pay-as-you-go billing that has both a floor and a ceiling is simple enough that people can understand it, and powerful enough that it can handle the entire spectrum of risk averseness and absorb transients — giving the impression of better quality of service — without a billing event. In practice, you find companies that have no commit and pay for whatever it is they use at the premium burst rate (no billing risk aversion at all) and other companies that set the commit and cap to the same value such that there is no variability (extreme billing risk aversion). But you find that most companies choose a commit based on their estimates of resource usage with a comfortable cap maybe two or three times the commit value just in case they really need it.

    This is essentially the evolved billing model for modern network resource “clouds”, and it works well for everyone. I see no reason the same basic lessons in dynamic billing models could not be applied to cloud computing.


    Thank you Ken for mentioning the concept of “non-core” operations. This is the first time that I have heard anyone referring to non-core operations and many vendors forget this concept. Non-core areas are the ones that support an organization’s central activity (e.g., in a pharmaceutical company the core operation would be R&D whereas non-core would be purchasing, human resources, facilities management etc.). In my 18 years in the enterprise applications software business I have learned that these days a majority of organizations are willing to let someone else manage or deliver services to support non-core operations.