An Open Cloud Strategy, 3 Bullet Edition

Nov 01 2011

I posted a link to David Lutterkort’s fantastic talk on the Aeolus Project at PuppetConf 2011, and Matt Asay jumped right in:

[blackbirdpie url="https://twitter.com/#!/mjasay/status/131046988971130880"]

He’s right. So I blithely replied:

[blackbirdpie url="https://twitter.com/#!/ghelleks/status/131047965061156867"]

This blog post was thus inevitable.

1) Choice is important.

This should be “Choice is still important.” but it wouldn’t fit in the tweet.

The IT industry has spent the last ten to fifteen years moving off of closed, proprietary stacks of hardware and software towards relatively open, standardized, commodity gear. If I move away from single-vendor platforms, I’ll probably save money on the up-front cost, but I’m also saving by introducing competition. I can compete HP, Dell, and IBM against each other and I’ll probably get a better price than if I have to sole-source that hardware buy. Open platforms also give me a better chance of incorporating new innovations, since I don’t have to wait for my one-and-only vendor to catch up.

An Exadata server.

Literally, a monolith. (Courtesy flickr user plαdys, licensed CC-BY-NC-SA)

In these early days of the virtualization and cloud market, there are a lot of software and hardware vendors that want to sell you a “cloud in a box”. This is a monolithic piece of hardware with all your infrastructure stuffed inside: networking, compute, storage, operating systems, databases, and so on. They’re expensive up front, but the gamble is that by removing or reducing the cost of tying all these pieces together yourself, it’s less expensive in the long-run.

I remember hearing Oracle’s CIO, Mark Sunday, evangelizing “Freedom from choice” at a trade show. I don’t know if he was being intentionally Orwellian, but I do know that he’s wrong.

We all know he’s wrong because we spent the last 10-15 years trying to undo that thinking when we moved from proprietary systems to the more open commodities. When we outsource our ability to make intelligent decisions, we lose. When we gamble on one vendor always making the right decision, we lose. When we get handcuffed to a single vendor, we lose.

Cloud computing is about elasticity and flexibility. It’s about moving away from encumbering capital investments and towards operating expenses, which are more agile. A big black refrigerator with all my hardware and software in it is the opposite of that. A single vendor in control of my entire virtualization layer is the opposite of that.

The idea that you can abstract away all of your integration problems is still very attractive – there’s no denying that. If I can take a whole host of data center choices and hide them inside one monolith, I can spend more time on things I care about. If something goes wrong, I know exactly who is to blame. But there’s a different solution to that problem, which brings us to the next bullet:

2) Confuse standardization and consolidation at your peril.

I maintain that you can get much more out of your infrastructure and your staff by encouraging standardization, rather than consolidating your spend with a single vendor.

Even in these early days of enterprise cloud use, it’s becoming apparent that unless you can rationalize your infrastructure, standardize your deployments, and drastically improve your management tools, the best you can do with virtualization is buy less hardware. If every major application has its own database configuration, messaging infrastructure and operating system build, all the agility and flexibility of the cloud and virtualization infrastructures won’t help you. Your systems will still be running in their own hand-crafted silos. You will get no economy of scale. You will pay just as much, if not more, to maintain these silos over time. It doesn’t matter if they live in a perfectly open infrastructure or inside a black monolith.

What if you used a cloud or virtualization migration as a means to rationalize your portfolio? If your operating systems are standardized across physical, virtual, and cloud-deployed systems, it’s a lot easier to integrate those systems. The same goes for databases, for middleware, and for messaging systems. To the extent that you can standardize, you give yourself more deployment choices and make better use of your people.

This is the cloud equivalent of the 10-15 year move to commodity hardware I mentioned earlier. If your systems can be moved from one infrastructure to another with relatively little effort, you’re giving yourself a strategic advantage. You can compete virtualization platforms. You can compete cloud providers. You’re also making the best possible use of your staff–they don’t want to maintain eight variants of WebSphere any more than you do.

3) Cloud is process optimization.

So if we now have our choice of software and hardware vendors, and have standard, predictable, manageable workloads, what’s left? Our internal processes. Our technical and business processes have to be able to support the flexibility and scalability that these decisions allow.

This is much harder than most shops anticipate. Just because you can do something technically doesn’t mean that your organization is up for it. My favorite example is the good people at DISA’s RACE project. They did a lot of work to make it simple for their users to pay for computing power with a credit card. Technically, the solution works just fine. In practice, their internal business rules make it impossible to transfer money between departments any quicker than three days. That means that no matter how flexible their internal IT systems are, they’re only moving as quickly as their weakest business process. It’s problems like these that need to be solved to enable the fully extensible, scalable, flexible cloud we’re all praying for.

Technical processes can be just as problematic. I work with the Federal government, and they have some elaborate rules for how systems are locked down and made secure. Too often, these processes are conducted by hand, for every machine. Federal cloud adopters are furiously trying to improve their security and audit processes to match the speed at which deployments can now move.

This may be the most important of the three bullets I’ve described: the success of your cloud deployment is only as successful as your internal business and technical processes will permit. Your choice of product or platform is almost irrelevant if you haven’t tackled some of these basic internal challenges first.

There is good news here. These three bullets are just as valuable to you even if you’re not considering cloud or virtualization infrastructures. They are, I think, prerequisites to that kind of environment, but they’re valuable in and of themselves. Cloud isn’t, in short, something that can be bought. It is something that, when properly implemented, will profoundly change the way your IT staff does business. That transition from lock-in, inflexibility, and lack of control is what is so exciting about cloud – but you don’t need a cloud to get it.

2 responses so far

  • Guy Martin

    Gunnar, is this where we are supposed to say: ‘It’s the people, stupid’? :D  Great post!

  • tawster

    Brilliant!