April 30, 2015

April 10, 2015

Please reload

Recent Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Featured Posts

Will the Real CSP’s Please Stand Up? (Part 3 of 4)

September 5, 2013

 

You’ll remember from part 1 of this series that I’ve described and defined “cloud” as:

And, in part 2 of this series we made it through about half of that list.

This post, part 3 of 4, describes where I think the carriers still have a lot of work to do and what they can do to address those shortcomings.

How about infinitely scalable? This is a subset of rapid elasticity and is an interesting concept for Service Providers in general and carriers in particular. They have entire groups dedicated to capacity planning. How much bandwidth should we allocate to a given location? What about data centers? How big should they be? How much space and power and cooling will we need? The carriers are so used to planning for some maximum load and then expanding their resources only when it's absolutely necessary and only over some period of time, usually years, that the ability to infinitely scale up or down, on demand might be a tough one for them.

There are a couple of ways the individual carriers have decided to acquire this functionality; both of them pretty straightforward. They either build it or buy it. Verizon, for instance, opted to buy Terramark. This gives them an almost turnkey solution to start adding services on to without having to expand existing infrastructure, which can get expensive.

AT&T, and most recently Sprint, on the other hand, have decided to use their existing Data Centers. I think one of these will turn out to be a better choice and that because of that some of the carriers will reach maturity as a CSP before the others. As for which one, well I think Verizon has the better chance of getting there first but I never count out a company with a 171 Billion dollar valuation.

What about easy to consume? I'm not talking here about how easy it is to provision your phone or even use it to access resources. Those are pretty straight forward. If we take a step back for a minute and talk about a more traditional computing model, the hosted data center, it's plain to see that getting a company's systems to talk to a provider's data center can sometimes be a very frustrating experience. Just ask @reillyusa or @beaker.

Will it be over MPLS? Or IPSec VPN? What about Customer Premise devices? Those conversations can take weeks or months. And that's just moving the 1s and 0s back and forth. That length of time can't happen with cloud resources.

And after the networking has been figured out? How easy is it for the customer to interact with the service provider to access excess resources or provision more systems or take down a system that is no longer needed? Answer, not very. If it takes less than a few phone calls, some email and sometimes months of waiting you're very lucky. Again, this is something that is just not tenable in a cloud environment.

The two elements I just mentioned, infinite scalability and easy to consume are both necessary for the rapid elasticity component. Without the ability to scale up and down or interact quickly and accurately with the cloud, rapid elasticity is impossible.

If you combine accurate information around what is going on in the cloud at any given moment with the capability to quickly provision or de-provision elements that make up the cloud you've given yourself the ability to modify the cloud in response to demand. This flexibility and responsiveness based on real time data is very powerful. Carriers haven't really had to think about this ability, again because they've been able to plan for capacity based on years of experience. Not to mention the fact that if any given part of their system operated at excess capacity for any given time they never really needed to do anything about it right away because of elements of supply and demand. Sometimes they're the only game in town so consumers haven't always had a choice in the matter. That has slowly changed over time which makes them more responsive to issues such as dropped calls, oversubscribed networks and the like.

Even with this new found realization, competition in other words, carriers are still not equipped to be able to modify their systems on the fly. Part of this goes back to the availability discussion we had earlier. The systems that provide five and six nines up time are systems that have historically had to be very static. Don't touch it, don't ever touch it.

 

The dynamic nature of a rapidly elastic cloud is almost anathema to the carrier way of thinking. What has to happen is for those employed at the carriers to understand that stable does not have to equal static. Fortunately there are several companies today that are working on ecosystems that prove that very thing. It's almost inevitable that the lessons learned from such ecosystems will eventually work their way into the carrier networks.

This is where I think a company like Verizon might have a head start. Since AT&T and Sprint are using their own data centers they are having to build out all the base level services. Verizon basically bought a turnkey Infrastructure as a Service and is trying to build from there. For all the other service models, Platform, Software, Security, X, the carriers will have to decide whether they want to partner with an existing service provider that already has a solution or try to build it themselves.

Again, each carrier seems to be going about this in their own way. To me the obvious choice is to leverage the expertise and skill set of others that have gone before and not try to reinvent the wheel.

So we've covered six of the seven elements that make up a fully-baked cloud, always on, accessible from anywhere, device agnostic, measured service, infinitely scalable and easy to use. We saw how the ease of use and infinite scalability are essential aspects of rapid elasticity.

What about the seventh element, Secure? That will be the subject of the fourth and final post in this series and you can read about that tomorrow.

Thanks for reading.

Joe can be reached in the comments section below, via email at jdk at calibersecurity dot com or on twitter @joeknape.

Share on Facebook
Share on Twitter
Please reload

Follow Us

I'm busy working on my blog posts. Watch this space!

Please reload

Search By Tags