By Matt Micene
Networking in the cloud is a rapidly changing area as new concepts, technologies, and standards continue to emerge and mature. To learn more about the landscape, we caught up with Valentina Alaria, head of product and solutions marketing for PLUMgrid, a cloud networking provider.
Alaria has over ten years of experience with cloud and datacenter infrastructure and has been involved with SDN and OpenStack since the early days. Throughout her endeavors at PLUMgrid, Nicira, and Cisco, she has held roles across engineering, product management, and marketing.
As part of the OpenStack Live conference next week in Santa Clara, California, she’ll be delivering a three hour tutorial on OpenStack networking architecture and concepts, along with her colleague Faan DeSwardt. Read more in this interview.
SDN, NFV, VNI: OMG!
There are a lot of acronyms in the space. Can you give us some clarity on the differences? What’s important for a beginner to understand about each one?
Great question! And, you are absolutely right: There is a whole new world of acronyms, and readers can get lost pretty easily. The way I like to break it down is like this:
- Software Defined Networking (SDN) was the first transformational paradigm change of separation of control plane and data plane and the ability to define, drive, control, configure the network in software. The initial concept took form in a variety of implementations with overlay networks (pure software play which decouples virtual and physical infrastructure via some form of tunneling technology) and fabric controllers (an SDN controller actually manipulating the physical switches, often via the OpenFlow protocol) being the two major incarnations.
- Virtual Network Infrastructure (VNI) is a term that very effectively conveys the transformation of the network becoming now a virtual resource that can be consumed as easily and effectively as virtual compute. We at PLUMgrid use it to describe our software-only solution for large-scale cloud deployments.
- Network Function Virtualization (NFV) is well defined by ETSI Architecture, but the way I like to break it down for customers is that NFV is a whole new world of use cases, and a true transformation of how all network functions that used to be hardware-based can now be delivered and consumed in software. SDN and VNI can be considered building blocks that are leveraged in a broader NFV solution.
How did you get started with OpenStack as a platform? Open source software in general?
I was lucky enough to start my journey with OpenStack (and OpenFlow) many years back—way before it all became popular. Back in 2008, I worked with a team of people on the very first OpenFlow demo. In 2011, my product back then was integrating with OpenStack and I just simply went ahead to give it a try and see what I was putting my customers through and learn how they would use it. It was still a bit rough at the edges, but it was starting to show the promises of what it then became.
Looking at the OpenStack community and the amazing growth and incredible applications people are building on top of it really shows the value of a community of talented individuals coming together, and vendors bringing the hardening and support needed to make it an easily consumable product
Read this: Lorem ipsum dolor article
At the conference, the Open Networking Users Group (ONUG) has a track called, The ONUG Great Debate: Closed vs Open Source Software. I have worked with vendors on both sides, so I wonder where you weigh in on open versus closed? How does working in open source compare with your work in architecture and research?
The power of the community is what makes open source initiatives extremely powerful and transformational—like OpenStack. On the other hand, I do work on a daily basis with customers and see their pain in taking that innovation and technology and adopting it in their environment. The power of OpenStack (as an example) is actually greatly amplified by the ecosystem of vendors around it that look at important aspects like support and hardening as well as augmentation of specific aspects (e.g. scalability and performance) that are needed in production environments. It is really a combination of the two that brings the most value to customers.
In my opinion, networking plays a large role in the idea that “there is no such thing as vanilla OpenStack.” How can this experience be made better for the people who need to build an OpenStack cloud?
Interestingly enough, networking was the number one concern for those users that took the most recent OpenStack Superuser survey. Networking is the core, the junction, of any cloud that is built, and plays a critical role in making a solution production-ready, scalable, and capable of growing with the requirements.
OpenStack provides a consistent framework to consume networking (Neutron) and a fixed set of APIs. The beauty and power of the model is its modular architecture, and the ability for each customer to select the backend that best fits his/her needs. They can start with the reference implementation and then as their needs exceed what the default OpenStack can support they can select the best possible solution on the market.
As a vendor that has a Neutron-plugin, I appreciate how Neutron keeps the consumption model consistent while at the same time allowing for innovation and extensions to satisfy the most stringent requirements and use cases.
The identity of a cloud system admin and networking engineer is changing. What is the new role and skillset?
It certainly is a big transformation for the network engineer who used to deal with a pretty static network infrastructure and is now catapulted in this realm of on-demand, all software, distributed systems. At the same time, if you dig behind the surface, there is still lots of old-school, traditional networking constructs wrapped with a whole new level of agility.
I have been training customers on SDN, VNI and OpenStack networking for many years now and I certainly see a need for more understanding of Linux and Linux networking and a software mentality. What is amazing, though, is to see how easily the most hard-core CCIE can transition from the hardware world to the software world and once they grasp the reach of the new model, how they can start designing networks in a completely different way.
The new cloud network architect plays a fundamental role. He or she is responsible for one of the most critical building blocks, starting from the right physical network infrastructure design up to a virtual network layer that can be easily consumed by users of the cloud.
Automation is one goal for software defined networking, but what are some of the other benefits of driving physical fabric from a comprehensive software layer? What are some of the concerns with the critical nature of physical fabrics supporting virtual ones?
Automation and agility are certainly key drivers. When a customer can cut down by 70% or 80% the setup time for a new cloud user, that is certainly a key success.
Mapping cloud use cases to physical network infrastructure is often simply not possible. The user of the cloud has the steering wheel and they want a strictly secure, isolated environment. They want to be able to create their own application environment, on-demand, same as they create a virtual machine.
Scalability and performance are also fundamental. Being able to create network functions and services in a distributed software layer enables thousands of users to effectively share the same infrastructure with all the changes and churn being contained in the virtual layer.
The physical network becomes simpler to design and maintain, built for speed and resiliency and with minimal changes (to minimize potential outages).
