Thoughts on "Navigating the Road to Cloud-Native Network Functions" by Tom Nolle

Tom Nolle, a well respected consultant in the world of telecom and one of my favorite bloggers, recently posted an article about "Navigating the Road to Cloud-Native Network Functions"

This is my first attempt to paraphrase his words, trying to 'tease out' additional understanding by introducing a slightly different perspective.

===

The NFV community is a loose consortium of vendors and individuals with an established interest in the form of deployed network software products. The continuous evolution in thinking around software architectural engineering principles, the emergence of new software solutions, and changing requirements in both the way these systems get used and in the objectives against which their success is measured, are all forces that drive change.

As humans, we have a tendency to resist change. If it gets colder, we temporarily put on a coat to get warm. If it rains, we may choose a water resistant one to avoid getting wet. Some rare individuals might decide to move to a different country with better weather conditions (on average). And it would take a special kind of - what most other humans would call - "insanity" to even consider more extreme solutions, like inventing a machine or process to eliminate the rain clouds altogether - i.e. bringing about selective, localized climate change.

Back to our Cloud-Native Network Functions - a.k.a. moving to a different planet, from the perspective of the NFV community. A big, unlikely change. Much more difficult than - say - changing terminology, and redefining some of the concepts used when talking about network software. 

Take "Virtual Machines" (VMs) for example. They represent a software version of a traditional hardware system, preserving the structure of its components and their suppliers - the eco-system. VMs increase the addressable market for the eco-system partners, as their carefully engineered solution can now easily be replicated and sold to an infinite number of customers, with minimal incremental cost or time. The physical constraints of hardware components are eliminated - or rather, someone else's problem, to be provided as generic resources sometimes called "cloud infrastructure".

The OS and other software components contained within the VM are "overhead", from the perspective of someone with the capability to take individual application processes out of those VMs, and host them directly on the underlying infrastructure. This is an eco-system layer that can be eliminated, to reduce cost (objective) and to achieve more efficient resource utilization (objective) - decomposing the VM into the sub-components that deliver its actual value ("microservices") provides increased flexibility and choice, allowing for more fine-grained optimizations.

The same OS and other software components contained within that VM form a familiar operating environment, for the organization running and maintaining those applications. There are well defined processes for upgrading to newer versions, adding more instances ("scaling out"), etc. When there are problems, a ticket is opened with the support organization of the VM vendor, who might pass it on to the OS vendor, etc. In summary, the operational processes for VMs are well understood and - considered - effective (objective). There are people assigned to these tasks, as part of a job that allows  them to make money and provide for their families (objective).

Now consider the transition from VMs to CNNFs. What would drive this transformation, which eco-system actors would benefit/be in favor, and who would be opposed?

Decomposing a VM into CNNFs is like taking a hammer to a mirror on a wall, disposing the frame and then scattering the pieces in various rooms around the house. The pieces are still physically there, but they no longer perform the function they were originally designed to perform, at least not in an effective and aesthetically pleasing way. And you might get hurt in the process - so why would you do this?

Vendor selection and component selection are both eco-system design decisions. The 'optimal' choice depends on many factors, things are inter-dependent and circumstances evolve over time. Each actor has their own definition of "optimal", relative to their own objectives. For a given organization and a given platform solution with hardware and software components, it may very well be the right time to move towards a more cloud-native universe. But it depends - what are the objectives, and how do they align with yours?

What a difference a plug-in makes

I work for Nuage Networks and we recently announced an integration of our Openstack Neutron plug-in with Oracle Linux and Oracle Openstack. A key question arrived via Twitter: What is so special about this plug-in?

First of all, plug-ins are a mechanism to provide different vendor specific implementations of the same basic functionality / interface. Openstack Neutron comes with a default plug-in and it provides a functional implementation of all the concepts defined in the Neutron API ( i.e. things like subnets, routers, ACLs, load balancing, etc. ). The Nuage plug-in replaces the default plug-in, and connects Openstack with our Nuage network policy engine ( VSD ) and control plane ( federated VSCs ).

To understand how the resulting system differs from stock Openstack, it is important to understand the notion of having a separate control plane - a key aspect of Software Defined Networking ( SDN ).
In traditional Ethernet based networks, switches decide the port to forward a given packet to based on learning. Each switch maintains a table with a mapping between MAC address and forwarding port; if a given MAC address has no mapping, the packet is flooded out of every active port until a packet with the MAC address as source is received. Due to limited MAC table space and ageing, there is a limit to the number of end points that can be supported with reasonable performance in such a network.

In order to build bigger networks like the Internet, routers were added. Like Ethernet switches, routers need to decide where to forward a given packet - but unlike switches, routers use separate protocols ( e.g. BGP, OSPF ) to exchange reachability information with other routers. This separate "control plane" replaces the "data plane" based learning process. It scales better than the Ethernet learning/flooding process, because each entry in the forwarding table represents a whole range of end points ( subnet ) and there is no flooding for unknown destinations.

With Nuage VSP, we build overlay networks that use a separate control plane ( based on standard protocols like BGP and OpenFlow ) for exchanging reachability information, for both L2 ( Ethernet MAC addresses ) and L3 ( Internet IP addresses ). This allows us to scale to large overlay networks that can span multiple data centres, and gives us the means to apply security and traffic management policies ( such as allowing/blocking certain ports, controlling which endpoints can communicate and on which ports/protocols ). We use an enhanced version of OpenVSwitch as the virtual switch/router in every hyper-visor, and OpenFlow to program each OVS instance.

The integrated system can be used in two ways: Networks can be created through OpenStack, or they can be created through the Nuage system ( VSD ) and "imported" into OpenStack. In both cases, VSD adds additional networking features to the resulting virtual networks, such as traffic statistics, QoS, advanced forwarding/redirection rules for service chaining, template-based policies, etc.
We can also connect physical servers and appliances to these virtual networks through software or hardware based gateways.

Standard OpenStack comes with a Neutron plug-in that integrates with OpenVSwitch too, however this configuration does not use a separate control plane, and it does not provide the additional functionality offered by VSP.

How SDN and NFV lead to prosperity and increased productivity

In July 2010 Matt Ridley did this wonderful TED talk which explains it all:


About 5 minutes into the presentation, he paraphrases an example first given by David Ricardo in 1817. Translated to software components and associated activities, individuals and organizations can benefit from cooperation and trade even if one company is better in all areas in absolute KPI terms, due to the comparative advantage.

For example: if a developer A takes 1 week to build a database back-end and then 2 weeks to build a web GUI for it, and a second, slower developer B takes 4 weeks and 3 weeks respectively, both can benefit by working together; the first developer can specialize in the database and the second in building the GUI. Even if we assume that parallel work is not possible and the database must be finished before work on the GUI can get started, by working together both developers can save time: for both projects, A spends 1+1=2 weeks on the databases, and B spends 3+3=6 weeks on both GUIs; both have saved a week of work, and can do more projects per year: increased productivity.

Of course, once developer A has done a couple of databases he/she gets better at it, develops or acquires some tools and scripts to speed up the process and may then only require 3 days for a new project ( and likewise for the GUI specialist ). This fundamental process of specialization or division of labour forms the basis for economic growth and prosperity.

So how does this relate to Software Defined Networking(SDN) and Network Functions Virtualization (NFV)? Most routers today are built as a combination of software and hardware; the software is provided by the same vendor that also produces the hardware. There is cooperation and trade with other vendors for the hardware and software parts ( e.g. using Broadcom chipsets, a derivative of some Linux distribution as operating system, etc. ) but the final product is closed - it can only be upgraded through the processes and designs of the original vendor. And because a typical router has an economic lifetime of about 5-7 years, an investment in a particular router locks an organization to the abilities and roadmap evolution of the associated vendor for a fairly long period, relative to the speed of innovation in telecom and the Internet.

SDN and NFV (the distinction varies depending on whom you talk to) decouple software from hardware, and allow those components to be supplied by different, specialized (eco-systems of) vendors. They enable a redistribution and de-composition of previously co-located integrated functions (software modules), leading to a further refined division of labour - not only in terms of who programs the software, but also who installs it, maintains it, hosts it, etc. etc. In other words, they fundamentally change the traditional value chain. And - under normal market conditions - this model will prevail over the traditional model, because of the more advanced division of labour and the associated gains in productivity. It represents the next stage of evolution.

Virtual fountains of Youth

Cloud is here to stay, and companies big and small are struggling to adapt. There is no shortage of articles with advice on what to change.

Organizations are living organisms. They are born, they grow and develop, they evolve to a certain size and at some point they dissolve (die) like all other organisms. The question is whether this is just me making fatalistic observations, or if there are fundamental laws at work which truly make these cycles inevitable.

The article referenced above suggests that telecom service providers should own their own destiny, by hiring people with knowledge typically found at vendors today. The thing is that telecom service providers are already full of smart people. The approach of outsourcing certain tasks and responsibilities to external parties is fundamental to achieving scale and sufficient focus on core activities, enabling telecom organizations to specialize and differentiate. To "beat" OTT players like Google and Amazon, trying to become like them isn't the answer. Those new hires would find existing organizational structures with barriers and limitations, most likely the very reasons why some of them left these old shells for newer, greener pastures in the first place.

I see a clash of generations, mature organizations versus relatively new players. Even though the average age of the people working at these organizations may not differ much, their management, structure and agility does. The younger organizations are somehow better adapted to embrace modern technologies known as "Cloud" or "SDN" or "NFV" today.

Is this merely survival of the fittest? Or can we find ways to fundamentally change our existing organizations - if so, what does this proverbial Fountain of Youth look like?

The Software Defined Enterprise

Increased online activity around  topics like Software Defined Networking (SDN) and Network Function Virtualization (NFV) shows revived market interest in the networking aspect of the { compute, storage, networking } triade that forms the foundation of distributed systems in general, and the Internet in particular.

To a large extend, these concepts are nothing more than rephrased expressions of existing ideas. Virtualization and abstraction are not new, and anyone claiming that they are has simply not been around long enough. Still, things are not the same today as they were before. So what is different, and why, and how should we adapt to cope with this new reality?

Clay Shirky sheds some light on this in his book "Here Comes Everybody". Technological advances like broadband Internet have radically changed the world we live in, and this both enables and requires new ways of organizing our activities. It does not matter how we call it - enterprises need to adapt their processes and the behaviour and mindset of their employees in order to survive, evolve and procreate. Herein lies the true value of things currently being discussed under the name of "SDN" and "NFV".

Over the next few months I'll be exploring this topic in more depth. For now, let's start with a name: I am calling it the "Software Defined Enterprise"

Fortune favours the Programmable : Stacking the odds with SDN/NFV

The Internet is full of benefits ascribed to either Software Defined Networking (SDN), Network Function Virtualization (NFV), or both. Improved flexibility and agility, reduced costs, higher profits - you name a benefit, and someone will tell you it is provided as a built-in feature. In fact, it is hard to find a benefit that is not associated with these latest hypes.

And yet - SDN/NFV isn't only a hype. There can be real substance behind these concepts, when implemented properly with actual code to support the claims. One example is something I am currently working on - a prototype which demonstrates a way to reduce average latency and latency outliers of web flows for highly scalable elastic applications, providing better control over service delivery and moving beyond "best effort" quality that is typical of today's cloud environments.

I call this "stacking the odds", and it fits my definition of SDN/NFV ( I prefer not to make arbitrary distinctions between the two - my prototype could be positioned as either or both, it really does not matter much from a technical perspective ). Unfortunately I cannot disclose any details at this point.

<Disclaimer: this blog reflects my personal thoughts, and is not related to my employer>

appTV - a vision for a new interactive TV experience

The world is evolving at an ever increasing pace, and companies and organizations are challenged to find new ways of delivering value for their customers. The traditional closed development model is no longer able to keep up and compete with the rapid innovation cycles of the Internet. A different approach is called for.

Cloud Media believes that open innovation and co-creation is the key to success in this brave new world. Rather than building closed, end-2-end systems which vertically integrate all required functionality, we should collaborate and combine components, modules and online services from many different companies and developers.

appTV articulates a vision for the future evolution of TV and IP video services in general. This market is characterized by high fragmentation and shifting business models, which makes it a very challenging and very relevant opportunity for everyone. The idea is to enable web-based interactive applications on TV and other screens. A cross-device TV app store model is proposed, to govern the innovation process and delivery of HTML based apps to the devices connected to the service.

So what? There are many more TV screens out there than PCs, and older generations and people in developing economies are more familiar with TV than with the Internet. By enabling access to simple Internet services on TV, we can connect more people to the digital economy, and help them engage in social networking and communication to enhance their lives.