I have no beef with AI- except when it’s overhyped. I have no issue with cloud-managed networking- I’ve been using it for years, with multiple vendors. Let’s get those points out of the way before I lay out a couple-few concerns rattling around in my brain after attending Mobility Field Day 12 and hearing what Nile had to say.
Now before Drew Lentz launches into an orgasmic rant about how delightfully wonderful it is that Networking as a Service (NaaS) seems to be trying to gain traction with the likes of Nile, Meter, and Ramen, let me say that I’m not outright panning the concept on principle at all. A lot of what Nile presented was fascinating, and I will likely do another blog just on the technical side of their presentation. But for now, this is just about how I see potential issues with NaaS (as Nile presented it- I have yet to really see a Meter or Ramen presentation) in some scenarios.
TCO Pitches Are An End-Around to the C-Suite
I’m approaching 30 years in the networking space, and have worn almost every hat imaginable along the way. I’ve been in many, many “lower your TCO!” meetings. and most of them were targeted canned pitches aimed at getting the bean-counters’ attention while not really examining the realities of the environment in play. It’s no secret that those who control the budget in many ways control the network regardless of their own savviness on the finer points of IT operations. I’ve also seen the results of a few independent audits that sought to determine whether outsourcing IT support that I was part of would save money, but it was proven that our in-house team was a significant value in each case.
Would that apply to all settings and IT teams? Of course not. But it certainly applies to many, where good managers have hired good technical people and solid choices in solutions have been made. We are not all interchangeable out here on the network playa. YOUR TCO story is different than MY TCO story. The overall quality of your skill pool is different than my own. Count on it. But Nile seems to be going for the whole-hog, no exceptions, WE WILL SAVE YOU MONEY tactic.
What’s that old saying? If it sounds too good to be true… I have no doubt Nile is a reasonable fit for SOME environments. I also have no doubt that it’s not a great fit for OTHER environments.
Surrender Your Network Operations to AI and a Nile Partner?
I think this is what is really bugging me when I contemplate Nile in my own sphere of operations. I’m all for AI making analysis better and identifying problems. I’m not keen on having to consult a partner who might have to run it by Nile when I want to change something in the network. Or for waiting for the finger-pointing to settle out between me, the Nile partner, and Nile when tricky issues come up.
And about that partner thing…
Part of the Nile pitch is that “your IT staff gets freed up to do other projects”… like maybe being unemployed or sending resumes to Nile partners when that staff are no longer needed because a large swath of the operation has been outsourced. Maybe shrinking the headcount is the right thing for a given enterprise- especially if they have the wrong heads in the overall count. But what about responsiveness and effectiveness when it comes to buying into the partner-as-your-network-team approach? I heard at #MFD12 that your networking success as a Nile customer is ultimately between you and your new BFF Nile Partner… I’ve done the limited outsourcing thing at times, and it’s been a mixed bag for results. It has been nice to have additional labor doing the grunt work of networking, but too often something that is supposed to be “turn-key” ends up needing frequent local in-house expertise or parallel monitoring to solve issues fast. When phones are out or cameras in sensitive spots are down, being in the partner’s queue while important systems being out are disrupting business continuity is not fun. So we occasionally end up doing what we also pay others to do because we have to- out of expedience and crisis avoidance. There’s some TCO for ya, Bunky…
But if our C-suite has “freed us up to work on other projects” and we’ve moved to a model where the partner is the crisis resolver, then we better have a damn solid partner or our TCO actually goes up while we lose money waiting for them to figure out our issues. We have no control over their skillsets, work ethics, or understanding of what makes each one of our environments unique. We have no insight into what their relationship with Nile REALLY is like. We’re talking grand-scale LEAP OF FAITH stuff here. (Leap away, Drew- you magnificent bastard.)
It’s Not Either/Or
I did find the Nile approach to be quite interesting and even compelling in spots. I can easily see them being a potential fit for my branch locations scattered around the US and in Europe. (But even as I type those words I realize that doing that would require me to find partners in multiple states and countries- as opposed to me just configuring everything in the Meraki dashboard and having the network components drop-shipped to someone on the far end that can follow directions on hooking it up.) I can see the potential appeal of Nile where I don’t have an established, effective network team- like in my branch offices where my topology needs and network sophistication tend to be pretty simple on balance. But for “the big network” where new requirements might pop up weekly, with the unimaginable-to-some mix of client devices I have in play, and where response is usually measured in minutes or hours, I have a really hard time contemplating placing the fate of tens of thousands of clients in the hands of a partner. I also cannot imagine needing to negotiate a desired config change in my environment with a partner or even Nile. God forbid the AI overlord doesn’t agree with my request.
More to come on Nile from me.
And Drew knows I love him.

