Tag Archives: naas

What’s Bothering Me About Nile After Mobility Field Day 12

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.

Something Old, Something New- A Geezer Looks at Mobility Field Day 12

I’m a delegate for Mobility Field Day 12, and am writing this a week ahead of the event. There are two vendors presenting, but both have an interesting connection. As I contemplate just the companies as I think I know them, I’m struck by the notion of Legacy versus New Approach. Read nothing into that- Legacy isn’t always bad and New Approach sometimes isn’t great. I’m certainly looking forward to what Cisco and Nile each have to say at MFD12. but pre-presentation contemplation is inevitable. Here’s where my head is at right this second.

Something Old in this case is Cisco. They have been in the wireless (and therefor mobility) game since way back in the day when they bought Aironet and this thing was new and sexy:

That was right about when dirt was invented. Cisco would go on to produce new access points for every 802.11 standard as they rolled out, and they made the jump to “lightweight” and controller-based WLAN with the acquisition of Airespace in 2005. Then in 2012, Cisco bought Meraki to get cloudy when all the cool kids realized cloud was the shizzle. Now today, we see see Cisco is set to End of Everything their once-flagship WLC controllers and the AireOS-based products while they also try to shoehorn their current generation Cisco-side wireless products into the Meraki framework. There’s a lot going on, and has been with wireless at Cisco for many, many years. While trying to leverage the Meraki Magic for full-stack cloud-management, they are also still trying to get revenue from the controller crowd where they can while perpetually coming up with new and innovative ways to license the holy bajeezuz out of everything and anything. I’m looking forward to what is new and exciting from Cisco.

Then there’s Nile. Something New in my narrative, Nile is pretty fresh to the network industry scene and is trying to push Networking-as-a-Service (NaaS) as The Next Big Thing. It’s interesting to me, being a network geezer, that the Nile product web pages are far more about saving you TCO costs with NaaS than they are about product specifications. I *think* that you are supposed to be buying “don’t sweat it, we’ll bring in the right stuff and you don’t need to worry about what that stuff is” and eliminating the need to scrutinize data sheets and find the right models for yourself. If you dig, you’ll get to the models in play, but they aren’t the lead story. And Nile appears to not just be wireless but maybe full-stack with “service blocks”. I’ll know more when I hear their presentations, but I can maybe see why this model is threatening to network architects and engineers if that’s the angle.

Now here’s the interesting part- if you look at the Who’s Who at Nile, you’ll find many People of Title that used to be at Cisco. I have sat through several Cisco “lower your cost of TCO!” meetings through the years, where those looking to lower my TCO never bothered to ask what my TCO actually was- the whole premise was built on canned assumptions that made for nice marketing but generally fell apart in spots pretty quick when examined through the lens of reality. Is the drumbeat of “Lower your TCO!” by Nile just being played by ex-Cisco players who were fond of the same marketing strategy at the Big C? Or is Nile truly onto something new and valid? I suppose white box hardware might help with lower costs, but now I’m speculating. The Nile presentation should be interesting, and even maybe provocative.

Did I mention that I’m a geezer? Almost thirty years in the industry makes you think about things maybe a bit differently than the vendors would like, but us geezers have our own frames of reference and we’re stuck with them.