The Cloud giveth, the Cloud taketh away
February 1, 2016 14 Comments
We all love ‘The Cloud’. It’s flexible, fast, always (mostly) available, and takes our business agility to heretofore unknown heights – but what happens when the service you’re using in the cloud goes a different direction than you need or want it to?
Meraki has been touting the Cloud flexibility as *the* single most important reason to move to their infrastructure management platform. This brings with it a whole host of great things like access-anywhere management, rapid feature development, and a whole new paradigm of how to configure your infrastructure equipment. In one move, Cisco has rocketed past the CLI based days of old, past ‘here’s a pretty GUI’ to 100% web driven, ‘don’t worry your pretty little head about it’ dashboards for everything from configuration, monitoring, troubleshooting, and deployment. It works and it works well.
Today marks the closing of Copy – a Cloud based file sync service from Barracuda and it got me thinking. When someone shudders their doors and it’s ‘just files’, you go to another Cloud based service provider – in this case Dropbox or box.com. What happens when/if Meraki goes away? Okay, they’re under the wing of big-brother Cisco now, so the chances of that happening are basically nil, but what if you ratchet that concern back a notch? What if they make a change you don’t like? What about ‘perpetual beta’ features such as the Remote Control that have been in beta since prior to the Cisco acquisition? What happens if you don’t pay your bill? Those of us familiar with Cloud services like Office 365 know that when you stop paying, you stop playing and for software based services (like Copy today) that doesn’t seem to as big as a deal to most people. What happens when that service is your network?
Perpetual Beta features
When Meraki adds a new feature to their product, the Cloud enables rapid deployment of those features. This is good. What happens when they remove a feature you use such as WAN Optimization? As you an see here Meraki decided to retire what they perceived to be either a little-used feature or a feature that was too difficult to maintain to keep functioning properly.
WAN Optimization, gone baby, gone!
What happens when Meraki decides to artificially cap the performance of your router (intentionally or unintentionally) to 50M?
Astute reddit users, always on the lookout.
While the WAN Optimization removal is clearly an intentional move and the Z1 cap is clearly unintentional, these both raise very significant questions about allowing someone else to be the ultimate authority for the features that are deployed on hardware you’ve purchased. What is your recourse when this happens? Open a support ticket? Make a wish? Roll back the firmware (hah!)? With no fail-safe mode of operation by design, when you lock yourself into a Cloud based infrastructure product, you are ultimately at the mercy of using features how and where they determine are best suited. Your only recourse is to scrap your gear if they make a decision to go in a direction that you no longer support. What is the environmental impact to this business model? How many Cloud-only products end up in landfills because of expired licenses? How much eWaste is generated because the product has stopped functioning (not through MTBF, but intentionally crippling through code)? You used to have options like Cucumber Tony and OpenWRT, but apparently Meraki has fixed the technical loophole that those folks used to use for the MR-12 and MR-16 Access Points by way of a Trusted Platform Module.
What is your take on Meraki and other Cloud based services that you operate your business with? Cloud based products are great and work as designed – but is loss of features something you consider prior to your investment in a solution? Does your organization rely on perpetually beta features that never seem to make it into production? Has a feature been ‘pulled out from underneath you’? What are you doing with that old AP/switch/firewall that is perfectly good hardware but you let the license lapse on? Inquiring minds want to know – please leave me a comment and let me know how you and your organization handles this kind of quandary!
SC-WiFi 
Great perspective, Sam. I had huge hopes for WLAN optimization, but it never worked right. It never should have been released as it was hyper buggy. Which brings me to… At this point, any “risk” associated with Meraki and better cloud providers is outweighed by the overwhelming-at-times weight of certain traditional vendors’ bugs and admin overhead on crappy controller code and WNMS systems.
As for Cucumber Tony, Open Mesh, Sputnik, etc- for SMB and home, these things are amazing. Even the much-maligned Ubiquit APs get really neat when flashed with Cucumber Tony/Sputnik. It’s not “Enterprise” but not not all SMBs need Cadillac (or even Chevy) APs.
If nothing else- I’d love to see Meraki’s UI excellence put some pressure on that other vendor to de-suckify their code.
None of this answers your questions, but just adding to the dialogue.
-Lee
Thanks for contributing Lee! As always, great input and insight.
-Sam
Lee, good perspective. But I do disagree that cloud provider control over your WLAN software versioning and features is lower risk than your own control as a customer over software versioning and feature use. Having managed a very large WLAN environment that crossed all sorts of use cases from centralized to distributed, from extremely critical business apps to guest/BYOD access because it’s cool. We had to develop such a very mature testing and verification process to vet *every single* WLAN code or configuration change (clients too BTW for the business critical corp owned clients). I don’t see how under any critical business scenario you can hand over software control to a vendor who does little to no quality assurance and rely on customer support incidents to be their QA team.
I don’t think cloud solutions HAVE to be vendor controlled. That is a business model decision that Meraki made to simplify THEIR business operations. To contrast, Aerohive (and from what I gather from Eddie’s comment, Aruba) provides cloud management that the user still retains control over software versioning, feature sets, and ultimately whether their hardware still works even if the cloud management subscription is cancelled. That to me is better flexibility for the customer and has tremendous value. But the downside is that Aerohive has a bit harder backend cloud service operations and management.
Cheers,
Andrew
Andrew-
You know that I always value your opinion. I can only speak from my own daily experience and the information that gets shared from other very-large WLAN admins that I talk with frequently. Over the last 7 or so years, I’ve only had issues with Meraki’s WAN optimization, and nothing else in a dozen sites. Their QA testing, or lack thereof, hasn’t burned me in any other way. My own small Aerohive pure-cloud network has also done fine from the cloud. So has my Cucumber Tony instance. Come back to my market-leading vendor’s on-premise equipment, and the code bug story would have put many lesser-funded companies out of business. It’s that pervasive and maddening, and I do not embellish. In fact, I would describe it as utter shit on both the WLC and NMS side on certain days. If the proof is in the pudding, the Meraki pudding has always been fresh and delicious and just reliable. The other vendor has been the polar opposite- it “feels” like there is no QA process for the vendor’s hyper-compelexity, or if there is it involves crack-addled orangutans. There’s only so much the customer can or should have to test for the dollars involved, and many bugs don’t show until the network is under load. For my operational needs (not everyone’s- that’s not my claim as I don’t live in a black and white mindset) the current Meraki paradigm has been an absolute grand-slam by every measure. At the same time, there’s plenty of time for it to eventually get screwed up.
-Lee
I’ll just repeat my tweet: “That’s what I like @ArubaNetworks model: Cloud as a value-add. Not an “all-or-nothing” deal.”
I’ve never understood the appeal of cloud-based WLAN solutions. Well, I get the appeal of cloud management in general – it’s the ability of these vendors to have control of your infrastructure and basically holding you ransom that is disturbing.
If the hardware was free I’d think it would make sense. But, selling the hardware AND then restricting access and features? That’s crazy.
Great article. Interested if the TPM is something that was added recently? Even so, they’re at least some APs out there, without the patch that will not fill the land. Which is a plus in my books.
That’s a great question! Honestly, I recall learning about a TPM some time ago, but I just opened up my MR-34 and can’t find any trace of a hardware TPM module. Having said that, attaching to the serial interface is pretty straightforward and it’s pretty clear that it’s secure-booting an image thats been signed somehow.
TPM has been around for several years inside some Wi-Fi manufacturers access points to secure the configuration, particularly for non-lightweight architectures whenever sensitive data is stored in NVRAM or flash of an AP.
Of course, but TPMs are typically a hardware component (from Infineon for example). What I’m saying is that a ‘proper module’ appears to be missing from the hardware of the MR-34, so there must be something else going on. CPU specs and all other ICs I identified do not appear to have any sort of TPM or security component advertised.
-Sam
If they did anything like that, they probably got the same approach as other vendors did when they panic that the FCC will not allow them to go to market ( http://www.wired.com/2015/09/hey-fcc-dont-lock-wi-fi-routers/ ) , which is a bootloader patch. Well, let’s see one and crack it open!
Excellent point, but that covers WiFi devices only. What about switches and firewall appliances?
Simon here from Cucumber Tony. Hello. Obviously my views are slanted.
It’s this total, uncontrollable lock-in that drove us to write Cucumber. When something is blocked, humans go out of their way to bypass it. Look at what happened with the recent locked Ubnt AC. It was cracked in a matter of days. Now, where does that leave Ubnt? Back to square one. Pointless.
If we could all be a little more cooperative, we’d have a supercalifragilisticexpialidocious set of tools to use. We could pick the best ones for the job. Nifty.
Some are trying… Ruckus have the vSZ with a (just about) OK API that means the end user can use their interface or they can use ours (or anyone else for that matter if they wish). It might only have about 1% of the functionality (so far) but at least it’s simple, it works, it has the stuff people need. And it’s a choice. Mimosa are doing the same. It’s cool and useful to have a single pane of glass to manage things.
This pane of glass doesn’t have to replace the manufacturers dashboards…
Lee’s right, not everyone needs enterprise features. In fact, most people don’t need 1% of them. They’re mainly just fun to look at.
This Meraki move only encourages us / people to break it. And I’m sure it will be broken in a few days. And why not 😉
The cloud giveth, the cloud taketh away. The cloud giveth once again. Rinse, repeat.
https://servernetworktech.com/2016/02/pwning-the-meraki-mr18/
Pingback: Sometimes Good Companies Do Stupid Things- Meraki Edition (IT Toolbox Blogs) – sec.uno