There is no doubt that telecom infrastructure is moving to the cloud. Over the past 20 years, the move from purpose-built hardware to software running on COTS servers has yielded measurable benefits to service providers, such as lower costs and improved serviceability. The next natural step forward from COTS is running the software-based infrastructure in the cloud because additional benefits will continue.

The benefits of cloud-based infrastructure are as follows:

• capex savings  (plus the ability to move expenditures to opex),
• opex savings, and
• accelerating service velocity.

The question at hand now is what form this cloud-based infrastructure will take. This what I refer to as true NFV, which means adhering to the standards (such as from ETSI (News - Alert)) so that the telecommunications infrastructure software is in a standards-based framework. There’s NFV management and orchestration software, allowing the infrastructure to work with other software (even other companies’ infrastructure virtual network functions) or running the infrastructure as a service in some public cloud. 

While many tier 1 service providers like the concept of true NFV, true NFV also comes with some historic telecom baggage. That is, there are standards and specs to conform to as discussed above, and testing and trial and procurement processes via RFPs with pages and pages and pages of questions. This is all time tested and historically useful to the service provider, but questions get raised, which slows deployment down. And, inevitably, more standards come to the fore. 

The concept of a VNF begets standard orchestration management software so the VNFs that conform to all the specs can talk to each other, and can scale, etc. This whole process makes the tier 1s comfortable. But it’s a vicious cycle, and the end result is that deployments get delayed, and it also just drags out the whole process.  It’s downright reminiscent of IMS!

While this is going on, there are other service providers that just want infrastructure as a service. “Give me an SBC that runs on some public cloud.” “Give me a media server that runs on some public cloud.” “Give me value-added service applications that run on some public cloud.” They want the infrastructure to be able to scale up (and down). They want to move capex to opex. And they want lower overall costs.  In other words, they want the same benefits, the same end game, as true NFV, but possibly obtain this from running an infrastructure virtual machine in a cloud such as Amazon EC2.

And voila, we have telecom infrastructure running on Amazon Web Services (News - Alert). This is easier to do. It’s virtual machines managed by the service provider. The NFV crowd will bring up real issues such as that there is no structure to orchestrate different software together, the VM may not be optimized to run on the specific hardware underneath, clouds potentially are optimized for larger (i.e. video) packets as opposed to smaller voice packets, and the voice packets may have to travel too far – both impacting quality. The clouds may also lack geo redundancy.  Like I said, these are all real issues. But if you go back to the benefits, it's worth the move, especially if you don’t need a gigantic all-encompassing network.

And, by the way, one can get geo redundancy and geo locality to handle latency if one chooses a large enough public cloud provider with a worldwide footprint.  Let’s take a look at geo redundancy in Amazon.

In an AWS implementation, the user has the ability to deploy its applications within specific availability zones, or AZs. Each AWS data center is considered a region. Within each data center region, there are multiple AZs.

AZs are set up to provide isolation for applications running within them from failures in other AZs . In addition, AZs within a region are connected to each other by inexpensive, low latency links. One way of protecting from failure in a single location is by instantiating software infrastructure software in separate AZs. Regions and AZs can be selected through the tools provided by AWS. 

It’s different than true NFV for sure, but it also accomplishes a lot of the same objectives. So while the NFV game plays out, infrastructure on Amazon Web Services marches forward.

Jim Machi is senior vice president of product management and marketing at Dialogic (News - Alert) Inc. (www.dialogic.com).