The core of this series of posts (this is part 1 of 4) comes from a talk I gave at the 2011 CSA Congress.
My contention is that the companies in the best position to truly disrupt the status quo of what we perceive as cloud today are the "traditional" Telcos. Note when I first developed and wrote the presentation at the CSA Congress I was working for AT&T although by the time of the congress I had moved on to a different company. My opinion hadn't changed then and hasn’t changed in the last year and a half. I still think the Telcos are in a position to become the dominant CSPs for the foreseeable future.
First, let's agree on some definitions. I use NIST's definition of a cloud as being made up of the following elements:
- On-Demand Self-Service and
While it might be implied in the above items I would add High Availability to that list. None of the other elements mean anything if we can't get to them.
Additionally, I would break these down further, though in no particular order, to:
- Accessible from anywhere,
- Infinitely scalable, both up and down,
- Easy to consume and use without human intervention,
- Able to provide metered usage statistics and modify the behavior of the cloud accordingly, and oh yeah,
- Secure. The meaning of which is different depending on who you ask and when you ask them.
In other words, what we NEED is a cloud we can safely and securely access, whenever we want, from wherever we want, as much as we want, and on whatever device we want. Add to that the fact that the service should be easy to consume and accurately metered and I'd say that's a pretty tall order.
So where does that leave us? Well, since I titled the talk and this post "Will the Real CSPs Please Stand Up" it's safe to say that I have an idea about who could get us to the state of safe and secure access, whenever we want, wherever we want, and on whatever device we want. And I think that is the major carriers such as AT&T and Verizon in the US, and their counterparts in other countries around the world such as BT, Tata Communications, Deutsche Telecom, et. al.
Why do I say that? Because the carriers do some things very well and some of those things map directly to the seven elements on this list.
What do I think the carriers do well?
Let's talk about Always On. Carriers pride themselves on having carrier networks with "five nines" availability which breaks down to effectively outages lasting no more than 5 1/2 minutes per year. Some even boast "six nines" in certain circumstances, which means that the service can only be unavailable for 31.5 seconds per year. Now, we can argue about the veracity of those claims and even usefulness of such terms as 5 9s but I don't think anyone would disagree that the carriers are very good at keeping their networks up and running.
There's talk that even Six Nines might not end up being good enough. Tellabs released a whitepaper a few years ago describing what they termed “uberreliability” www.tellabs.com/resources/papers/tlab_uberreliability.pdf and I urge you to go and read it and then decide for yourself what service provider communities, other than the carriers, are even close to meeting such metrics.
What will be interesting to see is if the carriers can take that expertise in providing such highly available services and do the same thing for not just their traditional voice services but their cloud services as well. I think it's safe to assume that the accessibility part of the cloud will be covered, considering the carriers are going to use their existing transport networks to get you from where you are to the cloud anyway, so what they'll need to focus on is the back end services portion.
Tomorrow I will address the remaining cloud components that carriers already handle in the next post in this series so please stay tuned.
In the meantime if you have any questions or comments about the series so far please feel free to share them in the comments section below, via email at jdk at calibersecurity dot com or on twitter @joeknape and I will address them as part of a future post.
Thanks for reading.