Q&A—F5 Networks' James Feger: Elastic services need elastic pay models

gears
F5 Networks' James Feger says the adoption of elastic services will resolve some of the cultural issues that service providers face as they virtualize their services and networks. (Pixabay)

After moving over to F5 Networks this past summer, James Feger sees the telecom industry through a wide-angle lens that includes service providers and their enterprise customers.

During the 14 years he was at CenturyLink, Feger tackled specific projects, such as virtualization, for the telco. Now Feger is taking on a wider range of challenges for the industry at large.

FierceTelecom caught up with Feger, vice president and general manager of F5's service provider business, on the sidelines of last week's Light Reading NFV and SDN event in Denver after he delivered his keynote address.

FREE DAILY NEWSLETTER

Like this story? Subscribe to FierceTelecom!

The Telecom industry is an ever-changing world where big ideas come along daily. Our subscribers rely on FierceTelecom as their must-read source for the latest news, analysis and data on the intersection of telecom and media. Sign up today to get telecom news and updates delivered to your inbox and read on the go.

RELATED: F5 Networks' Feger: Simplify and reduce complexity for end customers

In August, F5 Networks announced the release of its VNF Manager, which was designed to simplify the deployment of virtual network functions (VNFs), and its "pay as you grow" pricing model that includes subscription and perpetual licensing options.

In this Q&A, which was lightly edited for clarity and length, Feger talks about consumption models and F5's VNF Manager.

FierceTelecom: You just spoke about consumption models in your keynote address. How do you build those consumption models?

James Feger: Well, the idea with the flexible licensing is we have almost like a matrix of options. You have your typical perpetual that can then be price structured for the service provider however they need; length of time, how they pay for it, when they pay for it and the terms.

Then you have what I call the more or less traditional models where you buy bulk licenses, which is "Hey, we want to deploy intelligent traffic management and we predict we're going to deploy a thousand of these for our customers over the next year. We need to buy a thousand licenses" and you can do that in a bulk scenario and then use those as you need to. Then, last what we've worked on is this idea that allows you to truly pay-as-you-grow and consume these licenses as you're creating the services.

You have a smaller cash outlay upfront before you turn on your enterprise customer, turn on your end user. We believe that that's probably one of the big barriers that have slowed down what I call the virtual service creation. We've solved a lot of the technological challenges, which we've heard in prior presentations (in the Denver conference) and the commercial models are still more difficult than they need to be. They are not as automated and they are probably more rigid. If we're talking about elastic services, you also need to have elastic pay models.

FierceTelecom: How does pay-as-you-grow fit in with the VNF Manager that was part of the same announcement?

Feger: The announcement that we made there was really a combination of the packages that I was referring to: Create a service and focus on outcome. The other thing that we believe the industry is asking for that nobody's really responded to is, "Look, we're trying to create a service for a customer, and that customer's just looking for an outcome and that outcome looks like X. How do I get there?" What we've worked on is the idea that says, "Well, we know X percentage of our deployments look and feel like this. What if we decided to just create that bundle or that standard package and couple that with our flexible licensing models, put it into a common management system and have that system actually scale and manage the infrastructure to make sure that outcome is always being achieved?"

Outcome can mean a couple of things. It could mean always have this throughput or always have this performance integrity, and you define those through the deployment rules and the system's constantly monitoring to make sure you're within those thresholds. If it's not, it'll automatically turn on more virtual instances to make sure you're achieving that performance. If you don't need that extra performance, it'll spin those things down and park them, so you're not consuming resources and burning power and creating heat when you don't need to.

FierceTelecom: If I'm an enterprise customer, how do I know what I need from a service provider?

Feger: The way I see this working, and again leveraging the idea of the world I came from, one of the things that we find ourselves engaging with our service provider customers on is, "Okay, you're trying to sell to some Fortune 500 company. You're trying to be the managed services provider, the managed network data partner for this enterprise company. What does that conversation sounds like?" They'll say, "Well, they're moving their services to the cloud or they're building new locations and they're distributing their traffic all over the world for geographic redundancy and we need to make sure that they are always on in the scenario of a failover." They have three times the amount of bandwidth in this location, in this hypothetical scenario.

Instead of nailing all of that bandwidth up 24 hours a day when it's not being used, we'll put the machine in charge of that and say, "If this site goes down, we need to make sure this site grows exponentially in terms of capabilities and capacity. Automatically do that for us." You build that rule set and the VNF Manager will then look at that infrastructure. It would detect a failure in site A, whether that is fiber cuts or some sort of catastrophic failure. It would then provision those new services and that bandwidth and that throughput and all the intelligent traffic management in that other location. It takes the guesswork out of capacity planning. It takes the guess-work out of managing the infrastructure.

I think that will help the adoption of these types of elastic services mostly because it helps overcome some of the cultural fears. Then, you go back to the skill sets and the changing personalities within the service provider community. They're rapidly trying to get to agile development and rapidly trying to bring in software-focused engineers and architects. As they're doing that, it's allowing them to put the (automation) machines in control of these services so the customer experience never changes regardless of what's going on in the background. It's always good.