I decided it would be a good idea to write a series of blog posts about NFV. Why?
Over the last year, I have had to traverse a steep learning curve to understand what NFV is so that I would be in a position where I am comfortable having conversations with service providers and Telcos about it. As I have worked with others in our community, I have recognised the same look of confusion I had when I first started.
Secondly, it is clear there is a lot of general confusion around this topic, and I think it is important to provide some clarity about the general concepts. This is a new area for us as a company, so it is OK for there to be some confusion at this point. But that will need to change over the coming year as this business grows.
So, what is NFV?
The acronym stands for Network Functions Virtualisation. As I mentioned earlier, I was not an expert in NFV or networking. My skillset lies in Cloud computing. As I delved into the topic, however, I found some interesting facts.
- NFV is the convergence point between telecommunications and IT Enterprise Cloud computing.
- The two worlds do not understand each other, and I would argue there is some friction, too.
- Because of this unawareness, it is difficult to find informative material that caters to the needs of those who are on opposite sides of the fence.
As I read material about NFV, I would often be confused, because it made assumptions about my base knowledge that were inaccurate because I had never worked in telecoms or core networking before. When I decided to speak to people who understood NFV I found the same problem. They spoke at a level that was above my knowledge base, and I struggled to understand what they were saying.
I also noticed—when listening to conversations and reading correspondence—that many people are confusing NFV and software-defined networking (SDN) or network virtualization, and are therefore adding to the confusion of others, or unintentionally misrepresenting information to customers.
Hence this series. I will try to explain NFV from the perspective of an IT/Cloud person, which will hopefully make it easier to understand, and make it easier for you to have reasonably intelligent conversations with those who know NFV. Be careful though: A little knowledge can be dangerous. Know your limits and engage an expert when necessary. This hopefully does not mean only IT people will understand what I have written. Hopefully it will be clear for anyone with an inquiring mind.
We have established what NFV means, but what is it?
The first thing to say is that NFV is not network virtualization, or sometimes called SDN. Network virtualization is delivered by VMware NSX from the VMware portfolio. Network virtualisation is only a part of an NFV solution.
Let’s take a step back before we move forward and explain how Telcos traditionally deliver network functions; the context will help you to understand this topic more easily. Network functions have traditionally been delivered using proprietary hardware, where a specific server—built for the delivery of that service/function only—delivers the function. This purpose-built hardware is designed to meet the performance and service- level agreements required of that function, and would do it very well. This purpose-built hardware would be designed and built by network equipment providers (NEPs), and sold to the Telcos, who would then sell these network functions to their customers.
This model has worked successfully for years, but it carries some challenges:
- The proprietary hardware is very expensive = CAPEX (capital expenditure) pressures.
- The hardware only fulfills a single fuction = Capacity management challenges.
- Skills needed to support the hardware are very specialised = Silos of support and high maintenance cost. OPEX (operating expenditure) pressures.
- Bringing new services on board is very expensive and time consuming = Lack of agility and responsiveness to business requirements.
When the Telco industry took a look at what cloud computing promises the enterprise, they found it addressed many of the challenges they were struggling with (like cost, agility, and silos). But in order to take advantage of these promises, they had to virtualise the network functions so they could run on a cloud.
There are many implications with this idea:
- The network functions had to be developed as software instead of imbedded hardware functions.
- The NEPs had to be convinced that this was a good thing, since they made a living from building the hardware appliances.
- The cloud had to provide the same level of performance—and meet other key performance indicators—that were currently being delivered using the hardware appliances.
- The management functions that accompanied each hardware appliance have to be delivered as a consolidated/shared function on a cloud platform, because the concept of a shared platform is foreign to this solution space. Some of these management functions are similar to those in the enterprise space, but some are very different. Additionally, there are subtle nuances to similar management functions, and it is important for us to understand these.
The movement surrounding this new solution paradigm is called network function virtualisation. In summary, it is about moving network functions from their proprietary hardware appliances on to a shared cloud platform by virtualising them.
So this raises a whole list of new questions. This is why I decided to write this series of blogs; one blog would be too long to answer all these questions, and at the same time do them justice.
Upcoming blog topics:
- What is a network function?
- What is VMware’s solution in this space?
