Controllers Are Dead (And Why)
Analysts just love to pronounce big, visible elements of their chosen industry dead, and I’ve done this a few times myself over the years. Such must always be done carefully and judiciously, of course, and one’s reasoning behind such a conclusion must be carefully justified. One little mistake and one’s credibility can be severely damaged. But, no matter the risk, when it’s time to play coroner, such must be done.
And with that: Are Wi-Fi controllers really dead? Yes, indeed, they are. They’ve in fact been dying for much of the past decade, and we’ve reached the point where controllers are no longer necessary.
Now that even Cisco has recognized this fact, it’s time to have a serious discussion about the future of Wi-Fi controllers. Yes, controller-less solutions have been available for a decade, but when the Wi-Fi market-share leader declares controllers to be dead, everyone pays attention. In this post, we’ll explore the three key elements that have led to our funeral for today.
1) Just what is a controller, anyway?
Controllers, which trace their roots to the WLAN switches of the late 1990s, were put in place to centralize key functional elements of given WLAN architectures and implementations. This strategy was quite valuable at the time of their invention, because the microprocessors available for use in APs simply did not have the horsepower to do all that was required not just by the rapidly-evolving Wi-Fi standard, but also in support of essential upper-layer functions like security (Wi-Fi’s security is, after all, only one small part of security overall).
There was even a movement towards several variations of “thin” APs, with the reasoning being that APs should be responsible for nothing more than putting data on and getting data off the air, with the really difficult parts implemented in the controller.
Some architectures require that traffic from APs must flow through controllers, often citing security as a key beneficiary of this strategy. But modern controllers primarily implement the policies specified by the management plane of a given system via its corresponding management console. So, then, the controller is pretty simple – in concept, anyway.
2) So why have controllers shuffled of the mortal coil?
OK, the counterargument. Do controllers work? Sure. They do. But their disadvantages are many, as follows:
- Additional cost and complexity – If we distribute the functionality of a controller across the APs we need anyway and allow (secured, of course) data to flow in the most expeditious manner, we don’t need the controller at all. Controllers ain’t cheap, and they are one more element that requires management attention, both regularly and at the worst possible time.
- Redundancy requirements – Make that two or more elements. Controllers must be configured redundantly to provide the reliability, fault-tolerance, and resilience essential today, avoiding single points of failure. More cost. More complexity.
- Scalability issues – It’s possible to run out of capacity in a controller as the network and particularly its traffic volumes grow. Upgrades ain’t cheap, either. More – oh, well, you get the idea.
- Performance issues – again especially if traffic must flow through the controller, but over time most controllers run out of gas regardless. Upgrades and, eventually, replacements are both required.
And even as controllers have attempted to stay current with the times, via virtualization into VMs and Cloud-based implementations, and even disappearing into APs in smaller configurations, they’re still there, with all of the management overhead we noted above.
3) What do we do instead?
Well, obviously, we build highly-distributed WLAN architectures that distribute the control plane among access points transparently. This should look familiar, as it’s exactly the strategy the Internet itself uses. Imagine if the Internet required centralized controllers – you get the picture.
There are real advantages to distributing as much functionality as possible in WLAN systems, particularly as noted above with respect to cost, resilience, and realized throughput.
If we think in terms of a control function implementing the control plane (what I like to call the “operating system” of a WLAN) as distributed across APs, instead of centralized into a box dedicated to this essential function, it’s easy to see the basic advantages of controllerless approach. The data plane can be more efficient in this case, as there’s no controller for data to flow though, and the management plane can be implemented on a local server or even in the Cloud.
Everything gets simpler, easier, and (potentially much) cheaper as well. With the microprocessor power available today, the scheduling and control algorithms at the heart of the control plane can easily (and even optimally) function in distributed implementations, although the specifics in any given case remain the secret sauce of distributed WLAN system vendors.
The financial picture associated with the end of the controller era deserves a bit more discussion, so we’ll cover this in a more detail next time.
All posts in this series: