Personally I'm more aligned to the NIST definitions re cloud (http://csrc.nist.gov/groups/SNS/cloud-computing/)- now these aren't perfect, but rather a common reference point. Sadly even those are being 'interpreted' conveniently by many now...
Couple of things I'm fairly clear about in my mind :-
- Virtualisation /= Dynamic Data Centre /= Cloud
- Virtualisation is often used currently for 'tin stacking' with existing provision & operations processes, nothing wrong with that but a short term capex and facilities opex benefit only.
- Dynamic Data Centre is taking virtualisation to the next step, embracing automation and dynamic integration with other infrastructure support and management toolsets, this could be related to 'private cloud' if combined with a service model & opex accounting/recharging to the business customer
- Cloud includes a wider set of topics relating to ownership, finance, roles/responsibilities, managed services, commodity and scale that are typically not address by the above points
- Shared Infrastructure /= Cloud
- 'pool' would be better term for shared infrstructure, and yes these are a good idea in enterprises (should be the default option for everything in the infrastructure stack)
- But having an array with 15 different applications using it isn't a cloud, it's an array with multiple consumers, yes this forces a service mentality but that's hardly anything new...
Some of the questions I use as a litmus test for people telling me they are offering 'cloud services/technologies' is :-
- Are the actual purchase prices (not RRP etc, but actual buy prices) made available publicly for anybody to access?
- Are the prices the same for everybody (other than consumption based tiers)?
- Are the SLAs published publicly for anybody to access?
- Does the supplier publish a full TCO/ROI model for the customer to examine / adapt etc?
- What type of standards does this operate with / under?
- What's different to the past? (eg 'outsourcing', 'managed service', 'HP UDC', 'Egenera BladeFrame & PAM' etc)
- What is different between this and classic enterprise IT usage?
- Is the minimum duration of engagement hours, days, weeks, months or years?
- What is the 'startup latency' of the engagement?
- What are the metric elements for cost?
- What is the level of granularity of cost (consumption & change)?
- Do I need to meet/talk with a human in order to setup, purchase & use the technology or service?
- Is the technology or service fully controllable by a published API?
Clearly there are different questions / relevance between consuming cloud services, and utilising technologies in order to provide cloud services - but I find above an interesting starting point for both. Similarly there is no defined right or wrong answer to above, but the combined answers help frame my understanding (I have a very long list of other questions but that's for another day & blog entry).
Naturally consumption of cloud services tends to have a very different financial model & aspects that need to be accounted for when comparing (but that's a subject for a much bigger blog entry). Whilst internal company recharging can alter the appearance of financials for some it doesn't for the company as a whole (other than help to drive behaviours).
What I am getting really cheesed off with is people marketeering classic data-centre technologies as 'cloud' simply because they can be used as a component within a 'cloud service' - if I were to follow that analogy would I be able to buy 'cloud screws' from http://www.screwfix.com/?Honestly, look its really simple, as usual quiet action & genuine cost reduction talks not hype, marketing or bluster - if you want to ride the 'cloud bubble' be clear how your technology genuinely relates to 'cloud' and in what context, or please I beg of you STHU and focus on what you're good at?
No comments:
Post a Comment