Time to talk about cloud stacks again. No, not that there are too many (though there are), but rather the one-track mind that many IT buyers I encounter have with respect to cloud. Some end users I have spoken with in the past few weeks are looking to implement a private clouds, and they are actively evaluating “cloud stacks” from a limited number of vendors (mainly their strategic suppliers).
I’ve asked about their process for their private cloud initiatives, and specifically how far along they were on their top-down requirements analysis and documentation. The reply I typically received was more than a little bit surprising. While it varies, it typically goes something like this…
“We have not created a high-level analysis of requirements. We’re evaluating vendor solutions and will pick the best one.”
If IT leaders haven’t thought through their vision for private cloud, translated that into capabilities requirements, and aligned their business users, how can they possibly choose a technology? And why do they think that all they need is a cloud stack?
Is the dog wagging the tail, or is it the other way around? In this case, it’s clearly a case of tails wagging the dog as they get bombarded with vendor cries of “buy this cloud now and it will solve world hunger and peace.”
Cloud projects should have a flow that should definitively answer a VERY LONG set of key questions. Here are JUST A FEW of them…:
- What are the strategic objectives for my cloud program?
- How will my cloud be used?
- Who are my users and what are their expectations and requirements?
- How should/will a cloud model change my data center workflows, policies, processes and skills requirements?
- How will cloud users be given visibility into their usage, costs and possible chargebacks?
- How will cloud users be given visibility into operational issues such as server/zone/regional availability and performance?
- What is my approach to the service catalog? Is it prix fixe, a la carte, or more like value meals? Can users make their own catalogs?
- How will I handle policy around identity, access control, user permissions, etc?
- What are the operational tools that I will use for event management & correlation, performance management, service desk, configuration and change management, monitoring, logging, auditability, and more?
- What will my vCenter administrators do when they are no longer creating VMs for every request?
- What will the approvers in my process flows today do when the handling of 95% of all future requests are policy driven and automated?
- What levels of dynamism are required regarding elasticity, workload placement, data placement and QoS management across all stack layers?
- Beyond a VM, what other services will I expose to my users?
- How will I address each of the key components such as compute, networking, structured & object storage, virtualization, security, automation, self-service, lifecycle management, databases and more?
- What are the workloads I expect to see in my cloud, and what are the requirements for these workloads to run?
This list goes on for several pages, and more. If you have not done this level of analysis, you are not ready to evaluate a cloud stack. Sure, you can research and hear from vendors – often a good way to educate yourself and prompt new thinking about the concepts above. However, customers should stay away from asking for POCs, asking for pricing from vendors, setting budgets, and all of the other dance routines we face in the procurement process.
The unfortunate truth is that most vendors don’t want you to do this because it slows down the sales cycle. But I’m going to quote the carpenter’s axiom here:
Measure twice, cut once!
Would you build a house without a vision, rendering and architectural blueprints? Of course not. However, the other unfortunate truth I am finding is that too many customers I see are falling into this trap. They have the cart way out in front of the horse.
They are practicing “Ready! Fire! Aim!” I’m sure we all can guess how that will work for them…