Steve Saunders sits down with RIFT.io CTO Matt Harper to learn how a bunch of telecom veterans are tackling the core issues behind NFV.

Steve Saunders, Founder, Light Reading

October 3, 2017

12 Min Read
Q&A: How RIFT.io Takes Automation Carrier-Grade

I've been spending a significant amount of 2017 getting my head around automation, the next big wave of communications. One of the things that I discovered is that, in addition to the incumbent vendors, there are about three dozen new companies targeting this space with various pieces of the automation puzzle (You can read about them here.)

But one of those companies isn't really new at all. RIFT.io has been working to crack the automation nut since way back in 2013. In other words, it saw the opportunity really early, and has a significant lead over pretty much everyone else.

It's not just the fact that it has stolen a lead on the rest of the industry that makes RIFT.io stand out. Its product -- basically, automation middleware that sits between everything else on the network -- is also noteworthy, because it's open, interoperable and carrier-class. That sets it apart from pretty much all of its competitors, who tend to boast two of those attributes, at the most.

I think the reason why RIFT.io has gotten so much right with its approach probably comes down to its founders -- who are drawn from the ranks of some of the most successful telecom companies ever launched. In other words, this is a carrier-class product, not something grown out of a data science class.

The big question now hovering over RIFT.io is when it will announce its first customer. Four years is a long time to work on something without announcing a contract. The answer? "Pretty soon," according to Matt Harper, the company's eloquent CTO and founder, whom I sat down with recently.

Figure 1: RIFT.io's Matt Harper RIFT.io's Matt Harper

Read on for Matt's detailed account of what this important and significant company is up to.

Steve Saunders: Hey Matt.

Matt Harper: Hey Steve, I'm really happy to meet you. I've been a Light Reading reader for, wow, almost 20 years now.

Saunders: Thank you. We appreciate that very much. The reason I wanted to chat to you is that RIFT.io seems to have placed itself right in the path of the direction that the whole industry is going in at the moment -- automation -- but you managed to see the opportunity super early. Can you tell me a little bit about the company, and how you got to this point?

Harper: Sure. RIFT.io was started by people from a carrier background. I was one of the early people at USRobotics and 3Com. There's people here that worked at Redback -- which built some of the biggest broadband subscriber management systems. Then there's lots of the key people that started Starent Networks, and built the first carrier-class wireless access gear.

All of us saw that there was a migration happening, and we knew that carriers were really struggling with a fundamental shift. The carrier guys were looking with envy at the Amazons, and Googles, and Facebooks. They were basically running scalable, over-the-top (OTT) cloud services. Telcos, on the other hand, were building true carrier-grade networks. And the big difference was that the OTTs were piecing their networks together with third-party components rather than being able to do what Amazon and Google and so on were doing, which is to build their own infrastructure.

Very different approaches, OK? And the carriers, I think, realized that if they didn't change their economics to be more in line with the over-the-top players, then they'd either become irrelevant or just get gobbled up by these guys.

And an interesting thing here is that many of the products that we've built in the past [for the carriers] were actually cloud-based products. They used x86 processors, and they had complex networks inside of them, and they were highly elastic. And all that capability was wrapped up inside of an appliance that we sold to the operators.

Then along came NFV, and we realized that some of the essential components were in place for it to take off: x86 processors were available with features that allowed them to act as NPUs [network processing units]; the ability to control Ethernet switches at a fine-grained level was emerging; and you also had the arrival of commercial cloud VIMs [virtualized infrastructure managers] from VMware.

So those things were happening, but there were a couple of areas that we saw as equally critical that weren't being well addressed -- and it's those areas that we chose to focus on. One of these is automation.

Harper [continued]: A lot of people actually call this "orchestration," but, really, what is orchestration? It's model-driven automation. In the web world, things are automated just by writing scripts. But the real problem with just writing scripts is you end up with islands of functionality that don't play well with each other. If you're writing them all yourself, like an OTT, that isn't a big deal, but if, like a carrier, you're building your network out of components developed by other companies, you want a model to make these things plug together. We saw a real weakness there, and we chose to focus our efforts on solving that problem.

The other area that RIFT.io saw as needing work is the ability to write scalable and carrier-grade VNFs, or distributed VNFs. We tackled this one by creating a toolkit for building distributed VNFs -- with distributed control plane, distributed resiliency and distributed data plane. And we also used that toolkit to build our scalable orchestration subsystem.

One of the other key things we realized right from the beginning was that in order to make this whole ecosystem work, it couldn't be a closed, proprietary solution. We started the company from day one knowing that we were going to open source the solution and give the control of this technology to the operators and the service providers, because that was the only way they could gain the economics that they needed to compete.

Saunders: Are you targeting service providers, or enterprise, or both?

Harper: Primarily service providers, but the technology that we've built is also very applicable for high-end enterprise.

Saunders: Right. A lot of them see themselves as service providers now, don't they?

Harper: They really do. When these guys are at scale, they're doing the same things the service providers do. You look at some of that the biggest companies in the world like FedEx or UPS, these guys run significant transport networks. They have the same exact platforms as the carriers.

What's interesting is that high-end enterprises have been some of the earliest guys to adopt an orchestrated model, and the use case that they used was SD-WAN, but very, very basic versions of it; things like building transport networks. Generally, they've purchased proprietary closed solutions. There weren't open solutions for this. I think that they gained some experience about what is required in terms of key capabilities. They're ready to take the next step and saying "Wow, this would be a lot better if we had an open ecosystem where we could pull in what used to be physical appliances as virtual appliances."

Saunders: Have you announced any service provider customers?

Harper: We have not announced any publicly that we're in production with yet.

Saunders: Right. What's the timeframe on that?

Harper: Pretty soon.

Saunders: So for now, where is the funding coming from?

Harper: Our primary announced backers, both of whom are really aligned with our vision, are Intel Corp. (Nasdaq: INTC) and North Bridge Venture Partners .

Saunders: Who do you see as your main competitors right now?

b>Harper: In the orchestration space, there's a number of established players who have proprietary solutions. Guys like Hewlett Packard Enterprise , Ericsson AB (Nasdaq: ERIC), Cisco Systems Inc. (Nasdaq: CSCO). The reality is while they may have solutions that work really well with their own VNFs, they're not really an open solution that works well with third parties.

On the open source side of things, there's really only one competitor, and it's ONAP. It has a nice collection of companies that have announced they are supporting it, but it's significantly behind where we are in terms of functionality and maturity.

Saunders: Their big thing is how much code they've developed, which seems almost counter-intuitive -- that having a lot of code would be a good thing today. How do you compare in terms of functionality and stuff like that?

Harper: In terms of functionality, the systems are actually relatively close. I think there's some areas, such as orchestration, where RIFT.ware is significantly more advanced and more capable. That's why ONAP is integrating OPEN-O -- in order to gain some of the capabilities they're lacking. [See OPEN-O, ECOMP Combine to Create ONAP.] So they are fairly comparable, but we are built completely around a unified model -- a microservices architecture. That radically simplifies management and explains why means we use less code.

Saunders: I think most service providers would say that having eight million lines of code [this is the number of lines of code in AT&T's ECOMP, which is part of ONAP] is not a good thing.

Harper: It's a terrible thing. The less code the better.

Saunders: Your product seems to occupy a space between the incumbent equipment manufacturers and the service providers, who are fed up with waiting for the incumbents to deliver what they promised, and are trying to do it for themselves using ONAP. So you're a new category: "automation middleware," by which I mean everything which you need in order to virtualize and automate a network and its services, in a heterogeneous environment, and designed for open interoperability. Is that a fair description?

Harper: I think that's accurate. A couple of things really make us different from the incumbents. One is that we're not encumbered by also selling VNFs, and so we're not in the business of forcing you to also buy our VNFs when you buy our orchestration system. That's a big difference.

Another one is that by having the majority of our [code] in open source, we give customers a lot of confidence that the operators can contribute to it, that they're getting best of breed, and that they're going to benefit from the open-source community.

Now, if you look at a solution like ECOMP, you have to wonder: AT&T spent this tremendous amount of money on developing it. If that investment had been successful and they'd built the silver bullet that solved all their problems, and nobody else had it, don't you think they would've kept it to themselves?

I think they learned that it's not in their interest to build this whole thing themselves. They actually want to have a community, because the only way that automation can be solved is by a community.

I think most of these service providers have figured out that if the choice is build versus buy, then, really, they should be in the "buy" camp. They want to buy functionality that's best-of-breed, the best-of-breed VNFs. Same thing with their operating systems, and their VIMs, and their orchestration systems. They want to be able to go out and buy these things that are best-of-breed. If you go and look at something like ONAP, nobody's going to go get the open source version and run it. They'll go to Amdocs Ltd. (NYSE: DOX) and get a commercial version of it, just like with OSM [the Open Source MANO Community (OSM) community, built on RIFT.ware] people come to RIFT.io.

Saunders: OK, so to be clear, versus an Ericsson, or a Cisco, or a Nokia Corp. (NYSE: NOK) -- they have a story that they are building out around automation, but a customer is still having to buy the whole stack from them, right?

Harper: You are. You're buying the whole stack. What these guys are doing when they actually go into service providers is they're actually just selling islands of functionality. They're really selling virtualized appliances. They're not being deployed as a carrier-wide orchestration subsystems that work across everything.

Saunders: Islands of functionality. You would work to unite those islands. Is that what your platform would do?

Harper: Oh, absolutely. That's actually the problem we solved for carriers. We're the Switzerland that make all these things work together. We have the model that allows these elements to work across boundaries.

And by not actually competing in the VNF space, it allows us to have a really good working relationship with all the really key players that the service providers want to buy from.

Saunders: It's a strategic position, no question. I've noticed that a few other companies are now trying to occupy this middleware middle ground. UbiQube. EnterpriseWeb. [See The Autonomous Network Is the Endgame for Telecom and EnterpriseWeb: Early to NFV, Finally Ready for Take-Off?]

Harper: Sure; Kubernetes is another. There's also Cloudify. There's a lot of companies that are coming at this from the web side of things, or from the public cloud side of things.

The issue is that they tend to be weak is in a couple areas. One is network modeling. They're actually really good at deploying applications, but when it comes to actually building the networks, connecting things up, and controlling how data moves amongst those things, and doing optimized deployments, they're weak. And the other thing is that they tend not to have a complete model for manageability. They may provide limited northbound APIs, but they haven't gone in and built a telco-grade management system or telco-grade redundancy.

The other thing that I'd say is that it's important for anyone delivering solutions in this space to have service provider DNA in their company. If you don't, you can't understand the requirements of the carrier customer, and you probably will get pretty frustrated with their decision cycle because selling an enterprise might be a three- to six-month sale cycle, but selling to a carrier traditionally is a 12- to 18-month cycle. So much bigger deals, but also a much more complex sales cycle and a much more complex product.

— Stephen Saunders, Founder, Light Reading

About the Author(s)

Steve Saunders

Founder, Light Reading

Steve Saunders is the Founder of Light Reading.

He was previously the Managing Director of UBM DeusM, an integrated marketing services division of UBM, which has successfully launched 45 online communities in less than three years.

DeusM communities are based on Saunders' vision for a structured system of community publishing, one which creates unprecedented engagement among highly qualified business users. Based on the success of the first dozen UBM DeusM communities, the UBM Tech division in 2013 made the decision to move its online business to the UBM DeusM community platform – including 20 year old flagship brands such as Information Week and EE Times.

Saunders' next mission for UBM is the development of UBM's Integrated Community Business Model (ICBM), a publishing system designed to take advantage of, and build upon, UBM's competitive strengths as a leading provider of live events around the globe. The model is designed to extend the ability of UBM's events to generate revenue 365 days of the year by contextually integrating content from community and event sites, and directories, to drive bigger audiences to all three platforms, and thereby create additional value for customers. In turn, these amplified audiences will allow business leaders to grow both revenues and profits through higher directory fees and online sponsorship. The ICBM concept is currently being discussed with a broad group of business leaders across UBM, and is earmarked to be piloted in the second half of 2013 and early 2014.

UBM DeusM is Saunders' fifth successful start-up. In 2008, he founded Internet Evolution (www.internetevolution.com), a ground-breaking, award-winning, global online community dedicated to investigating the future of the Internet, now in its fifth year.

Prior to Internet Evolution, Saunders was the founder and CEO of Light Reading (www.lightreading.com), Heavy Reading (www.heavyreading.com

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like