CloudBzz

One part of the debate on cloudonomics that often gets overlooked is the effect of over-provisioning. Many people look at the numbers and say they can run a server for less money than they can buy the same capacity in the cloud. And, assuming that you optimize the utilization of that server, that may be true for some of us. That that’s a very big and risky assumption.

People are optimists – well, at least most of us are. We naturally believe that the application we spend our valuable time creating and perfecting will be widely used. That holds true whether the application is internal- or external-facing.

In IT projects, such optimism can be very expensive because we feel the need to purchase many more servers than we typically need. On the other hand, and with the typical lead time of many weeks or even months to provision new servers and storage in a traditional IT shop, it’s important to not get caught with too little infrastructure. Nothing kills a new system’s acceptance more than poor performance or significant downtime due to overloaded servers. The result is that new systems typically get provisioned with far more infrastructure than they really need. When in doubt, it’s better to have too much than too little.

As proof of this it is typical for an enterprise to have server utilization rates below 15%. That means that, on average, 85% of the money companies spend with IBM, HP, Dell, EMC, NetApp, Cisco and other infrastructure providers is wasted. Most would peg ideal utilization rates at somewhere in the 70% range (performance degrades above a certain level), so that means that somewhere between $5 and $6 of every $10 we spend on hardware only enriches the vendors and adds no value to the enterprise.

Even with virtualization we tend to over-provision. It takes a lot of discipline, planning and expense to drive utilization above 50%, and like most things in life, it gets harder the closer we are to the top. And more expensive. The automation tools, processes, monitoring and management of an optimized environment require a substantial investment of money, people and time. And after all, are most companies even capable of sustaining that investment?

I haven’t even touched on the variability of demand. Very few systems have a stable demand curve. For business applications, there are peaks and valleys even during business hours (10-11 AM and 2-3 PM tend to be peaks while early, late and lunchtime are valleys). If you own your infrastructure, you’re paying for it even when you’re not using it. How many people are on your systems at 3:00 in the morning?

If a company looks at their actual utilization rate for infrastructure, is it still cheaper to run it in-house? Or, does the cloud look more attractive. Consider that cloud servers are on-demand, pay as you go. Same for storage.

If you build your shiny new application to scale out – that is, use a larger quantity of smaller commodity servers when demand is high – and you enable the auto-scaling features available in some clouds and cloud tools – your applications will always use what they need, and only what they need, at any time. For example, at peak you might need 20 front-end Web servers to handle the load of your application, but perhaps only one in the middle of the night. In this case a cloud infrastructure will be far less costly than in-house servers. See the demand chart below for a typical application accessed from only one geography.

So, back to the point about over-provisioning. If you buy for the peak plus some % to ensure availability, most of the time you’ll have too much infrastructure on hand. In the above chart, assume that we purchased 25 servers to cover the peak load. In that case, only 29% of the available server hours in a day are used: 174 hours out of 600 available hours (25 servers x 24 hours).

Now, if you take the simple math a step further, you can see that if your internal cost per hour is $1 (for simplicity), then the cloud cost would need to be $3.45 to approach equivalency ($1 / 0.29). A well-architected application that usea autoscaling in the cloud has the ability to run far cheaper than in a traditional environment.

Build your applications to scale out, and take advantage of autoscaling in a public cloud, and you’ll never have to over-provision again.

Follow me on twitter for more cloud conversations: http://twitter.com/cloudbzz

Notice: This article was originally posted at http://CloudBzz.com by John Treadway.

(c) CloudBzz / John Treadway

I have no doubt in my mind that Thomas Edison, were he alive today, would instantly spot the real value of cloud computing. Most people think it’s the economics. To one of history’s most prolific inventors, cloud computing would mean innovation.

You see, cloud isn’t just about how cheap you can make a VM, or how much less money Amazon costs than your internal infrastructure, even though it’s absolutely critical to the success of cloud computing that this is the case. Instead, the real value being created is how cloud computing dramatically lowers the barriers to experimentation and new models of delivering capability, thus increasing the chance that true innovation can occur.

Consider the following. Cloud computing is still way more prevelant in the U.S. than elsewhere in the world. There are relatively few non-U.S. clouds, even in Western Europe, though the pace of new cloud investments there appears to be increasing. All VCs now tell their Web-based portfolio companies to save their capital and use cloud computing to launch their service. Why? Because it reduces the amount of capital required to get to market. If the U.S. has a more vibrant cloud ecosystem, it has a positive impact on the level of start-up activity driving new innovations to market. Cloud computing, therefore, increases start-up activity.

Here’s another example. There’s a new pre-market company in the complex event processing (CEP) market called Cloud Event Processing (disclaimer – I am an advisor) using cloud instances, Map/Reduce for massively parallel computation, and a lot of other techniques that are becoming more prevelent in a cloud environment (e.g. no SQL databases). This is a new model that promises to dramatically change the face of the CEP market. Founder Colin Clark’s blog is incredibly open and forthcoming about why he feels that cloud-based CEP is a great and disruptive innovation. His post on Why CEP in the Cloud Makes Sense lays it out for all to see.

When Eli Lilly needed lots of processing power to drive drug discovery, they too turned to the cloud to generate a large map/reduce cluster in a matter of hours vs. the hundreds of days it would have taken through traditional provisioning. As pointed out in this Information Week article on Eli Lilly’s cloud success, the key value is the enabling effect that this cloud project has had on innovation (a word used 5 times in this article).

Have you ever had to go in front of your company’s capital committee to ask for money? This is one of the more painful things most companies put people through. Sometimes it takes months of analysis, justification, and back room lobbying to get a capex request approved. What do you think that does to innovation?? Imagine that tomorrow, instead of asking for $1m for your new speculative project’s infrastructure, you ask your boss for a few thousand dollars of expense budget to try out this new idea. If it takes off, you’re a hero. If it’s a dud, at least the company is not out $1m. That’s how cloud lowers the barriers to innovation and encourages experimentation.

While cost does matter, the cloud is about eliminating the opportunity cost, and the opportunity lost, by discouraging innovation. Next time someone argues with you over “cloudonomics,” change the discussion. To borrow from a famous campaign office sign from Bill Clinton’s 1992 presidential campaign – “It’s the Innovation, stupid!”

Follow me on twitter for more cloud conversations: http://twitter.com/cloudbzz

Notice: This article was originally posted at http://CloudBzz.com by John Treadway.

(c) CloudBzz / John Treadway

Setting aside the shameless cloud-washing that’s going on from some vendors, there are a lot of cloud service providers (CSPs – providers of cloud) today.  Many of those listed in Sys-Con’s Top 150 report are CSPs, while others are providing extensions, tools or services for clouds.  Everybody’s a cloud provider these days – and as Larry Ellison recently said “All boats are cloud boats.”

Every telco, every hoster, every data center outsourcer, most systems providers and many, many startups are becoming CSPs.  After all, there have been thousands of hosting providers over the past several years competing for your business.  A few were huge, several were large, and most were small but often profitable.  I’m convinced this time it might be different — the cloud provider market will be increasingly consolidated with fewer opportunities for new entrants or profit from the tier 2 or 3 CSPs.  The APIs, data center economics and proprietary platforms will make cloud a much more consolidated market.

The chart below depicts the scenario that I see taking place over the next few years, where the number of new entrants and the hyper-efficiencies gained by the biggest (Amazon, Google, Microsoft) result in razor thin margins that can’t be met by most of the players going forward.  The pricing curve will drive adoption, solidifying the economies of scale by these mega CSPs.

One of the ways that the biggest guys will get scale is through completely proprietary cloud stacks that have a marginal cost of $0 to deploy new customers.  Contrast that with the vendor stacks from VMware, 3tera, Enomaly, and VMOps.  If you have to pay money to others based on the number of servers you have, the number of VMs or other components, it puts you at a disadvantage.  You can still win, but your profits will be lower and it will be harder to find the capital to invest to stay competitive.

There are the open source alternatives such as Nebula and OpenNebula, and the VMware-free version of Eucalyptus.  Some will go this route, innovate around the core, and survive.  Others will rely on the vendors or community to keep them competitive and some may not be happy with the results.

This goes back to the excellent recent post by James Urquhart on differentiation.  There are many ways that CSPs can differentiate their offerings, but price is probably not one of them (unless you’re in the mega category).  That said, your premium needs to be reasonable – selling cloud VMs at 5x the price of Amazon is not sustainable in the long run.  Relationships, custom services, security, applications, and other content that’s harder to commoditize needs to be part of your strategy.

I predict that there will be many new CSPs over the next 18 months, but even before the new entrants stop coming many companies will exit the cloud business.  Some exits will be via consolidation/merger, but many will just pull out of unprofitable businesses in the face of blistering competition.  My take is that the great shakeout will be in full force in the 2012 time frame, with a bottom reached over the following 5-10 years.

So, will you be a survivor, or will you be cloudkill?

Any new technology market has its own lifecycle and rhythm.  From mainframes, through smartphones, there’s the early years, the rapid growth, some slowing down and inevitably a decline.  Some technologies never go away completely (e.g. mainframes), while others never really get a foothold (insert your own example here).

Open source was a software movement that began as an idea and now dominates how many new software offerings are marketed and sold. Open source is not a technology, but a business and legal framework within which technology is propogated.  Still, the biggest companies in software are largely closed source – Oracle, SAP, etc.  Nearly all specialty vertical apps (e.g. trading systems) are closed source.  Whereas most new development technologies including databases and tools are open source.  Given that open source is more a legal construct which bleeds into sales and marketing, it’s highly likely that there will be both open and closed source models co-existing for any foreseeable future.  Further, open source shrinks the size of the industry from a revenue perspective by default  (though parodoxically, software spending is up this year even in this economy).

What about cloud computing?  Will there still be the need for the cloud modifier in the future?  In the past most infrastructure was sold directly to the users under a capex spending model – this includes servers, databases, operating systems, etc.  Of total infrastructure spending in 20 years, how much will still be for on-premise capex, and how much for cloud opex?  Will ecconomies of scale drive infrastructure in the cloud to a point where the infrastructure market will shrink in both real and nominal terms?

Will the purveyors of servers, networking and core infrastructure software sell 90% of their wares to cloud companies?  Will what we currently call  ”cloud computing” be  just plain “computing” in the future?  Time will tell, and it will be a long time before the cloud distinction becomes superflous, but it will be interesting to watch.

There has been a lot of good discussion lately about the semantics of private vs. public clouds.  The general issue revolves around the issue of elasticity.  It goes something like this: “If you have to buy your own servers and deploy them in your data center, that’s not very elastic and therefore cannot be cloud.”  Whether or not you buy into the distinction, pivate clouds (if you want to call them that) do suffer from inelasticity.  Werner Vogels in his VPC blog post debunks the private cloud as not real:

“Private Cloud is not the Cloud

These CIOs know that what is sometimes dubbed “private cloud” does not meet their goal as it does not give them the benefits of the cloud: true elasticity and capex elimination. Virtualization and increased automation may give them some improvements in utilization, but they would still be holding the capital, and the operational cost would still be significantly higher.”

What if we were to look at the private cloud concept as an interoperability play?  If someone implements a cloud-like automation, provisioning and management infrastructure in their data center to gain many of the internal business process benefits of cloud computing (perhaps without the financial benefits of opex vs. capex and elastic “up/down scaling”), it still can be a very valuable component of a cloud computing strategy.    It’s not “the Cloud” as Werner points out.  It’s just part of the cloud.

To realize this benefit requires a certain degree of interoperability and integration between my “fixed asset cloud” and the public “variable expense cloud” such that I can use and manage them as a single elastic cloud (this is what is meant by “hybrid cloud”).  Remember that enterprises will always need some non-zero, non-trivial level of computing resources to run their business.  It is possible that these assets can be acquired and operated over a 3-5 year window at a lower TCO than public cloud equivalents (in terms of compute and storage resource).

Managing these fixed + variable hybrid cloud environments in an interoperable way requires tools such as cloud brokers (RightScale, CloudKick, CloudSwitch, etc.).  It also requires your internal cloud management layer to be compatible with these tools.  Enterprise outsourcers like Terremark, Unisys and others may also provide uniform environments for their clients to operate in this hybrid world. In hybrid you get the benefits of full elasticity since your view of the data center includes the public cloud providers you have enabled. You may choose to stop all new capex going forward while leveraging the value of prior capex (sunk costs) you’ve already made.  In this context, private cloud is very much part of your cloud computing strategy.  A purely walled off private cloud with no public cloud interoperability is really not a cloud computing strategy – on this point I agree with Vogels.

Co-Generation:  Selling Your Private Cloud By the Drink

Now, assuming you’ve built a really great data center capability, implemented a full hybrid cloud environment with interoperability and great security, what’s to stop you from turning around and selling off any excess capacity to the public cloud?  Think about it – if you can provide a fully cloud-compatible environment on great hardware that’s superbly managed, virtualized, and secured, why can’t you rent out any unused capacity you have at any given time?  Just like electricity co-generation, when I need more resources I draw from the cloud, but when I have extra resources I can sell it to someone else who has the need.

You might say that if your cloud environment is truly elastic, you’ll never have excess capacity.  Sorry, but things are never that easy.  Today large enterprises typically have very poor asset utilization, but for financial and other reasons dumping this capacity on eBay does not always make sense.  So, what about subletting your computing capacity to the cloud?

Then, if I take all of the big corporate data centers in the world and weave them into this open co-generation market, then instead of buying instances from Amazon, Citigroup can buy them from GE or Exxon.  What if you need a configuration that is common in the enterprise, but not in the cloud (e.g. true enterprise class analytic servers with 100TB capacity), perhaps you can rent one for a few days.  It may be more cost-effective than running the same job on 300 Ec2 instances over the same timeframe.

There may be many reasons why the co-generation cloud computing market may never evolve, but those reasons are not technical. Doing this is not rocket science.