You're deploying a cloud in support of enterprise IT. Typically, there are three approaches (private, public, hybrid) times 30 providers/technology times 10 patterns of use times 400 things you can bolt on for one reason or another. Yikes! that's 360,000 permutations, and they're not mutually exclusive. In a way, cloud solutions are like snowflakes: No two are alike. Most work. But they all don't provide the same degree of efficiency and value.
Given all these permutations, the trend has been to overcomplicate many deployments. Where five technologies and/or providers will do just fine, many organizations try to deal with all contingencies. In many instances, they incorporate what seems to be trendy at the time, adding technology for its own sake. An example would be using newer and more expensive security models, such as identity management, when there is really no requirement for it. Or bolting on a monitoring and management system that may not be needed.
[ Get the no-nonsense explanations and advice you need to take real advantage of cloud computing in InfoWorld editors' 21-page Cloud Computing Deep Dive PDF special report. | Stay up on the cloud with InfoWorld's Cloud Computing Report newsletter. ]
I get it. In building software, cloud or otherwise, it's tempting to toss in anything and everything you can into the technology stack. After all, adding to the technology stack later can be very difficult. That's a justifiable temptation. However, for each component you toss into the architecture, that's another piece or part you need to maintain over time, meaning more cost and more risk.
Furthemore, enterprise IT is getting into the thick of cloud computing, so many people lack experience. At the same time, the market is being flooded with cloud computing technologies, both on-demand and local software, and many of them sound compelling.
The word here is "discipline." The business requirements should lead, and you must understand those needs and back the right technology into their solution. I understand about future requirements, but, hey, that's part of the requirements, right? If you can't define the need now or see it as a clear demand in the future, you can probably let it go.
When in doubt, leave it out.
This article, "Killing the cloud with complexity," originally appeared at InfoWorld.com. Read more of David Linthicum's Cloud Computing blog and track the latest developments in cloud computing at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.