Having just attended the 2019 Wireless LAN Professionals Conference (WLPC), I got a few days full of really interesting perspective from other WLAN doers. I saw and heard predictions, hopes, and fears for what comes next as we roll toward 802.11ax, the coming of 6 GHz spectrum to Wi-Fi, and more widespread use of WPA3. There was a lot of good chatter, because there simply is no conference like WLPC (I recommend it to anyone who is in WLAN practice/management, or over those who who are).
One thing I heard A LOT about was APIs. And using Python to get more out of our WLAN hardware and management systems. And… how “you should all learn to do coding!” I have no issues with any of these, but I also tend to be a 10,000 foot thinker and so couldn’t help but ponder the real-world implications of all that when it comes to how wireless systems are actually run day-to-day. I also found that I wasn’t alone in my contemplation in talking with others at the event.
Let me get right to my points- I have great appreciation for the flexibility and capabilities that using APIs can bring to a WLAN system. But… that is balanced by a number of concerns:
- If a vendor has historically put out crappy code that is developer-driven versus engineer-driven, how do we trust the developers to get it right when it comes to what data awaits engineers at the end of the APIs?
- I fear that “and we have an API!” can become a cop-out for NOT putting out a complete enough NMS system for the high costs that you’ll still pay for these NMS systems. As in… “oh THAT feature is leveraged by the API”, and not in the expensive management GUI that maybe now is missing common-sense basic functionality.
- In some ways APIs-to-the-rescue is a huge step forward, in other ways it’s an admission that vendors sometimes can’t build an NMS that doesn’t suck (because if they could, maybe we wouldn’t need APIs?) Maybe…
- Not all WLAN staff teams will want to be in the programming business. Time will tell if they will be able to work effectively as they avoid the API and try to stick with the NMS and non-API tools.
None of this is necessarily my own strict opinion as I digest everything I’ve seen and heard at this year’s WLPC, but I heard enough from other people to know that the community is not in lockstep embrace of “API all the things”. Some teams are just stretched thin already, and pay a good buck for vendor tools so they don’t have to become programmers to keep their WLANs on the rails. Then there’s the always-relevant “evolve or watch your career die” school of thought that can’t be ignored either.
Fascinating times. Much change is in the air.
Now onto one of the most interesting things of all that I heard at WLPC: more on Open Config. Mike Albano from the Enterprise side at Google planted some fascinating seeds back in 2017 with a presentation he did at that year’s conference:Introduction to OpenConfig; What Is It, What Does It Mean To Wi-Fi | Mike Albano | WLPC 2017 Phoenix from Wireless LAN Professionals on Vimeo.
Mike was on the stage again this year doing a little follow up on progress made with Open Config. He also participated in a Whiskey and Wireless Podcast with a couple of nicely-hatted lunatics and shared even more with an eager audience. I suggest you keep an eye out for both his recorded WLPC presentation and the podcast to come live (I’ll add the links here as well), because Open Config is the API concept on steroids. As mentioned in the 2017 video, but expanded on this year, Open Config seeks to make the software side of many vendors’ wireless offerings largely irrelevant. You gotta hear it.
Given that we’re in an era where WLAN vendors have declared themselves “software companies” who happen to put out some pretty crappy software and then charge through the nose for it, Open Config is interesting for reasons far beyond it’s API-ness.
Like I said, these are fascinating times.