Folks have been touting that controllers are dead for many years now, but the reality is they are still alive, albeit dying a long, slow, painful death. Many vendors like Cisco and HPE Aruba had large customer bases using controllers, and it was very much in those vendors best interest to keep them alive while they built the next best thing. It’s much easier to start from scratch like Mist did for example (acquired by Juniper and subsequently HPE). They have all however gotten a taste of that delicious, never ending, recurring cloud revenue and are all headed in that direction in one way or another.

Cisco for example has released the Catalyst 9100 series APs that now can work with the Cisco Meraki Cloud. HPE Aruba has released AOS 10 that has the flexibility of APs working with the HPE Aruba Central Cloud only, or the HPE Aruba Central Cloud and gateways. They have essentially renamed controllers to gateways and “gateways” are now optional. Gateways can optionally handle some data plane functionality. HPE also just announced they will be acquiring Juniper which includes Mist AI/Cloud, further signaling the acceleration towards the cloud. Mist got well ahead of HPE Aruba in AI and Cloud because they simply started from scratch so HPE just bought them! Problem solved, or is it? Integrating everything will likely slow them down. The time is ripe for new challengers to step up starting from a clean sheet of paper.

The Legacy Controller Architecture
I personally like to refer to controllers as legacy at this point and don’t want to hear any vendors pitching them to me. This includes your newfangled “gateways”. You see I was all in on cloud but then I started a new gig who was still running all controllers. Going back to separate management systems, controllers of controllers, more controllers, stacking controllers, clustering, virtual interfaces, failover, etc., is just a nightmare! It’s just too complex and difficult to maintain/troubleshoot impacting OPEX. The legacy controller architecture is often referred to as a centralized or an in band architecture. Specialized hardware-based controllers (Cisco or HPE Aruba for example) are installed locally onsite or potentially in the data center to perform centralized management, control and data plane functionality.

The Management Plane
The management plane refers to the logical WLAN architecture component that is responsible for management functions such as configuration, monitoring, and firmware management.

The Control Plane
The control plane refers to the logical WLAN architecture component that is responsible for functions that determine how traffic should be forwarded such as layer 2/3 mobility coordination.

The Data Plane
The data plane refers to the logical WLAN architecture component that is responsible for client data forwarding. In a controller architecture, client data is tunneled from the access points to a centralized controller for policy enforcement (authentication, firewall, bandwidth allocation, L2/3 mobility coordination, etc.) In some ways this makes deploying the controller architecture a bit easier given you don’t need to configure all the VLANs at the edge.

The controller provides the intelligence in the solution. The access points are dependent on the controller and often referred to as dependent, thin, dumb or lightweight. While a distributed data plane is possible with a controller architecture (not tunneling client traffic from the access points to a centralized controller but instead having traffic remain distributed at the edge at the access points), doing so often comes with a sacrifice of features/functionality. For example, limited authentication methods, no firewall, no layer 3 mobility, etc. The controller typically performs these functions and the access points are not intelligent or smart enough to perform them on their own.

Areas of Concern with Legacy Controllers:

  1. Specialized, expensive (hardware, licenses, rack space, power, maintenance), hardware-based controllers perform centralized management, control and data plane functionality resulting in limited scalability and challenging controller sizing exercises.
  2. Controllers can result in single points of failure, traffic bottlenecks and u-turns. For example, if printing to a local printer, traffic may be required to travel all the way to the data center and back again to get to the local printer onsite.
  3. While scalability concerns and single points of failure can be mitigated with redundant hardware, stacking controllers, high availability, clustering, etc., doing so significantly increases complexity. For example, many companies have have mitigated scalability concerns and single points of failure by leveraging redundant controllers and clustering functionality, however this has resulted in an overly complex architecture that is difficult to maintain and troubleshoot.
  4. Client data is tunnelled to a centralized controller local onsite or at the data center where policies are enforced. This is not aligned with many SDWAN architectures being deployed (local breakout).
  5. Client traffic enters deep into the network before enforcing policies vs enforcing policies at the access point, at the edge, before entering the network. Security best practices indicate to enforce policies closest to the source.
  6. There is a loss of feature/functionality if attempting to turn off tunnelling (bridge mode). For example, application and device type/OS visibility, dynamic multicast optimization, captive portal, layer 3 mobility and firewall.
  7. Missing the operating efficiencies of modern Artificial Intelligence (AI) and Machine Learning (ML) features/functionality not available in controller architecture such as AI Insights (helping to proactively find the needle in the haystack), AI Search (Natural Language Processing (NLP) search engine) and AI Assist (auto traffic capture, auto ticket generation in IT Service Management (ITSM) platform and  auto Technical Assistance Center (TAC) escalation).
  8. Missing modern APIs and webhooks often not available in controller architecture for further automation in the future.

The Modern Cloud Architecture
The time is now to migrate to a modern cloud architecture. Often referred to as a distributed or out of band architecture. A modern cloud architecture performs centralized management and control functionality in the cloud with 99.99% reliability and unlimited compute resources however distributes data plane functionality to the access points at the edge. This results in unlimited scalability (simply by adding additional access points) and increased reliability. Access points are more intelligent, enforcing policies at the edge and are often referred to as intelligent or smart.

The Modern Cloud Architecture Offers the Following Benefits:

  1. Reduced costs and increased reliability and scalability:
    • Ability to eliminate specialized, expensive (hardware, licenses, rack space, power, maintenance), hardware-based controllers with scalability and challenging sizing concerns from the network and instead leverage the cloud for management and control functionality with 99.99% reliability and unlimited compute resources however distribute data plane functionality to the access points at the edge. This results in unlimited scalability (simply by adding additional access points) and increased reliability.
    • No more single points of failure, traffic bottlenecks and traffic U-turns of hardware-based controllers. When the access points are unable to communicate with the cloud, or the cloud is unavailable, they continue to function resulting in only temporary loss of cloud management instead of network down time.
  2. Decreased complexity without the requirement for redundant hardware-based controllers, stacking controllers, high availability, clustering, etc.
  3. Client data is bridged at the access points at the edge where policies are enforced instead of tunneled to a centralized controller. This aligns with many SDWAN architectures (local breakout).
  4. Increased security with policies enforced at the access point, at the edge, closest to the source as security best practices indicate vs. traffic entering deep into the network before being enforced.
  5. Increased operating efficiencies:
    • Ability to take advantage of modern Artificial Intelligence (AI) and Machine Learning (ML) features/functionality often not available in controller architecture such as AI Insights (helping to proactively find the needle in the haystack), AI Search (Natural Language Processing (NLP) search engine) and AI Assist (auto traffic capture, auto ticket generation in IT Service Management (ITSM) platform and  auto Technical Assistance Center (TAC) escalation).
    • Ability to take advantage of modern APIs and webhooks not available in controller architecture for further automation in the future.

Recommended Approach
If you haven’t gotten started on the migration to a modern cloud architecture you really should. Start out with a lab trial. Get a few APs into the lab and start kicking the tires. In fact, you should get a few from each vendor (Aruba Central, Cisco Meraki, Juniper Mist, Extreme, etc.) and start comparing and contrasting. I really like what Juniper Mist is doing but judge for yourself. Which has the features you need, which is easiest to setup, which has the best user experience, which has the best built in help, which provides the best performance, which has the best vendor support, which has real AI and not just marketing spin. Given many folks work from home these days, you might even want to set up your home network as your lab, although you might have to perform changes after hours as to not upset your significant other and children! If you have teenagers, gamers especially, they do a great job of basic stress testing and won’t be shy about telling you what they really think about it. Once you have performed a lab trial, identify a small site to use as a Proof of Concept (POC). The biggest technical hurdles may be extending the VLANs to the edge, and perhaps configuring the APs as RADIUS clients in the RADIUS server instead of the controller, but you should have already tested those out in the lab. Once you have had success with the small POC, extend out to a larger pilot and so on.