Head in the clouds

Michael Nygard has his head in the computing clouds, suggesting that not only is cloud computing in our future, but that there’ll be many of them. He’s right.

Everyone who runs a large data center is today faced with the same set of interconnected environmental problems; space, power, and heating/cooling. And these are environmental not just in the sense of tree-hugging but also in a straightforward practical sense: there is no more space, there is no more power, there is too much heat and not enough cooling. These problems were the domain of junior people a few years ago, worrying about where, physically, to locate all the new Windows boxes. Then it was middle managers trying to sort out power and HVAC issues: “If we deploy a new phone system in our building we won’t have enough power to do any upgrades in the data center,” that sort of thing. Now environmental issues are front-and-center for senior IT management and if you’re a “red-shift” kind of company, for senior corporate leadership too.

You can cloak it if you want to in green terms but businesses are faced with real operational issues that they need to address regardless of their perspective on global warming or riverine dolphins.

Alongside these environmental issues, data centers are also facing a crisis of manageability. A large enterprise data center is a staggeringly complex thing, too complicated. Also, if the truth be told, most of them are not that well run; would you expect, for example, that an auto parts distributor would have great technology management skills? No, of course not, and the fact is that they probably wouldn’t want to spend the money to acquire that talent and technology even in they could; their differentiation, the competitive advantage of their business, lies elsewhere. So they have a complicated, and sub-optimized, technology infrastructure.

The answer to all of these problems — Monday edition — supposedly lies in virtualization. Novell gets brought into these conversations because inevitably data center managers have a roadmap that looks something like this:

1. Simplify and Standardize

The operations guys, who run the apps once they’re written, are finally getting the teeth to enforce common standards on the development side of the house. This is a political process as much as anything else, but it’s as hard as any technical issue, something that nerds are woefully bad at understanding.

What are the preferred options for operating systems? For databases? For Java platforms? For development languages? And so forth. The answers don’t matter so much as the fact that there are only one or two of them. Some shops use the model of Legacy/Supported/Preferred/Emerging, where Legacy is bad, Supported is headed to Legacy, and Emerging is headed to Preferred. So, for example you might say that Oracle and SQLServer are your preferred databases, while DB2 is supported (reluctantly) for a particular reason. Sybase, let’s say, is around still in the environment but it’s Legacy and thus unsupported: if you have problems with it, don’t come crying to Ops about it. Emerging would be MySQL and that sound you heard after the Sun acquisition was ten thousand infrastructure architects moving MySQL from the Emerging category to Preferred.

One of the key elements here is Linux. Data centers in the future are going to run Windows, in some form or another, and Linux. That’s it. Now, that’s going to take a long time, since we know that IT is conservative, and there will still be Solaris and VMS and so on in the data center of the future, but that’s not where the action is. It’s going to be Linux and Windows. But, as we’ll see, that may not make so much of a difference.

2. Consolidate and Virtualize

So once we’ve started to enforce rules on the heterogeneous chaos, we can begin to take advantage of that consistency. We’ve probably already got a SAN and perhaps an Oracle RAC environment (in addition to all those single instance databases), so the idea of virtualized pools of IT resources is not a new idea to our customers out in the business units. And it isn’t a new idea for sure for the mainframe guys, who are laughing their asses off, inside of their oxygen tents.

So now we start to consolidate servers through virtualization, inevitably beginning with the development and testing environments. You give the developers standard virtual machines to work on and then, magically, they’re going to migrate — after proper testing, mind you, we do have our dignity — into virtual production environments. At the same time, there is more likely than not a server consolidation project going on to move single servers into virtualized environments. Ten:1 or even 20:1 is common in production environments.

All that virtualization creates management headaches of its own; for infrastructure software vendors like Novell, the game is going to play out not at the level of the hypervisor — which is going to commodity status before reaching general availability — but at the level of the management tools. That’s what people will pay for.

Virtualization is not as easy as I’m making it out here; properly configuring hardware, for instance, is not yet straightforward and the performance hits on mis-configured hardware can be significant. Memory is king in the hardware for virtualization, and blades don’t seem to cut it because of their I/O and other physical constraints, so lots of shops looking at virtualization are re-thinking their blade investments that are just a few years old.

Even if you get that and the management of virtualization under control, you still have the basic architectural design of your virtualized data center to consider: is every application going to run its own virtualized stack? What about single apps on single physical servers? Are you still going to incur the hypervisor tax in that situation? Is the management & DR benefit worth it? And I’m ignoring the desktop side of things here but that is an other, huge, mess that you could virtualize.

3. Cloudify (? Cloudize? Cloudit?)

Let’s say that you’ve done all this and you’ve got a few standard platforms (Windows, database, Java, web server/LAMP, raw C++ for super-special stuff) that you’re supporting in your Preferred environment, plus some Supported and Legacy stuff that’s still lying around. For the most part, you’ve broken the tight linkage between the physical resources — the disks and the CPUs — and the abstract/digital ones, which means that you can now start to think about moving them around. Hedge funds might not want to put their algorithmic trading systems too far from Wall Street, but their HR systems don’t really need expensive Manhattan real estate, do they?

This also points to the fact that these infrastructure services are utility-like, as Nicholas Carr described in his readable The Big Switch. Java developers really should not care what operating system, or what hardware platform, or what storage system is running in the background. (They also shouldn’t care whether it’s WebLogic or WebSphere or JBoss but the fact that they do is another story.) You don’t care what operating system Google, or Bank of America’s website, or this blog, is using, do you?

Anecdotally, I’ve heard about corporate developers that have used Amazon’s pay-by-the sip service to develop apps without having to go through the laborious approvals process for infrastructure, and then the business sponsors of the application have said to just leave it there rather than moving it back ‘inside.’ But, as Nygard writes, this doesn’t necessarily mean that Amazon’s EC2 service — or EMC’s or Sun’s or Dell’s… — is going to suck up all of these virtualized enterprise machines, although that is one option. Another option is that enterprises are going to build their own clouds and host their platforms themselves. Again, the issues are not so much technical as political: no less real, just different.

The existence of the pay-by-the-sip services is, however, going to cast a harsh light on the value of corporate IT services. The business owners will be able to see, exactly, how much more they’re paying for supposedly secure inside-the-firewall services compared with out-in-the-wild services. And by services I mean computing/storage/etc.

4. Ongoing

So where is this all going? In a characteristically insightful piece, Tim Bray surveys the landscape and sees change all around — in programming languages, databases, desktops, and elsewhere. For instance, if you’re looking for the new Emerging-category database, Bray suggests Apache CouchDB, Amazon’s SimpleDB or Google’s BigTable. I don’t know if that’s right or not but he’s smarter than me. And this is what he has to say about the strategies to make money from all of these observations:

Business Models · Servers, they’re easy to understand. Blue-suited salesmen sell them to CIOs a few hundred thousand dollars’ worth at a time, they get loaded into data centers where they suck up too much power and HVAC.

Well, unless you’re gonna do your storage and compute and load-balancing and so on out in the cloud. Are you? The CIOs and data-center guys are wrestling this problem to the ground right now.

And as for software, used to be you shipped binaries on magnetic media and charged ’em a right-to-use license. Nope, nowadays it’s open-source and they download it for free and you charge them a support contract. Nope, that was last century; maybe the software’s all going to be out there in the cloud and you never download anything, just pay to use what’s there.

Personally, I don’t think any of those models are actually going to go away. But which works best where? The market’s working that out, right now.

For now, that seems to be just about the right answer to me.

One thought on “Head in the clouds

  1. I was having the discussion today about virtual servers. With one arch talking about how management problems arise with more than 20 virtuals. I, otoh, think that the more servers you have the better. I’d like to see each developer manage their own developmet virtual server. That way if they hose their environment they can just ask to have it reimaged.
    On the green topic, we all should try to do our part. I created RideSearch.com to help the nation carpool. I foresee the need for more servers in the future…

    Carpool for a better tomorrow

Comments are closed.