So what’s the best way to construct a clear, precise and consistent
cloud definition? In my mind, nothing would work better than mathematical
formulas. Bear with me for a second here… Mathematics has always been
considered the most refined of sciences. It’s been said that in order for
anyone to produce sophisticated but simplified depictions of scientific
concepts, it would have to be represented using math. On the other hand, using
formulas to define IT concepts brings about a major problem. Formulas paint the
application of a definition in either black or white. There are no greys here.
This means that if you are trying to apply my definition to your cloud
strategy, it will either be a perfect fit or it will highlight some application
gaps. Is this good a thing? Maybe!
The one thing I can voice here is that formulas are
beautiful when they are kept simple (think E=MC2). By keeping the
cloud formulas simple, I aim to keep the definition simple, and hopefully make
it easier to align this definition with the reality of IT environments… With that in mind, let’s give it a try.
In this blog entry, I will attempt to simplify the Private Cloud
definition. So let’s lead with the formula:
Private
Cloud = Virtualization + Orchestration + Service Catalog
Yes, it is that simple. And that is what transitioning to a
private cloud environment should mean for the majority of organizations. Most
of today’s establishments do not need more than a solid foundation of
virtualization infrastructure to provide the resource pooling and rapid
elasticity the NIST definition calls for. Add a layer of basic business process
automation and a coating of service management, and you’ve got yourself a
private cloud.
In a nutshell, organizations should focus their energy on deliberating,
identifying, and codifying the IT services that could be included as part of
their overall IT Service Catalog. This provides an immediate value to both the
end users and the IT organization itself. It explicates and clarifies the
mission of IT and prompts IT services to be more consumable. Likewise, the
automation of service provisioning and maintenance activities would also
increase the value of IT services and reduce their associated costs. This, of
course, is no news… organization have been trying to achieve for years. However,
it’s now easier to achieve with the flexibility of virtual infrastructures and
virtualization management systems.
But, how about the remaining NIST cloud characteristics?
Don’t we need “on-demand self-service”, “broad network access” and “measured
service” to make it a real private cloud?
My answer is not really… The value of private clouds
could definitely be extended if self-service and charge/show back capabilities
are added to the mix. But these capabilities might not always be required to
achieve the value and ROI anticipated from Private clouds. Realistically, many
organizations will opt-out of self-service on the short run as it might clash
with their current users’ culture. Users will continue to favor the traditional
model of assisted service for the majority of their IT demands. Their level of
IT knowledge as well as interest in being exposed to technology details might
become the biggest hurdle to overcome. Subsequently, the internal IT team might
become the only user of the self-service capability. Likewise, charge back and/or
show back capabilities are another “great to have”. They do add a lot of value and
can increase the outcome of private cloud implementations but are not required
to complete our definition.
Let me be clear here. I am not saying that you should not
consider self-service or charging as part of your private cloud strategy. But
by all means, do not give it more weight than it deserves and do not make it
stop you from capitalizing on the chief goals of private clouds. Instead,
consider the key business drivers, the implementation costs, as well as the readiness
of your organizational culture then determine applicability and plan smartly
for adapting your organization to the implied changes.
Another thought, multi-tenancy is an optional consideration for
private clouds. You are more likely to consider its implications if you are
planning for a public or community cloud (I will work
on formulas for those in a future blog, I promise) but not when you
are supporting a single organization.
So how about the intersection of private clouds with the
cloud service models. In other words, can the concept of private clouds gel nicely
with all cloud service models (IaaS, PaaS, & SaaS) and their derivatives?
My answer is unlikely… For IaaS there is certainly a
good match and a good business case to backup the marriage of the two. But the
correlation starts to fracture with PaaS and SaaS. More about that in a future
blog.
