When vendors pitch software, they spend a lot of time demoing and discussing what the software can do, and usually no time exploring how the software gets into a usable state in the first place. The assumption that they hope their prospective customers make is that installation and configuration are straightforward and uninteresting.
In fact, the opposite is usually true: the more complex the problem that software solves, the more complicated the problems will be during initial setup.
What does this suggest about products that manage today’s cloud computing environments? Given that we’re talking about one of the most complicated problem domains in software, you’d guess that setup problems are endemic and fearsome.
And you’d be right.
Here are just a few of the headache-inducing questions that must be addressed in a deployment of a cloud management suite:
- How will we model the different latency and connectivity characteristics of our network, such that we can optimize the behavior of deployed software?
- How will we guarantee that each communication channel in our integrated stack is appropriately secured, has the necessary firewall exceptions, and is protected from DDoS and similar disruptions?
- How will we decompose the overall stack into constituent entities that can be bundled efficiently on separate servers?
- How will we scale out?
- How will we guarantee high availability? And what high availability guarantees represent the right tradeoff between cost/upfront preparation and nimbleness?
- Are subcomponents of the system individually upgradable? Is there a required component order for upgrade? Do the subcomponents test for mutual compatibility as they interact?
The list goes on and on.
These are solvable problems, and I’m not complaining. In fact, part of my passion is solving problems exactly like these, so customers don’t have to. My point is that it’s critical for cloud vendors to take their game to the next level on the matter of setup and configuration. As I’ve said several times in past blog posts, the value proposition of cloud is about simplicity, and customers will only perceive ROI in cloud when we deliver them something usable. That can’t happen if we think setup and configuration is an uninteresting side note.
Adaptive Computing has been working hard on this issue already. We added RPMs to our original tarball-based deployment model, which give us faster and more uniform install. It also makes upgrades far easier to manage. Substantial work has been done on how to decompose our cloud suite into component servers that make sense. For the first time we’ve explained the deployment considerations that inform good choices about high availability (see “Implementing a Highly Available Moab Cloud or HPC Suite” whitepaper, just released at MoabCon 2013).
I’ve recently become interested in using autoconfiguration to take our game to the next level. That’s my personal research project for the next few months. I’m hopeful that it will yield an even better install experience than what we offer today. Imagine cloud services that discover one another and cooperate to uber-optimize… Should I stop short of the autoconfig behavior in this comic?