top of page


Nile Shakes the Network Infrastructure Tree


Guy Brunsdon

24 September 2022

Nile emerged from stealth last week. Why am I excited about their approach?

The news of Nile Secure emerging from stealth last week hit me from several angles. First, I was surprised at ex-CEO of Cisco, John Chambers, and ex-EVP Pankaj Patel heading up a company taking dead aim at their old company and other incumbents. Still, another part of me let out a quiet cheer that someone “got it” in understanding the purpose of a network is to run a network service for the business.

Let me explain.

The Origins of My Perspective

I drifted into building and operating enterprise networks early in my career. As a fresh graduate at my first employer, I stuck my hand up when the network guy departed. I was ordained as the network guy. While I made the original career choice into "computers" because I was essentially a geek and loved the tech, a few outages and network performance issues drummed into me that the core functional job of the network (and hence my job), was to deliver a network service to the business. My metrics were performance, availability, resilience, serviceability, and security (admittedly, there wasn't much security back then). That's what mattered.

When I made the leap to IP networking and eventually became a chief architect of a national enterprise network, my metrics didn't change. The underlying technology and solution had changed from SNA to IP, but the metrics by which the network and I were judged, had not. It was still performance, availability, resilience, serviceability, reach, and security. My job and that of the network had remained stable over time, while the technology had changed (a lot!). Fast forward to today, the technology has evolved and become incredibly complex, but the job of the network and its operators has not.

As a customer and network architect, I "hired" network equipment (front-end processors, switches, routers, etc.) to satisfy that network service job. They formed the solution to the job, while the SLAs were the outcomes by which it was judged.

Into Vendor Land

I spent much of the next chapter of my career at a large network vendor (and some compute virtualisation vendors). However, I'm not convinced many at that networking vendor always looked through the lens of "the job of my customer is to provide a network service". Instead, the focus was often on the product rather than the job for which they were employed or "hired". Sales folk trying to meet quarterly goals might scream they needed feature ‘x’ to close a deal, and so the continuum went. It was a tough situation. And perhaps this was reinforced by the quarterly analyst numbers that defined markets around technologies and product classes (admittedly, the alternative market definition around customers and jobs would be difficult to quantify).

It was a sustaining innovation cycle with incremental features and worsening complexity. I had many conversations with customers who would lament their engineering and ops teams couldn’t run our premier product/solution. It was just too complex.

Vendors (us included) developed tools and dashboards inwardly focused on the health of the product rather than the job for which the products were employed. Of course, you need a healthy network, but the lens through which you judge the overall solution should be the job for which that technology was employed (hint: a network service for the business).

It may seem nuanced at first but adjusting your unit of analysis to the customer’s job versus the product makes an enormous difference. You can take this one step further to the CIO’s job of delivering an application service to the business. This would encompass the subordinate network service, storage service, compute service, and security service with their associated SLAs. A vendor with products in all these categories could do something quite novel in adjusting or optimising the subordinate services in support of the main job. The reality is that these subordinate areas correspond to different siloes and buying centres in most enterprises (and vendors). Of course, the public cloud providers had this worked out long ago.

Ok, Back to Nile

Let's get back to the Nile announcement. Nile understands that networks have become too complex. They also understand the job of a network is to provide a network service to the business and the metrics by which it is judged—the SLAs (or arguably the SLOs) of performance, availability, serviceability, reach, and security. They're tackling not only the core functional job of the network but also the product lifecycle components. Pankaj Patel (CEO of Nile) said they would "remove the insane complexity out of networking." Bravo, indeed.

Final Thoughts

Sure, there will be those who disagree. That’s fine. This is an opinion borne of my personal experience on the customer and vendor sides coupled with several customer interviews. Either way, I believe it’s a welcome and overdue shake up that will benefit customers.

There is a lot to unpack on the technical and delivery side, but I reckon they "get it."  Their mission and vision are game-changing. I look forward to watching how this plays out.

bottom of page