Whomever added the “b” in subtle is a genius…and don’t get me started on the silent “e”…
They could have spelled the word awkwardly like “sutel”, or like its pronounced “suttle” but I bet the gray hair in the backroom of the Dictionary Institute wanted to add some flair, wanted to create a conversation piece, wanted to show some imagination, wanted people to wonder in amazement. They wanted people to talk about it.
Quite possibly they simply wanted to add a little creative discussion to the dictionary, and combined with contempt with the Proper English Spelling Rules that lead to boring words like “boring” and “word”, decided to do something different. They wanted people to argue about it.
After winning several recent arguments over the definition of Cloud, I have come to the conclusion that no doubt the same authors of subtle, had their hand in this foggy situation. “Creative discussions” usually start out with this group consensus: there are so many definitions of Cloud no wonder every thinks they have one…
That can’t possibly be true.
Very rarely would I expect that a 100+ year young national organization that exists for the purpose of being the fundamental measurement tool of technology definitions, would be “foggy” on the concept, or on any concept to which they provide definitions…especially considering the raw definition is used on every slide deck I have ever seen on the topic of Cloud. No, it’s unlikely that we disagree on the definition.
What is likely however, is that we 1) forget that the CHARACTERISTICS of cloud are applied regardless of the chosen SERVICE and/or DELIVERY model, and 2) mostly lack a definition for “level of done-ness” of the characteristics required to call our result a “Cloud”.
Let’s me explain….
By known definition, I’m sure we agree that the CHARACTERISTICS of Cloud are on demand: resource pooling (virtualized), broad network access, rapid elasticity (automation), self-service (SPOG), and measured service. Additionally, the assessment of these characteristics are from the outside looking in (i.e. if an external body were to review the Cloud, would it exemplify these characteristics). Textbook.
What’s not textbook, is when either service models or delivery models BECOME apparent characteristics of Cloud, when in fact the characteristics apply regardless of model. For example, for simplicity, let’s say there are 3 SERVICE models (ie what type of offering is being provided):
1. Infrastructure (as a service)
2. Platform (as a service)
3. Software (as a service)
In each, you have different ISO levels of “under management”. For any of these service models to be considered Cloud, the characteristics of Cloud must apply. If they do not, drop the “as a service” as you simply have plain old software and infrastructure, like you have always had…. In fact, applying the characteristics to any legacy model helps determine whether the “new” SaaS offering from your favourite vendor is in fact truly a new Cloud offering, or just a remarketed version of an ASP that they marketed last year (which was an installed tool they marketed a year before).
One doesn’t move from ASP to SaaS, unless resource pooling (virtualized), broad network access, rapid elasticity (automation), self-service (SPOG), and measured service are introduced.
Likewise, example, let’s say there are 4 DELIVERY models (i.e. from what source would one deliver the service as described above):
1. Private (cloud)
2. Public (cloud)
3. Community (cloud)
4. Hybrid (clouds)
In each case you have different levels of ownership, presumed/expected security concerns, and financial considerations. For any of these delivery models to be considered Cloud, the characteristics of Cloud must apply. If they do not, drop the “Cloud” as you simply have plain old software and infrastructure, like you have always had….just consumed from different sources.
One applies resource pooling (virtualized), broad network access, rapid elasticity (automation), self-service (SPOG), and measured service into/from a service within a public, private, community or hybrid deployment.
Of course service and delivery models work in concert, in a standard matrix. Cloud offerings are usually described as one or more of SaaS/PaaS/IaaS (of some subset) services, and work within one or more of Private/Public/Community/Hybrid deployment. Fog is generated when the discussion does NOT include all three dimensions; they are not standalone concepts. You MUST understand the application of Cloud characteristics AND the service and delivery models to appreciate the holistic definition of the Cloud offering.
To relate to real examples from the Hitachi family, HCP Anywhere would be considered a SaaS service for File Sync and Share that could be deployed in a private cloud for enterprises or community cloud for the clients of enterprises. UCP, our converged and unified platform, is an implementation of IaaS service that could be deployed in a private cloud for enterprises or public cloud as a white labelled service offering. Both HCP Anywhere and UCP share the characteristics of Cloud.
Secondly, the discussion becomes MUCH more foggy when the topic leads to the ill-defined “level of done-ness” or level of readiness of each of the characteristics. Let me pose these questions:
- What % of the infrastructure must be virtualized before its considered a Cloud?
- Do all services need to be available for self-service provisioning before its considered a Cloud?
- Do all components needs to be managed by a single pane of glass before its considered a Cloud?
- If I know I have to buy more hardware for the next project, can I still consider it elastic?
- We can show the costs but not really charge it back to the consumer, can I still call it cloud?
- I have a heterogeneous environment, without a converged stack, but I still comply to the characteristics of cloud, can I call it Cloud?
It’s very easy to be binary here. All or nothing. Cloud or not. Realistically however, VERY VERY few deployments of Cloud could possibly meet the purity of characteristic completeness. It would also be very easy to apply some arbitrary or average-based scorecard for each of the characteristics, and objectively assess your grade. But we are not there yet.
For a realistic assessment, we will need to rely on a subjective observation of how someone external to the environment, external to the organization, might assess the “level of done-ness” based on past experience and level of maturity of the industry and peer group. Sort of like the characteristics themselves. That seems perfectly reasonable.