Wide Awake Developers

« Outrunning Your Headlights | Main | Sun Joining the Cloud Crowd »

A Cloud For Everyone

The trajectory of many high-tech products looks like this:

  1. Very expensive. Only a few exist in the world. They are heavily time-shared, and usually oversubscribed.
  2. Within the reach of institutions and corporations, but not individuals. The organization wants to maximize utilization.
  3. Corporations own many, as productivity enhancers, some wealthy or forward-looking individuals own one. Families time share theirs.
  4. Virtually everyone has one. To lack one is to fall behind. No longer a competitive advantage, the lack of the technology puts one at a disadvantage.
  5. Invisibility. Most people have or use several, but are not aware of it.

Depending on your age, you might have been thinking "cell phones", "computers", or even "televisions".  I don't think I have any blog readers old enough to have been thinking "telephones", "telegraphs", or "electric motors", but they all went through the same stages, too.

I feel very comfortable putting "cloud computing" in that list, too. Cloud computing is at stage 1. It's expensive enough that there are a few in the world: Amazon AWS, Mosso, BungeeConnect, even Force.com. They're shared, multitenant, and soon to be oversubscribed.

One day, I suspect that we'll each have our own computing cloud attending us, formed out of the many computing devices that surround us every day, but I'm getting ahead of myself.

Before that, we'll see enterprises, first large then medium and small, building their own computing clouds.

"Wait a minute," you object. "That misses the whole point of cloud computing. The entire purpose is to not own the infrastructure."

That's true, today. It was also true, at one time, that farmers did not want to own their own steam engines. So, they outsourced the job. Farmers would own machines like threshers that had everything except the troublesome boiler and engine. Those required technical expertise to run, so the farmers left that job up to folks who would bring their steam engine around, hook it up to the thresher, and charge the farmer for the length of time he needed it. As steam engines got cheaper and safer, they eventually got built right into the thresher.

This next part may sound like FUD. It isn't. I like cloud computing. I like virtualization. In fact, I think it's about to revolutionize our industry.

I like it so much that I think every company should have one.

Why should a company build its own cloud, instead of going to one of the providers? Several reasons, some positive, some not so much.

On the positive side, an IT manager running a cloud can finally do real chargebacks to the business units that drive demand. Some do today, but on a larger-grained level... whole servers. With a private cloud, the IT manager could charge by the compute-hour, or by the megabit of bandwidth. He could charge for storage by the gigabyte, and with tiered rates for different avaialbility/continuity guarantees. Even better, he could allow the business units to do the kind of self-service that I can do today with a credit card and The Planet. (OK, The Planet isn't a cloud provider, but I bet they're thinking about it.  Plus, I like them.)

I actually think this kind of self-service and fine-grained chargeback could help curb the out-of-control growth in IT spending, but that's a different post.

This would seriously raise the level of discourse. Instead of fighting about server classes, rack space, power consumption, and rampant storage sprawl, IT could talk to the business about levels of service. Does this app need 24x7 performance management with automatic resource allocation to maintain a 2 second response time? Great, we can do that! This other one doesn't need to be fast, but it had better work every single time a transaction goes through? We can do that, too! This application needs user experience monitoring, that database only needs non-redundant storage, because it can be recreated from other sources... it's a better conversation to have than, "No, our corporate standard is WebSphere running on RedHat Enterprise Linux 4, with Dell PowerEdge servers.  You can have any server you want, as long as it's a Dell PowerEdge."

I also think that the gloss will come off of the cloud computing providers. (I know, most people still haven't heard of them yet, but the gloss will inevitably come off.)

Accidents happen. Networks still break, today, and they will in the future too. Power failures happen. How would you defend yourself in a shareholders' lawsuit after millions in losses thanks to a service provider failure? (Actually, that suggests there may be an insurance market developing here. Any time you've got quantifiable risk and someone willing to pay to defray that risk, sure as hell, you'll find insurance companies.)

Service providers get oversubscribed. What happens when your application is slow, and remains slow for months? Having an SLA only means you get some money back, it doesn't mean your problem will get fixed. It's a dirty secret that some service providers are quite happy paying out credits, if they can avoid bigger costs. What's your recourse? Transition costs. It costs a lot.

Latency matters. It might matter more today than ever before, since most internal applications have gone to web interfaces. Keeping your endpoints on your own network at least lets you control your own latency. 

Then there's security. Many of my clients are dealing with PCI audits and compliance. I have no idea what they'd say if I suggested moving their data into the cloud. I'm pretty certain I wouldn't still be in the room to hear what they said. I'd probably be standing outside in the rain, trying to catch a cab back to the airport.

Like I said, I'm not trying to FUD cloud computing. I think that it's so good that every company should have one.

There's one more reason I think it makes sense to build internal clouds. I'll talk about that in my next post. 

TrackBack

Listed below are links to weblogs that reference A Cloud For Everyone:

» Sun Joining the Cloud Crowd from Wide Awake Developers
As I was writing my last post, I somehow missed the news that Sun is building their own cloud platform, called Project Caroline.There's a PDF about it. It appears to be a presentation for JavaOne.  It may be locked down... [Read More]

» The Granularity Problem from Wide Awake Developers
I spend most of my time dealing with large sites. They're always hungry for more horsepower, especially if they can serve more visitors with the same power draw. Power goes up much faster with more chassis than with more CPU... [Read More]

Comments

Micheal,

Interesting post. You've spotted a number of issues with shared cloud computing that most folks have considered yet. On the flip side, many users applications aren't large or sophisticated enough to ever encounter SLA, scaling, or latency issues. Those that do, though, I completely agree will want their own clouds.

However, I would like to point out that while building a cloud from scratch yourself is expensive and requires a great deal of skill, there's no need. 3tera's users already enjoy their own clouds today, whether hosted with our partners or built in their own data centers.

barmijo,

I wondered if I'd see someone from 3Tera on this post...

Yes, I am aware of your product, and I think it addresses the technical foundation very well. In fact, I posted a complimentary piece after I got "hands on" with AppLogic at QCon last fall.

What I'm describing is only a small stretch from what I see in GridOS today. Specifically, if a company deploys their own cloud, the IT department should explicitly aim to enable self-service by their service consumers, the business units.

Your shared hosting model comes very close. The rest is just accounting. Think of the IT department of the future as equivalent to one of your hosting partners, but serving only internal customers. The platform needs to integrate with identity management for authorization and with the general ledger for chargebacks. (I.e., treat the GL as an internal billing system instead of using credit cards or purchase orders.)

Cheers,
-Mike Nygard

Michael,

Here at Arjuna, we buy into the benefits of ‘internal’ clouds. One problem that we’re focusing on, is that everyone wants to take service from the cloud but very few want to put anything in. It’s a huge risk to build out a utility (whether internal or external) in the hope that consumers will sign up and get you a return on that investment. There’s also a significant disruption as consumers move from using specific services supplied by dedicated infrastructure to generic services supplied by the cloud. Like you, we believe that clouds will be built in the small (internal clouds), and will then grow through a process of amalgamation, driven by economies of scale. Internal clouds can concentrate on the enterprise’s specific services and on their immediate concerns e.g. security, data access, latency etc. Once those clouds are in place serving the individual department or enterprise each internal cloud can accept and provide service to other clouds, between departments, within the supply chain, or, ultimately from 3rd party utility providers. Over time one could imagine dedicated infrastructure atrophying (in the same way that, as Nicholas Carr describes, internal electricity generating facilities did) with service increasingly sourced from the cloud. The smaller clouds would also atrophy as the specific solutions they provide for the department or enterprise become increasingly standardised and are adopted by the larger utility clouds.

We’re working on a product (Agility) that delivers the internal cloud. Agility will allow the departmental IT manager to dynamically assign parts of their infrastructure to the cloud under the control of their own policy. This means that they can restrain how, and by whom the infrastructure may be utilised, and under what conditions it may be seized back from the cloud. That way the IT manager can improve resource utilization and monitor usage for chargeback, without surrendering control. We think this approach will allow the internal cloud to grow organically as trust is established and more and more resource is assigned to the cloud.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)