In NFV, Automation comes before Orchestration

Yesterday, I had to reject positioning a MANO vendor in a PoC due to the misunderstanding from the customer’s side. They thought MANO was about automation, as if it was a synonym for Orchestration. I believe they are not the only ones that may have some confusion here. After all, the list of software solutions that exist on this domain is too extensive, and they often offer aspects of both concepts: Openstack, Cloudband, Cloudify, Cloudforms, Ansible, Puppet, Tacker, OpenMANO, etc.

One may want to analyize the set of software tools available “to do stuff” and the level of abstraction that every software offers. Let me use a simple analogy, so you’ll understand what I mean by level of abstractions. Suppose you want to build a Caterham Superlight, a sports car that you can either buy assembled as any other car, with waranty, from a manufacturer, or you can build it yourself, as a Kit Car.

In NFV, most telcos prefer to build their solutions integrating pieces from different vendors, so they don’t pick a fully-packaged solution (see what happened to HPE at Telefonica UNICA). If you choose to build a Caterham on your own, you can choose different approaches:

  1. Pick your favourite toolbox, open the cardboard boxes, and start assembling the car piece by piece using soldering machines, screwdrivers, nuts and bolts.
  2. Get a robotic arm, which requires a special program customized with the information about the car components. The arm will do some of the work for you with the tools from your toolbox, or other advanced tools designed to fit the robot’s hand. You still need to bring him the components and he’ll assemble them and move the parts around.
  3. Design a full-fledged factory line with a moving processing line surrounded by multiple robotics arms sit around the line, and they use tools to assembly the parts as they pass by. The parts must be put in pre-defined areas so the robots can pick them up. The production line has enough sensors to show if everything is OK, but when not, it must offer the option to the Operator to intervene, troubleshoot and repair the components.


Now that you understand these three approaches, now consider a NFV project composed by infrastructure, cloud software, management tools, automation, service orchestration, policy engines, OSS/BSS, VNFs and their managers, etc.

  1. The tool level includes the Cloud Operating System in the NFVi layer. It’s the set of buttons and APIs that execute actions and give a return code. Like a hammer on a nail, it can hit it right on, miss it entirely, or bend it. They provide feedback about the executed action, but that’s it. It’s not the hammer responsibility to remove the nail if it was bent or if the hammer missed the nail. That’s you, the SysAdmin, the hammer user.
  2. Next comes the automation level, including the VIM and the VNF-Managers, as well as internal components that can be not so visible like scripts/recipes in Shellscript, Puppet or Ansible. It’s about taking a well-known process and making it automated so a machine can do it for us. It cannot innovate and rarely can take decisions on its own. Basic “if-this-then-that” rules can be implemented, and that’s often referred in IT as “orchestration” although in NFV it’s too basic to deserve that title. You should only automate those actions that you have previously mastered doing manually.
  3. This leads us to the orchestration level includes Policy Definition and Enforcement, descriptors for Service Definition and function chaining, all part of the top MANO components (NFV-O), This is like the manufacturing floor plant above, and the keyword here are policies. A policy it’s a written rule that sets an ordering criteria (where do we put the parts), a set of levels and KPIs that indicates if everything is OK or not, and a predefined set of actions that need to take place when those levels are not reached, the most basic being a “Halt the production line when something is wrong”. Pick your orchestration in function of the automation tools that are more productive for you, and make sure you can define the orchestration rules in a language that suits your business needs.

When a process has reached the level of maturity of the orchestration level, you can then consider further Quality Improvement techniques that will collect statistical data, Using historical data, you can apply many methods to detect bottlenecks, identify sources of failure and improve the productivity of your systems. Best-practices such as ITIl, eTOM or ZOOM, are the red tape required to allow the controlled change in procedures/tools in a way that never disrupts the business and keeps improving over time.

If you are curious about those steps, you can read more about six-sigma and CMMI and you’ll see the equivalence by yourself.

In conclusion, in an NFV project (as well as any other IT architecture) , do not put the cart before the horse. You should only automate those actions that you have previously mastered doing manually. Pick your tools carefully, master them, before engaging in any Automation project or purchasing Orchestration solutions that have nothing to orchestrate yet.


Comparing Openstack vs AWS to Tesla vs Edison

After reading this article I realized the current situation between AWS (public cloud) vs Private cloud (IBM/Cisco/HP/Dell-EMC) is very similar to the Electricity landscape in mid-1800’s ending in the War of the Currents in late 1800’s (AC vs DC)

Let me explain my point in this analogy: before electricity was discovery, manufacturing used natural power (water, air and animals) to create movement that was transferred inside the factory to help process goods using belts and chains. When electricity appeared, an Electrical generator was used as a power source, copper cables transferred electrical power to machines, and increased productivity and the density of workers, with reduced maintenance for the machinery.

So eventually every factory had its own coal-powered electrical generator (i.e. x86 servers nowadays), and line workers used their machines (i.e. computers) that required the energy that came via the copper wires (i.e. internet or VPN access).

Then the Power Grid was invented, and the industry wanted to shutdown their small electrical generators and leverage the bigger power grid. Outsourcing servers to AWS (public cloud) is like connecting the factory to the power grid (public electricity), but there were no standards for that in late 1800s, hence the Edison (DC) vs Tesla (AC) war.

In this case, Amazon is Edison, the greedy inventor, with lock-in in his veins (DC was patented). Tesla is Openstack, a generous inventor with open APIs and specs to build your own special sauce on top of a good-enough standard (60Hz, 110V, but easily changeable to 50Hz, 220V)

We’re seeing the struggle of Industries outsourcing their power generators and connecting it to the grid (i.e. the cloud). But there is the Monopoly way (Edison), and the Open way (Tesla)

Let OpenStack be the Tesla here, it will help the ‘Tech Giants’ to fight the good battle (Interconnected Private clouds using Openstack) and provide better services to the Industry.

Marcos Garcia, an OpenStack enthusiast