We designed MobiledgeX Cloudlets to work with mobile operators’ Network Functions Virtualization infrastructure from the start.
As we talk to more mobile operators about integrating our technology into their infrastructure, the relationship with their Network Functions Virtualization (NFV) initiatives often comes up. Is working with MobiledgeX going to make that more complicated or require the use of new and different system infrastructure? The truth is just the opposite. Adding MeX Cloudlets to an NFV enabled mobile infrastructure is remarkably straightforward, as if by design because it was by design. All MobiledgeX system elements have been architected and implemented to fit in and integrate with a spectrum of modern infrastructure ranging from the commonly used cloud platforms to more specific, domain specific architectures including NFV and MEC. Here’s the story, unpacked a little.
NFV, broadly, is an important technological sea change for all large network operators. The basic idea is very simple and economically compelling: transition from dedicated-function network appliances to software workloads running on virtualized, standard servers. Almost all network functionality is implemented in software, let’s start with that. Custom silicon is used for packet forwarding and high-performance routing decisions, but it’s mostly just software. Historically network “devices” (e.g., a switch, a router, a load balancer) were packaged as a hardware appliance, what some like to call “tinware” — a server application wrapped in a metal box.
Compared to typical server applications of the time, hardware appliances were attractive because they were finished (didn’t require server, operating system and application installation and set up) and very easy to configure and start using (e.g., just add a few IP numbers). To use a hardware appliance you unboxed it, rack mounted it, connected power and networking cables, powered it on, spent a few minutes configuring, and you were off. For a network team with limited software and system expertise, this approach worked really well.
The problem with hardware appliances is how they constrain network growth and adaptation to changing market needs. In order to add capacity or network functionality using hardware appliances you have to buy the right set of appliances and install them in the right parts of the network in advance of the additional load or new functionality. If you buy too many or put them in the wrong place, it’s a waste of money. If you buy too few or put them in the wrong place, it constrains your ability to meet demand. And since we’re talking about buying and shipping relatively expensive appliance systems, and racking them and connecting them into the physical network infrastructure, the money involved and the time required to deploy once received is substantial. Appliances made sense for relatively slowly evolving network services; they are increasingly a business liability in the rapidly evolving world of the cloud.
NFV solves this problem by changing from dedicated appliances to software workloads that perform the same function, running on standard, virtualized servers. You still need to have adequate server capacity in the right place before you can add (or shift) network capacity or functionality, but there are many fewer server types, and servers are a lot cheaper (you still have to license the software functionality when deployed) and much simpler to install (don’t have to be wired into the network infrastructure — they just use the network infrastructure). With an NFV infrastructure, new capacity or functionality is added by instantiating the right software workload on a generic server in the right location. When network capacity is no longer needed, the virtual server can be repurposed, and the software license terminated. Measured in cost efficiency and business agility, NFV is simply a better approach.
There are a lot of details in making NFV practical ranging from creating the software workloads that accurately replicate appliance function, creating new licensing structures, to implementing the underlying management structure. Implementing NFV within a mobile operator is still more complex because of integration with existing and proposed infrastructure standards. But all that complexity notwithstanding, the reason to move to NFV is simple and compelling.
So that’s the background. Lots of network operators have some form of NFV initiative which already have them evolving new, virtualized computational infrastructure. Given that, is working with MobiledgeX going to make NFV more difficult or add additional new infrastructure architecture they have to deal with?
We have a good answer here. What we need to support our Cloudlets in a mobile operator infrastructure is a tiny subset of what’s involved in a full NFV implementation (standard servers) and fits very nicely within a standards-based NFV architecture (in fact, we’ve adapted our interfaces and API’s to make them identical when that made sense.) We’re delighted when a mobile operator is down an NFV path because it means that they probably have done 90% of what’s needed to integrate with MobiledgeX.