In the sea of buzzwords that we are inundated with in IT, none is more popular these days than the word “cloud”. What is important about this word though is that it comes with a very specific meaning that many products and services are missing. I liken it to the word “magic” which in itself is not possible, however the concept of something being “magical” is.
Cloud is being used the same way in many cases, and because of this we have to be aware of its requirements and evaluate those requirements to see if the product, vendor or service is in fact a true cloud offering.
What is the Cloud?
There are many phrases used to define the cloud but what we have to understand is that the general standard of cloud computing has three characteristics:
- Available on-demand through self-service from a Service Catalog
- Fully managed (in the case of public cloud)
- Elastic capacity and billing
Some additional reading to introduce the various definitions of Cloud can be found on the Wiki page which may help to expand your understanding: http://en.wikipedia.org/wiki/Cloud_computing
The Litmus Test for Cloud Products
The 3 key features listed above are the requirements. While many services offer similar types of service, we must have all of these features present to have a true cloud product.
Self-service and the Service Catalog are first and foremost in the list with good reason. In the cloud environment (including private, public or hybrid) the customer drives the usage through their own on-demand portal. This can be a web portal, but also extends into the availability of an API for programmatically managing the cloud services. If it requires a phone call or for a person to be involved in the delivery of those services, it doesn’t make the cut.
Fully managed is fairly self explanatory. The customer has no need to worry about environmental management, hardware provisioning or maintenance. This applies to public cloud deployments. Obviously in private cloud or hybrid cloud environments there will still be active management at the customer site.
Finally we have an elastic service. Elastic means that in can expand on-demand and includes duration of availability (minutes, hours, days) and sizing (CPU, memory, DB, storage). Elasticity is about two directions which many don’t realize. It is not just about being able to grow on-demand, but to be able to shrink when needed as well.
Elasticity provides a way for systems to respond to needs and to reduce expense when those resources are not needed. For the vSphere folks, think of it along the lines of Distributed Power Management.
Cloud: Yes. Heaven: No.
I hate to break the bubble for people, but having access to the cloud isn’t going to be the solution to system design issues. Cloud resources will not solve a problem with an application infrastructure or code that isn’t well written. If you have a performance issue in a small deployment, growing the environment may just escalate your issues.
Whatever you have today needs to be re-evaluated for requirements and how it will map against a new cloud deployment; or more importantly if it is applicable for a cloud deployment.
In the same way that the new infrastructure provides exciting ways to do things differently, we have to change the way that we deploy and manage services within our organization. This is a fundamental change in how we do business with IT. As an IT organization, we need to re-engage our business and become more agile; both literally and figuratively.
Cloud is not Automatic Disaster Recovery
Even beyond the last paragraph, this point needs to be hammered home with force. Having cloud services is NOT a disaster recovery plan. Cloud services can be an enabler for new ways to protect your systems, but unless you architect for it, just deploying to the cloud does nothing more than move the same unprotected system to a new location. No matter how you juggle the balls, there are still the same number of balls.
Using cloud infrastructure as a a new place to deploy BCP/DR installations is a brave new world. And it is an ideal way to utilize this service because of its elasticity. As more competition comes in “Enterprise” cloud infrastructure we are already seeing significant price changes in the favor of the customer.
Cloud is not Guaranteed Uptime
As I’ve written about previously (The Mighty Chain of IT), we have many things involved in managing uptime. Despite any promise of five-9 uptime (99.999%) the reality of it is that it is only words. When outages happen in the cloud infrastructure, which they will, the best that we can get from that is a contractual deduction in pricing; or, in other words, some of our money back.
Cloud is Here, and it is Directional
The long and the short of the discussion is that cloud infrastructure, in its many flavors, is accessible today. And more importantly, it is becoming an accepted standard for organizations across every industry vertical. Every year we may here some buzzword driven marketing about it being the “year of VDI” or “year of Cloud” but we are past the hype at this point.
What is even more exciting about cloud infrastructure is that it is ever evolving and this is the start of an incredible era in computing. Although cloud isn’t the answer to all issues, it is a directional shift in how things are moving. Just be wary of a how “cloudy” your service is because just naming something as a cloud doesn’t make it so.
You can paint black stripes on a white horse, but it won’t turn into a zebra.
2 thoughts on “Why a “cloud” product may not really be a cloud product”
A key takeaway from this is that “cloud is not guaranteed uptime”. Outages can still happen in the cloud. This is why a cloud monitoring solution is required, to find and fix an issue before it affects end users.
Well said Susan! I’d love to be able to speak about how your product could augment a current solution. Perhaps we should put something together for the blog here and open up the discussion. Drop me a line and we can chat about it if you’d like.