Level 3's Ewert: Look to Cloud for NFV Models

The answer to NFV transformation may not be blowing in the wind, but it is blowing in the cloud, says Travis Ewert, senior vice president of network software development at Level 3 Communications.

Telco Transformation interviewed Ewert on effective NFV transformation initiatives. In part one of this Q&A -- edited for length and clarity -- Ewert talks about what organizations working with, or moving, to NFV can learn from cloud models while strongly advising that NFV engineers to stop treating their servers and other boxes as beloved "pets."

In part two, look for Ewert to delve more deeply into the cultural aspects of NFV transformation, particularly where NFV automation is concerned.

Telco Transformation: For an organization that is looking to get started with its NFV journey -- or even if it's just looking to reevaluate it -- what is the first step?

Travis Ewert: I guess first and foremost look at your operating model. I'll answer this from the vantage point or perspective of the service provider -- that traditional service provider who's very much leveraged a black box model. Going from that black box, look at how you connect the traditional dots by way of how you build that network. Then go with a model that is more cloud-centric, leveraging virtualization principles. Probably the first big change is that there is a recognition that all of those architectural engineering design/development and other principles have to change.

That being the case, the first piece is a recognition that you have to build to more of a modern-day depth principle. I try not to use the buzzwords because, frankly, a lot of our industry buzzwords bother me because they're just used too much. But, for the purpose of this one, I recommend building to more of a microservice-type of model, an approach that is more segmented. Whether that's on the hardware side of things -- where right now we're decoupling things and doing it ourselves versus the black-box solutions -- or even on the software side -- where we're building things in layers or in frameworks that have reusable components that we'll wrap APIs with to be able to make use of in a new way -- that's a big one.

Also important is just that culture or mindset of building for simplicity, or standardization -- leveraging cloud architecture and cloud principles. That's where virtualization, containerization and other related things become key. So there's a software methodology piece to it, there's a hardware methodology piece to it and then there's even some reference to "How you standardize to make everything look the same?" That's the beauty of a white box server type of architecture. You can make it all look the same, manage it all the same, and then, yes, the boxes may have different personalities for different functions.

TT: You mentioned how you don't like to use a lot of buzzwords, and how too many people use them in the industry, and then they don't mean anything. Specific to NFV, what buzzwords or "buzzterms" are you seeing used too much, what's being overhyped and where's the real beef when it comes to NFV-based transformation?

TE: Well, I think NFV's probably the best or worst example of too much hype. Probably the more important reference is that of network disaggregation. Because the virtualization of a function is just one of the many choices that's really impacting this industry both by way of opportunity to build networks differently and provide a different customer experience, as well as the cultural impact, operating model impact, impact to the operation, etc., around how you build it and then support it in day two.

TT: What about culturally? What needs to happen organizationally, politically and culturally to move forward with NFV?

TE: One of the biggest ones is just overall acceptance of, I'll call it, a software culture -- one that reflects frequent changes and more of an iterative approach. If you go look at the traditional model, it's long release cycles, whether it's on the infrastructure side of things where you don't update or touch things very often -- and when you do it's a very heavy-handed, big-change review-board approach with lots of eyeballs -- versus the cloud guys, where they may be making changes every hour or multiple times an hour all day long, and do so in a way where they can put something out there and revert back or pull back if need be in quick order. Even just that is the first big cultural change.

Probably the other big one is, I call it, "How do we get away from that end-to-end methodology or mentality?" Sometimes they even call it the "hero effect" -- meaning that, you have, for instance, that technician, that super tech, who's the best tech because he can figure it out end-to-end. He understands from a telco network perspective, "Here's the access piece, my metro ag, cross core here," and he understands every piece. Whereas if you look at it in this new world where things are componentized, where you may have microservices, that culture moves from end-to-end know-it-all to someone who's a best in that individual domain. How you can bring that together, for us, personally, is a big change.

One popular blog post by Randy Bias on "Pets vs. Cattle" (a more updated version of which can be found here) really came out of cloud architecture vernacular. The reference to "pet" is to traditional networking -- where it's Bob the mailserver, or it's the Dallas-Fort Worth Ag router, or pick your examples -- where you manage that asset with special, unique love and care, feeding, maintenance. I joke about the name, but, literally, you go back not that many years ago where there are named elements, that technician knows it by name, takes care of it individually -- versus that of cattle, cattle being they're all the same. They may have a number. One may fall off the line; you just replace it. You do so in a way that availability or even high availability is not a one-for-one or active/active; it's just in the line that falls off. You didn't notice it by way of traffic impact. Frankly, a lot of that methodology we built into our CDN.

How do you move culturally towards that approach where it is a more genericized infrastructure and do your best to make it all look the same? Because once you've done that, that's when you can truly standardize. So it's an endorsement by everyone -- senior leaders down to those individual contributors -- of those core principles around how you build networks and how you manage them, etc.

Related posts:

• BSS/OSS: Level 3's Ewert Urges Cloud Centricity for Better Systems
• This Year's Model: Programmable Functional Disaggregation
• Level 3's Ewert: Why Network Disaggregation Is Key

— Joe Stanganelli, Contributing Writer, Telco Transformation