Having spent almost eight hours with Nile’s senior technical leadership to get more familiar with the company’s unique approach to LAN and WLAN, I can say upfront that I appreciate the ambition and effectiveness of the solution. You will not find a framework that more effectively tackles design challenges like VLAN management and network security and makes it look easy if you can get there. But can you “get there”? Not all environments will be able to. And if you do get there, expect a different kind of daily network management experience.
A Geezer’s Take
For those of you who don’t know me well, a quick intro is in order. I’ve been in networking for almost thirty years now, following over a decade spent doing electronic warfare for Uncle Sam. I’ve also worked as a freelance analyst and writer with lots of opportunities to look at a range of different networking companies, products, and strategies. I don’t know it all, but I have done and continue to do enterprise networks big and small. I’m a certified expert in some things, a qualified professional in others, and then there are technical areas where I’m an utter buffoon but have the wisdom to yield to my betters. I was an early cloud-managed networking adopter, but I also understand the pros and cons versus on-prem. This all shapes my perspective on the cloud-managed, As a Service delivered Nile solution.
A New Lexicon
In learning about Nile, I found myself needing to hear many things twice and then to have them explained to me with simple words. There’s just so much the starts off feeling differently, even if underneath it’s really not that far from what we’re used to in legacy networking. This effect made locking on to Nile’s methodology harder for me, but it is what it is. Let’s consider the Nile Service Block as an example.
Um, what the hell is a service block?
Sounds odd to the trained networking ear at first, yes. But the Service Block is just switches and access points. That’s it. Well, kinda/sorta. There are different sized service blocks for networks of varying sizes, and to migrate to Nile is to use both their switches and access points from Day 1. This is not optional- you must use 100% Nile switches and APs within the Nile framework. Sounds easy in small environments, and potentially impossible in larger ones where switches and APs are numbered in the thousands- especially given that switch lifecycles may be much, much longer than AP lifecycles.
UPDATE: Nile reminds me that on the topic of needing to use all Nile APs and switches- This is right but our customers can migrate one floor or one building at a time. One doesn’t need to forklift the entire network at once. I accept that, but I don’t see it as scalable for other than a complete, rapid migration.
A Different Philosophy
One of the things I struggled with learning about Nile was the voice in my head that kept saying stuff like “this isn’t how I do it now… these are radical operational changes…” But finally that all melded into a Grand Realization. For most network solutions, you buy bits and pieces and shape their configs to meet your networking operational philosophies and goals. With Nile, you are buying an operational philosophy, and your networking approach and team dynamics will need to adapt to that philosophy.
Is that bad? No, not at all- especially given that most of Nile’s vison is impressive. But’s a pretty radical departure, from “normal” networking. It’s also something that not all customers will like the feel of. After I got a deep look at some of Nile’s key advantages like Layer 2 issues being completely eliminated and zero-trust security that will not be topped by any other solution, I started to realize the payoff to accepting the Religion of Nile. But as I said, that won’t be for everyone. Especially given that some simple-to-me changes need to be asked for from Nile- as in you need support to make certain changes to the environment that today would be commonplace engineering tasks.
Where Does Nile’s Approach Work Well?
Though my mind does not yet accept Nile as a big environment player (unless that big environment has endless time and money and is very, very thin on networking staff), I can see myself potentially loving the solution in small to medium environments up to dozens of switches and a few hundreds of APs. Why does my mind cap it there? It just does- my personal frame of reference sees that as a natural boundary to the Nile story. Nile will disagree, and I don’t claim to be right on this- just telling you how I see it.
Nile’s management and monitoring views are fantastic, I must say.
UPDATE: Nile reminds me that despite my trepidation “We have very large campus deployments – 40 building campus; 200K people conference center where an event hosted 55K people on our network; 2M Sqft Distribution Center. In terms of scale, you may have an opinion but we have proven to scale to large sites and large concentrations of people.” I’m sure the solution scales, but my opinions about the complexities of getting there in other than greenfield deployments remain. But I do thank Nile for their input.
What About Wi-Fi, Specifically?
First the good- after seeing Nile’s AI-enabled wireless management framework, I have no doubt that they are solid. Solid for client access. Solid for security. Solid for radio management in general. Solid for smooth integration between the LAN and the WLAN.
But again, it’s the getting there that may be a bit thorny to accept.
As mentioned, you will need Nile’s APs AND their switches. There are no wallplate APS offered. There are no external antenna APs offered. There are no Wi-Fi 7 APs on the roadmap yet as of today. And… before you can deploy Nile APs, every space where they will be used needs an Ekahau survey done and design verified by Nile. Why? They can’t guarantee excellent performance if they haven’t approved the design. I get it, but I don’t… In that this gets into the waters of what Nile is “responsible for” versus what the end user’s IT team (if there is one) is responsible for. To me, as a 20 year WLAN design professional, I don’t want a vendor’s approval as a rule. I know my spaces better than they do. But, I do somewhat get the “why” of the requirement- but I also strongly disagree with Ekahau-only.
UPDATE- Nile has informed me that both Wi-Fi 7 APs and APs with directional antennas are in fact in development. (Not so with wallplate APs.)
What if I want to disable legacy data rates? That’s the kinda thing you need to ask Nile to do, you don’t have the administrative freedom to do it yourself. There are enough examples of this “you have to ask” stuff that it can feel offensive as a WLAN professional. Again, just my opinion.
Nile shows sensors as part of the solution, but I struggle to see the value of the additional cost if everything else is controlled and engineered so tightly. They are an optional aspect of the solution. Maybe they have an operational value that I can’t grasp but I can’t say I’m warm on them.
As a Service Messaging, Messaging in General
Also my opinion- Nile is different enough as a solution that they need to be careful in their messaging. Throw too many “we’re different because of THIS” at us, and it gets overwhelming and can be a turn-off. Zero Trust alone is enough to ask people to swallow when they haven’t gone down that road before, as is totally replacing all APs AND ethernet switches as a requirement. Then throw in the “you MUST do” and “you CAN’T do” bullets, and your head might start to hurt. It can be a lot to process, even before you get to the question of what does “As a Service” mean.
Just as I now accept that the Nile solution is technically compelling (if you can live with the what it takes to get there), I also accept that As a Service doesn’t necessarily mean that in-house network engineers are no longer needed and that jobs will be lost. Nile needs to really, really be careful about saying things like “oh, that’s OUR responsibility” when marketing to mature IT teams. My network, my responsibility. Nile and their partners work for their customers, and not all customers are ready to relinquish control and design authority to Nile.
I have learned that the Nile solution does have a fair amount of use-case flexibility that starts with rigid Zero Trust but then adapts. To me, Nile really needs to do a better job of touting their flexibility versus their rigidity. To make those adaptations, you will have to work with their support team. How smooth is that process? I can’t say that I know as I have never gone that path.
Also on the topic of messaging, Nile needs to catch up with competitors in some regards- by now, Wi-Fi 7 has to be a declarable road-map item. And to go after bigger, more risk-adverse customers, any mention of “we’re a startup” needs to be stowed.
Final Impressions
Nile has some pretty big Silly Valley names in play that run the company and who have developed the solution. And the solution is impressive. But it’s also different enough on many levels that those same big Silly Valley names need to realize that the rest of us are slow to lock onto things that shake our reality and introduce too many changes at once. Many potential customers will never make it to the good part of the story if they get lost along the way trying to understand all that feels confusing and maybe a little threatening up front. I wish them the best, and truly appreciate the time I spent with Nile getting educated.
wirednot 