Dear Cisco, Please Don't Screw Up Meraki
Lee H. Badman
November 19, 2012
News has broken that Cisco is paying $1.2 billion for WLAN competitor Meraki. What will it mean for Meraki customers? Let me tell you my concerns, because I run both Cisco and Meraki networks.
Cisco wireless networking, which is built on a controller-based architecture, has arguably the priciest access points in the industry. And it has many of the problems that face very large vendors: long waits for tech support and a lack of response to input from all but the largest of its customers. (And I'm not the only IT pro who feels this way.)
- Agile Service Desk: Keeping Pace or Getting out Paced by New Technology?
- COBOL in the Big Data Era: A Guide
White PapersMore >>
- Research: Federal Government Cloud Computing Survey
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
By contrast, Meraki, which is one of the pioneers of cloud WLAN management, where APs and other gear are managed from a cloud-based platform, can compete with Cisco on features while also remaining highly responsive to customer feedback.
How do those attributes play out in the real world? Here's one example: My primary wireless environment is built on Cisco products, and I sometimes get frustrated by the amount of time I spend dealing with the technical assistance center (TAC). A Cisco TAC case is opened via multiple pages of Web forms after you find your support contract number (which we all know, right?). By contrast, with Meraki, a single click and quick text entry gets the support ball rolling.
Here's another example: Meraki customers can submit feature requests via simple Web form. I've been pleading for years for a virtual client function that lets you test the wireless environment any way you'd want by temporarily turning an AP into a full-blown client. To date, I can't get the courtesy of an acknowledgement from Cisco. By contrast, in less than a few hours, I was able to suggest to Meraki a rewrite of its wireless guest portal for my Meraki deployment of 35 APs at a remote site. Meraki techs worked with me via phone until they nailed it.
In my limited experience, I've also found that Meraki gear tends to mostly just work, which has been a draw for the Meraki faithful. Configuration of both wired and wireless hardware is simple. Site-to-site VPN tunnels, for example, are brought to life on Meraki security appliances with just a few clicks, and then they stay up. Our Cisco ASAs? After a few hours of cryptic command entry, the tunnels come up--until they break weeks or months later and we need to reboot them again, and then open TAC cases that go on for days or weeks (leading to the inevitable code upgrade recommendation that often brings new and exciting bugs).
What To Keep
Both companies have a similar product set and offer unified management. Meraki has recently brought cloud-managed security appliances (think Cisco ASA) and Ethernet switching into its portfolio, for a single-pane-of-glass management environment. Meanwhile, this October, Cisco announced a unified management platform for its wired and wireless network products. So what will Cisco keep?
Early press reports claim that Meraki will be left largely intact, from staff to corporate philosophy. Anyone familiar with Cisco has to wonder how long that can really last. Though Meraki is being described by some as Cisco's new middle-market strategy to replace what Linksys never became, there's simply too much product overlap between Cisco's and Meraki's gear. Cisco has a significant enough development investment in its native gear to not want to harmonize the two environments. Hug your Meraki MXes while you still can.
I realize all of this sounds like Cisco bashing, but I'm not anti-Cisco. The fact is, Cisco is the market leader for a number of reasons: Cisco products scale well, its gear is hardy and reliable, and the company builds new hardware with the needs of big networks in mind. So despite my complaints, I continue to choose Cisco for my campuswide WLAN.
The problem is Cisco takes the big-network model and tries to force it into places where it doesn't fit. For instance, I would've needed at least a handful of independently configured and managed Cisco devices in a branch deployment that I run to bring up the same core functionality that Meraki delivers in a single MX appliance.
Meraki has been that rare vendor that delivers the ease of use it promises, while not getting so big that it feels like developers and product managers are on a different planet from their customers. Here's hoping that all that's good with Meraki rubs off on Cisco. And regardless of how Cisco handles the Meraki integration, this acquisition validates the notion of cloud-managed networking.