Q&A—Red Hat's Brian Gracely talks NFV, containers and microservices

Despite being around for years, there's still a learning curve for network functions virtualization (NFV) according to Red Hat's Brian Gracely.

Gracely, the director of product strategy for Red Hat, spoke about some of the difficulties of carriers deploying NFV as well as the maturity levels of containers and microservices in this Q&A, which was edited for clarity and length. In the first installment, he spoke about open source and Red Hat's decision to double down on Kubernetes.

FierceTelecom: In a recent interview, Vodafone's Fran Heeran said the industry should spend less time focusing on NFV and more time on cloudification. What do you think about the current status of NFV, and where is it headed?

Brian Gracely: Well, I think there are couple parts to that. We've had a set of engineering teams that are focused on NFV at Red Hat. We're working primarily with OpenStack, so it's very much "How do we virtualize the functions, or how do we virtualize that software service?" You know, "How do we get it into a virtual machine so I'm not dependent on proprietary hardware?"

Brian Gracely, Red Hat
Gracely (Red Hat)

That's been relatively successful to a point. I think some of the telcos struggle a bit with trying to get enough bandwidth and network I/O out of an x86 box versus a custom built ASIC from a Juniper or from a Cisco or anybody else. That has been somewhat of a struggle, and that's the nature of purpose built hardware versus general-purpose hardware. But the level of "How do we turn what used to be hardware functions into software functions?" I think that's making good progress.

RELATED: Q&A—Red Hat's Brian Gracely on open source and doubling down on Kubernetes

I think that the flip side to that is when they get into sort of cloudification. There's a part of it where anybody in technology whose been working at it for a while sees the new stuff come along and they go "Oh, we should get out of this old stuff and go do the new stuff." Even in the NFV space we see people who are now questioning "do I stick with doing this on virtual machines or do I move this over to container technology?" because containers and Kubernetes seem to be sort of new and hot. That's more of the normal technology curiosity and the pace of technology.

The flip side of that is when they start saying "Well we should move our NFV to cloud." That's when we say "Well, what are you trying to do? Do you think you are going to be in the application software business? You're going to build new apps for mobile phones or something else?"

Now you're moving from just technology curiosity to probably preparing to be in that business, because that business is totally different from delivering network services, wireless services and security services. That's where I've seen some companies struggle, because they decide, "We would like to be somebody that we're not," and they don't realize how big of a jump it is to get to that other thing.

That's where technology isn't going to help then necessarily. Grabbing an open source project that's in that new domain doesn't mean you know anything about how to monetize that domain, right?

The technology can get you part of the way there, but one of the areas we see with the cloud providers and telcos and others is they would like the technology to move faster. They sort of ignore the learning curve sometimes.

It's the same challenge that every software company has. Like I said "Do you want to be in this business, do you want to go after this market domain?"

FierceTelecom: In another interview, Colt's Mirko Voltolini, head of network on demand, said he didn't think containers were far enough along to use them, and that VNFs should be designed with microservices in mind. What's your take on those thoughts?

Gracely: The original thing with VNFs was always, "We want to disaggregate the software function from the hardware function." And that's ultimately why people started with virtualization in that space, because they go, "Okay, I can still get the same software function, it's a load balancer, it's a proxy or whatever VNF function is, but I can run it on general purpose hardware."

If you look at the maturity level, virtualization has been around for more than 10 years now, probably closer to 15 years now. Containers have really been kind of a viable technology for less than five years. So for somebody to say containers aren't exactly where I want them to be, I think that's fair if you're comparing them to virtualization.

The pace of innovation for containers is moving really fast now because it's not tied to one specific vendor, it's not just tied to VMware, but I think we'll see that maturity of containers ramp up very quickly. So that's the part of his comment that's like "Hey, we want to disaggregate software from hardware."

The second part of your conversation with him is "I want to move to microservices," which is really a software development, application framework conversation. "I don't want to build one big blob of software/. I would like to take that one big blob and break it up into a bunch of pieces with the idea that I could work on each piece individually and collectively. We'll probably move faster than having all these dependencies on one big blob of software." And that's something that the industry is generally trying to get better at. For some customers, that's something they can deal with, they start from scratch, they start with a new application and they look at distributing it.

That's something that's very hard for a lost of customers to do if they take the existing application and then try and break it up. Because it either wasn't designed that way or those developers don't exist anymore, or they don't have access to the source code, or whatever.

I don't think that I would agree with them if they say "Hey, containers and microservices aren't ready for prime time or there's not enough tools around." It's a matter of getting your organization up to speed to be capable of using those things.

The reality is there's a learning curve to figure out how to use them, and that may be why they perceive that there's lack of maturity. But I think that the flip side of that is there are a lot of companies doing this already today. So it's not as if people aren't capable of doing it. It's just a matter of having the right skills, being dedicated to doing it and making it a business priority.