Cloud-native and DevOps are terms we hear a lot lately. Businesses using these types of tools can generally innovate and deploy faster. That is what agile, digital business is all about. But some businesses using cloud-native and DevOps tooling have networks stuck in a monolithic, legacy time warp. This could stymie the pace of application development and deployment.

To move at full speed, it’s crucial to bring the networking operations teams into the DevOps chain, according to Dominic Wilde, chief executive officer of SnapRoute Inc. “The DevOps teams are responsible for time-to-service for the application,” he said. “And that’s really the value of the organization.”

This is why network operations teams don’t win a lot of popularity contests in companies.

Wilde sat down with John Furrier for a CUBE Conversation at theCUBE’s studio in Palo Alto, California. Glenn Sullivan, SnapRoute co-founder, and Adam Casella, SnapRoute co-founder and chief technology officer, also spoke with Furrier in separate interviews. They discussed how cloud-native tooling brings networking into the agile DevOps age. (* Disclosure below.)

This week, theCUBE spotlights SnapRoute in our Startup of the Week feature.

Networking naysayers

Traditionally, network infrastructure has been brittle and easy to throw out of whack. Often, it’s the network team that says “no” to new agile information technology initiatives, because they don’t want to break anything.

For DevOps teams to blame networking teams for the situation is unfair, according to Wilde. “The problem is with the the vendor community. We haven’t been delivering the tools that enable them to deliver the services they need,” he said. 

Those much needed tools are what differentiates SnapRoute’s networking technology. The four-year-old startup has built a new network operating system from the ground up. It is a fully containerized (containers are a virtualized method for running distributed applications), microservices architecture. It embeds Kubernetes — an open-source, container-orchestration platform. These cloud-native technologies break the network into more manageable agile pieces.

“It allows networking for the first time to be brought natively into the DevOps toolchain,” Wilde said.

Watch the complete interview with Dominic Wilde below:

SnapRoute was conceived in the minds Sullivan and Casella when they worked as networking engineers for Apple Inc. They remember the daily networking grind well.

When anyone in the IT organization wants to try something new, network folks’ answer is typically, “Not in my backyard,” Sullivan said. It isn’t because they’re jerks; they just want to keep their jobs.

“They’re not judged by how quickly they can put a new feature out or how how quickly they can roll an update,” Sullivan explained. “They’re literally judged in most organizations by uptime — how many nines are they giving.”

Anyone judged on network uptime and application availability is going to be gun-shy, no matter how attractive the proposed change.

Watch the first part of a two-part interview with Adam Casella and Glenn Sullivan below:

DevOps and networking in tense tango

Digital consumption models are giving application availability make-or-break weight. A bad app is flat-out bad business nowadays. What do consumers do when an app is down, slow or annoyingly glitchy? They go to the app store and download a different one.

The end-user experience is where DevOps and networking operations enter into a frustrating, stop-and-go tango. DevOps’ speed of app development, upgrades and deployment — good; that same agile movement knocking things around on a fragile network — not good.

The Cloud Native Computing Foundation recently surveyed enterprise and DevOps professionals. It found that “production usage of CNCF projects has grown more than 200 percent on average since December 2017, and evaluation has jumped 372 percent.”

Clearly, the benefits cloud-native tooling brings to DevOps are too good for companies to pass up. How can companies bring their networking up to DevOps speed? The answer, quite simply, is that they need a whole new kind of network — a cloud-native one.

“You try to take a monolithic network OS and put it into [continuous integration/continuous delivery] pipeline, you’re going to be pushing a rock up a hill,” Sullivan stated.

Tech is on a trajectory where IT components are becoming more and more ephemeral, according to Sullivan. The lifespan of monolithic apps is about four years; virtual machines last 23 days; the average container lasts about two or three days. The network now has to have the ability to react to that without breaking into pieces.

So break it into pieces — with cloud-native containers and microservices.

Watch the second part of a two-part interview with Adam Casella and Glenn Sullivan below:

Is cloud-native ready to eat SDN?

No new management tools are going to get the network cloud-native and DevOps ready, according to Sullivan. The solutions that have come out over the past eight or nine years for networking and open networking all have this fatal flaw, he added. They’re trying to solve this from a management perspective with different software-defined networking profiling, etc.

“Our core argument is, the management layers on top aren’t what needs to change,” Sullivan said. “You need to change the way the network OS itself is built so that it’s not so brittle, so that it’s not so fragile.”

This is accomplished through breaking it into microservices and containers. Then, and only then, is it feasible to put it into a CI/CD pipeline.

This brings networking into the DevOps tool chain for the first time, according to Wilde. NetOps teams still control and define network policy. But they don’t have to worry so much about DevOps engineers breaking something when they make trivial changes and  deploy applications onto the network, he added. 

Kubernetes builds NetDevOps bridge

It simplifies networking and gives everyone involved fewer protocols to worry about. Whittling down procedures and protocols is how some of the most overworked networking teams on earth stay sane.

“Places like Facebook, places like Google — we know that they’re saying the fewer features I have running, the simpler my environment is, the easier it is to troubleshoot, the less that can go wrong,” Sullivan said. “It’s all goodness to run less, so if you give people the ability to actually do that, they have a substantially better network.”

Photo: SiliconANGLE