Top 3 Telecom Provider with a Heavy Retail Presence Selects Pica8 over Cisco
In 2017 a top 3 telecom provider with a heavy retail presence (more than 4,000 stores in the U.S.) made a business decision that has been delivering solid dividends ever since: It started replacing some 5,000 Cisco Catalyst switches in its stores with Pica8’s PicOS® Software Switches on white box hardware. The strategy is saving the company about 50% in capital and support costs. But cost savings accounted for only about half the rationale for making the change. The open strategy also gave the flexibility that the company wanted to implement a multi-vendor network with Aruba WiFi and enable an automation strategy, based on Pica8’s AmpCon™ Controller, that includes zero-touch switch provisioning in its stores and simplifies ongoing (switch) lifecycle management, thereby reducing operational costs. The decision to replace Cisco Five years ago, as part of its regular, rotating access switch refresh process, the customer examined its costs for upgrading the Cisco 3850 switches in its stores. The 50% cost savings the company identified came from replacing its Cisco switches with Pica8 PicOS Software Switches deployed bare metal on comparable power-over-Ethernet (POE) white box switches from Edgecore. Pica8 software runs on an unmodified Debian Linux-based kernel. White box switches are built (by the same ODMs) on the same basic platforms in terms of chipsets as switches from Cisco, Juniper and the like, but without the brand name cost far less. Support costs are also considerably lower than what the customer was paying Cisco. With Edgecore/PicOS switches installed in about 1,400 stores to date, and more on the way, the savings have panned out as expected. On top of the cost savings, three other factors collectively played an equally important role in the decision. First, the company had plans to build an automation framework that would enable it to manage its entire IT infrastructure, including the network, from a single centralized console. The company wanted any new switches to support network automation tools with open APIs that would integrate with that framework, rather than Cisco’s proprietary automation platform and tools. Second, even if the customer did decide to use Cisco’s automation tools (which eventually became DNA Center), in many cases doing so would mean incurring the additional expense of upgrading to the latest switch and software versions. This would require a massive unplanned upgrade and paying for features and functions the customer didn’t need in its stores. Finally, the customer said it was not getting the level of responsiveness from Cisco that it needed, in terms of addressing bugs and issues with different features. In contrast, Pica8 consistently receives compliments on its responsiveness in our quarterly business review calls. Pica8 passes the security test After it made the decision to go with an open switch approach, the company held a proof-of-concept bake-off between Pica8’s PicOS and Cumulus Linux. Pica8 won out largely on the strength of our ability to address some access layer protocols that are critical to ensuring security and robustness in the access layer. These protocols address issues like user authentication, and guarding against malformed packets as well as bombardments of spam traffic that can bring down switches – all issues of concern in access environments such as retail stores. Pica8 has been servicing campus and access networks since its inception, so we had no problem meeting the customer’s requirements. The competition had its roots in data center networks where such issues don’t generally come up. Automation makes the grade Pica8 was also able to deliver an automation framework that fit with the customer’s enterprise IT and network management vision. Our AmpCon Controller enables several capabilities that help the customer cut its network operational expenses and enhance operational reliability, including zero-touch deployment. Installing a new switch in one of its stores is a simple process for the customer: plug it in, connect it to the network and turn it on. From there, an agent on the switch enables it to find the AmpCon server, update the software if necessary, add licensing, install a pre-loaded switch configuration and bring the switch up on the network in a single deployment workflow. That means the customer can quickly deploy switches with no truck roll or on-site technician required – an important consideration given its stores generally don’t have IT staff on-site. AmpCon also helps with ongoing operational tasks, including configuration backups and software updates. The customer can queue up software upgrades for all switches in a given region, for example, and execute it overnight with the push of a button. Should a switch fail, AmpCon can execute a RMA workflow to push its configuration to a replacement switch. It will also flag any switches that have support scheduled to expire soon, and automatically install updated licenses with support extensions. Reliable switches are essential to any company with distributed sites. They support network traffic and IT infrastructure that is critical to keeping sites functional, so they need enterprise-level features that promote reliability and ease operations. As our work with this large customer shows, Pica8 understands those requirements well and can deliver them even under the most demanding circumstances. And our open approach means you not only save on costs but can take advantage of the flexibility that is inherent to open networking. To learn more, read our white paper, “An Enterprise Approach to White Box Networking.” Or, if you have questions, feel free to get in touch. Niraj Jain is the COO of Pica8.
Want NAC without Cisco’s Financial Handcuffs? Then You Want Pica8
In recent years, we’ve seen a real upsurge of interest in deploying network access control (NAC) in the enterprise campus. We’re not at all surprised by this, given the network is now used by more types of devices (IoT, security cameras, BYOD) and users (students, employees, contractors) than ever before. What’s more, organizations are more conscious about securing their networks and data – rightfully so – and capabilities and enhancements NAC has gained over the years make it an intriguing option. But is it millions of dollars’ worth of intriguing? As we understand it, enterprises contacting Cisco about NAC are likely to find themselves being funneled toward Cisco DNA Center, whether they want that expensive network management platform or not. It’s not that Cisco DNA is required for customers seeking to implement NAC, but you can expect a hard sell in that direction. We believe we’ve got a far better solution, and we know we’ve got one that’s less expensive, and based on open networking principles. With Pica8, NAC is built right in. It’s part of PICOS, our open NOS. All that’s required is a bit of configuration – defining policy for users and devices on the server, and some straightforward configuration on the switches. The result is a network that is protected by PICOS-enabled switches acting as front-line sentry, tightly integrated and controlled by the NAC server as the security policy “brain” of the network. NAC’s growing impact While NAC started life as a configuration tool for dial-up access servers, it now serves as a vital network-wide policy management tool for enterprise networks. NAC can individually authenticate both a device (via certificate or MAC address) and that device’s user (typically via credentials). Attempts that seem suspicious can be quarantined, while those that aren’t are assigned to the appropriate VLAN (by department or business unit, for example). Next, the appropriate authorizations are applied, ensuring that a given user can access only predetermined data and areas of the network. Today, these traditional functions are just the beginning for NAC; there’s good reason switches supporting NAC are now more accurately called policy servers. Modern NAC solutions consider the full context of the network access request – including users, devices, time and location – when making access decisions. Users logging in from a personal device or off-premises location (and isn’t that important in a post-pandemic world) may face reduced access privileges compared to those logging in from company-issued laptops. Additionally, the NAC server can be connected to DNS servers, DHCP servers and other network infrastructure components, where it collects as much user information as possible. Using that data, it constantly monitors back-end system activities. If a user begins to act in a suspicious manner, the NAC server can shut down that port, notify the questionable user’s manager, and take other actions — all on the fly, in real-time. In short, we support a comprehensive set of NAC services in an affordable, easily managed manner. It’s rare for an enterprise to deploy, for example, Aruba wireless but Cisco NAC, or vice versa. But Pica8 PICOS switches can fit well in either environment, because they’re built on open networking principles, and we’ve focused on ease of integration. That’s the beauty of open networking. IBN without the pain Just as Pica8’s NAC approach is more straightforward than our competitors’, so too is our intent-based networking, which is garnering more and more interest (though the definition and operation is a moving target). IBN is just a much easier lift with Pica8. Our AmpCon framework, available for a fraction of what Cisco DNA costs, replaces legacy vendor-driven operational complexity with simplicity, addressing the networking-specialist skills shortage and reducing operating expenses along the way. Taken together, Pica8’s NAC solution and AmpCon IBN serve as another example of Pica8’s flexibility, accessibility and affordability. We believe it’s time for organizations to break free of vendor networking lock-in and take-it-or-leave-it pricing. For more technical details on NAC, see this previous blog post. To learn more about the Pica8 vision for IBN, download our white paper, “An Open Approach to Implementing Intent-Based Networking.” Click here to try out PICOS or request a demo.
Tech Talk: Why Telemetry is Critical to Successful Intent-Based Networking
Interest in intent-based networking (IBN) continues to grow, even as the definition remains vague and varies by vendor. In this post, I’d like to offer my take on one element that I believe will be important for any successful IBN implementation: efficient and effective open telemetry. Telemetry is key to data collection and monitoring which, in turn, is crucial for managing not only networks, but everything the network supports, including applications and storage systems. With effective telemetry, we can automate responses to network issues to ensure reliability, uptime and performance. Open telemetry with gNMIAt its core, telemetry involves two things: The continuous collection of data from networking devices, such as switches and routers Ensuring all data collected is time-stamped Continuous data collection is important in order to be able to diagnose issues on the network, including those in the past, and to establish a baseline of “normal” network performance. The timestamp is important to establish when a given incident occurred, and the time differential between different, related incidents. Together, the two elements enable you to identify trends and, soon, to diagnose issues in real time, using artificial intelligence tools. The real challenge with telemetry is coming up with an efficient way to collect data while handling data traffic in parallel, which is exactly the issue gNMI-gRPC Network Management Interface is designed to overcome. gNMI is an open source (OpenConfig Project) unified management protocol for streaming telemetry and configuration management that leverages the open source gRPC framework. This means a single gRPC service definition can cover both configuration and telemetry. The gNMI service defines operations for configuration management, operational state retrieval, and bulk data collection via streaming telemetry. Spawning new management capabilitiesThis efficient data-collection capability is important because it will give users management capabilities they simply have not had up to now. It will enable us to use sFlow to monitor network devices in real time, while using gNMI to efficiently send the data to a central data collection server for storage and analysis. To date, sFlow has been used mainly for non-real-time historical analysis and troubleshooting, because there simply wasn’t an efficient way to get sFlow data to a server. This capability will enable users to do things like set thresholds and get alarms for any criteria they like. In the past, most alarm criteria were defined by the switch vendor for alarms like the CPU is too hot or memory is too low. These things rarely happen in switches, but when they do you certainly want to know. It would be preferable, however, to monitor the CPU utilization by dynamically adjusting the threshold based on the telemetry data itself. For example, if the CPU is normally running at 10% during off-shift hours, but somehow spikes to 60% on a particular night, the telemetry data analyzer could automatically generate an alarm. However, if a CPU is usually running 70% busy around 9 a.m. because all staff are being authenticated at that hour, the telemetry analyzer would not trigger an alarm, even if the CPU was at 80%. This is just one example of how telemetry data can help the analyzer to observe and learn. The same technique can just as easily be applied to network security or performance monitoring. Event logs are another consideration. Right now, you can set up a system log server to collect data from a network device event log. But you can’t analyze it in real time because, again, there’s no efficient way to get the data to the server. gNMI provides just that mechanism. In short, gNMI provides a way to implement telemetry in an open, efficient, standards-based way. We are working on integrating it with our Linux-based network operating system, PICOS, so you’ll soon have an efficient way to stream data out of any network device. Automated troubleshooting and responseWhile using gNMI for network telemetry is new, it has long been used with servers and other IT infrastructure. So, once we have widespread availability of streaming telemetry from network elements, network and IT managers will have much better visibility into the state of not just the network, but the entire IT infrastructure. This is where we can expect AI to play a role, by analyzing the available data in order to identify root causes of problems. For decades, we’ve all struggled to troubleshoot application performance problems. Was it actually a problem with the network, or was it the server or the application code? By constantly collecting data from all the pieces involved in the IT infrastructure and applying AI, we can finally start answering those important remediation questions – in real time. The next step is to automate the response, which is what IBN is all about. You collect and analyze all the event data and, if it is a network problem, IBN automatically adjusts data paths to correct it. But none of this is feasible if you can’t efficiently collect the data in the first place. IBN also doesn’t work effectively if you’re not combining network data with event data from other components, including servers and storage systems. So, it won’t be just a single IBN server managing the network, but lots of servers monitoring different components. This is the IBN vision Pica8 is working towards. I fully expect we’ll have the gRPC-gNMI piece done around the end of the third quarter this year. From there, you can use our AmpCon open network services platform, or your own controller, to implement it. That’s what open networking is all about – choice. To learn more about the Pica8 vision for IBN, download our latest white paper, “An Open Approach to Implementing Intent-Based Networking.” Click here to try out PICOS or request a demo.
Welcoming Walmart to the Open Networking Community
Want to catch the latest in open networking? Head to your local Walmart store. It appears Walmart has bought into open networking in a big way. The company recently joined LF Networking, the collaboration ecosystem for Open Source Networking projects that is part of the Linux Foundation. “By joining LFN, Walmart has the opportunity to contribute, influence the cloud growth and better support the enterprise and service provider communities by open-sourcing innovative technologies across its retail infrastructure,” said Koby Avital, Executive Vice President, Walmart Global Tech. Those comments were echoed by Subhadra Tatavarti during her (virtual) appearance at the Open Networking & Edge Executive Forum 2021. Now with Wipro Ltd., at the time of the conference Tatavarti was Sr. Director Technology Commercialization at Walmart. She made it clear the move to open source was driven in part by the pandemic, which accelerated a trend that had already started: more traffic at the network edge. Traditionally, the bulk of Walmart transactions were in-store, not online. “What Covid has done is completely flip it for us. We’ve seen up to a 76% increase in e-commerce traffic,” Tatavarti said. (Many other companies experienced the same sort of change in traffic behavior, as I wrote about previously.) The increase in online activity was accompanied by another change in customer behavior. “More and more customers were buying online but picking up in store,” she said. In essence, stores were becoming fulfillment centers, which drove the need for additional technology in-store, such as for customer check-in and supply chain. Like many enterprises, Walmart has been adopting a hybrid cloud strategy. The company has 1.7PB of analytics data in the cloud for example, and its check-out applications are also cloud-driven, Tatavarti said. Over the past few years, the company has also been investing heavily in artificial intelligence (AI) and machine learning (ML) applications to drive operational efficiency. In thinking about the company’s edge strategy, Walmart had to decide which workloads would be hosted in the cloud vs. at the edge. “Workloads that can be deployed on edge are those that require low latency and fast compute,” she said. “Workloads like AI and AR/VR [augmented reality/virtual reality] need a fairly robust edge platform.” The same goes for video security systems and AI/ML-driven inferencing engines. This should sound like a familiar story. It’s been Pica8’s position for some time that the explosive growth of enterprise applications like AI/ML, IoT, Digital Health and Smart Buildings has overrun the ability of big networking-iron infrastructure to adapt to a distributed workforce/customer environment with Wi-Fi 6 as the last mile. Covid’s redistribution of the workforce has simply moved the problem to the top of the heap. But the way Walmart addressed the issue should give comfort to any company that has been considering an open source approach to networking – and other infrastructure. “It’s almost impossible to run an extremely large organization without the latest, greatest technology,” Tatavarti said. Which is why Walmart is a “huge consumer of open source technology,” including Node.js, OpenStack, Cassandra, Hadoop, and the Cloud Native Computing Platform. She’s right, of course. The beauty of open source software is that it’s constantly being updated, thanks to the contributions of the open source community. By adopting open source software, you’re basically taking advantage of the expertise of engineers at hundreds of large companies, like Walmart. What’s more, with an overall open networking strategy, you don’t have to wait for the next release from a legacy vendor in order to take advantage of the “latest, greatest technology.” With disaggregated networking, you can update your network operating system whenever it makes sense to do so from a feature/function perspective, while continuing to make full use of open source tools like Ansible, Puppet and Chef. The same also goes for the underlying network hardware. In terms of technology, that can put you months if not years ahead of legacy vendors with their outdated hardware and software upgrade schedules. Walmart has a GPU in every store to support security applications, payment and checkout systems, including self-checkout, all of which are highly sensitive to latency. The fact that the company is using open source edge network technology should be seen as a vote of confidence in open networking. And adopters will stand to benefit from the work Walmart is doing. One example Tatavarti cited is eBPF, which enables programmability within the Linux kernel, to add various features and functions. (Pica8’s PICOS runs an unmodified Linux kernel to enable just this type of use.) Walmart used eBPF to control the number of concurrent connections coming in and effectively manage them, to deliver a good customer experience without crashing the network. She also made reference to eBPF-based technologies for deployment of network functions and observability. “We are in the early phase of figuring out how to give back what we have done with eBPF to the developer community,” Tatavarti said. In terms of the open source community, “We hope we can become bigger partners and play a bigger role going forward.” Well Walmart, representing Pica8, the company that delivered the first open, Linux-based NOS in 2012, let me say welcome aboard. If you want to learn more about what open, disaggregated white/brite box networking can do for your network, check out our white paper, “An Enterprise Approach to White Box Networking.”
3 Reasons Pica8’s PICOS® is (Already) Flourishing Across the Enterprise
I read with interest a blog post about the open source data center network operating system (NOS) SONiC. To date, SONiC has been deployed mainly by hyperscalers and other large cloud data center providers with very homogenous infrastructure and simple use cases, but a recent Gartner blog post predicted it will soon be adopted by enterprises. Hence, Packet Pushers responded with a recent post titled, “3 Things SONiC Needs To Flourish In The Enterprise.” The “3 things,” it turns out, are already being provided by Pica8 via PICOS, our open NOS that runs on open white box/brite box switches, and AmpConTM: •Commercial support, a la what Red Hat provides for Linux•Commercial management, configuration and automation tools•Sales and marketing to promote disaggregation in general and this NOS in particular. Lots to unpack here, so let’s get to it. The Background on SONiC SONiC is a NOS developed by Microsoft for its Azure data centers. The company later released the code as open source software and it is now a sub-project under the direction of the Open Compute Project (OCP) Networking Project Group. A Gartner blog post published in mid-March (the Ides of March, to be exact, for what that’s worth) made this bold prediction: “By 2025, 40% of organizations that operate large data center networks (more than 200 switches) will run SONiC in production environments.” The post talks about switching vendors that are “aggressively investing in and/or support SONiC including Dell, NVIDIA, Arista, and Juniper” and others including Cisco that “allow SONiC to run on their switches.” The blog post really served as a teaser for Gartner’s just-released Market Guide for Data Center Switching, which, of course is only available to Gartner clients. But it also prompted Packet Pushers to take a closer look at the claim, serving as something of a gut-check. Now, keeping in mind both the Gartner and Packet Pusher posts are talking solely about data center NOSs, let’s take a closer look at those “3 Things.”1. Commercial support, a la Red HatPacket Pushers correctly points out that a commercial version of any open source software provides much-needed support, including patches, updates and more. A commercial vendor also handles the “fiddly bits” (I like that) with respect to the ASIC abstraction layer, so customers don’t have to. The vendor simply provides the customer with a list of compatible hardware and that’s that. I couldn’t agree more – and this is exactly what Pica8 does for users of PICOS. Our proven abstraction layer is called vASICTM, and our extensive hardware compatibility list is right here. 2. Commercial management, configuration and automation toolsHere Packet Pushers, again, correctly points out that SONiC is a Linux-based NOS and thus can be managed by tools such as Chef, Puppet and Ansible. It then adds, “but network engineers may want something more tailored to their discipline.” The post mentions intent-based networking as well as a desire for “stripped down, simplified, and cloud-based” management tools. This again struck a chord because PICOS is likewise Linux-based and, thus, manageable by all the same Linux tools. In fact, we’ve developed a number of Ansible playbooks specifically for automating networking tasks related to deployment, configuration, license management and so on. Beyond that, however, Pica8 also has an automation framework, AmpCon, that addresses network switch deployment and configuration, automation of day-to-day activities, visibility across the network, and policy enforcement. In short, AmpCon can be thought of as a “stripped down, simplified, and user-friendly” version of the cumbersome Cisco DNA Center. It performs the core functions that most enterprises need – at a fraction of the cost. (Actually, it’s almost free as Pica8 does not believe customers should have to pay through the nose for controlling their networks.) It even addresses open, intent-based networking (OIBN) in a way that enables companies to dip their toes in the OIBN waters and adopt it at their own pace. (Learn more about OIBN in our recent white paper.) 3. Sales and marketing to promote disaggregation in general and this NOS in particularThis may be the one area where I have to disagree with the Packet Pushers post. It posits that while hyperscalers and cloud providers have a clear business case for an open, modular, disaggregated, customizable NOS, most enterprises don’t care about such things. “They want reliable software; support for core protocols; and tools to configure, manage, and troubleshoot the network–ideally delivered by a vendor partner,” Packet Pushers says. Well, OK, but why not both? Wouldn’t an enterprise be interested in a NOS that is at once reliable, supports core protocols, comes with effective management tools, is supported by a commercial vendor – but is also open, and works on your choice of white box/brite box hardware and Linux tools? The post correctly goes on to point out the benefits of the open approach, including being able to more quickly take advantage of hardware and software advances, greater choice and the ability to swap out hardware or software based on changing requirements. The fact that it’s lower cost is gravy. These are points we’ve been making for quite some time. But there’s one more rather big differentiator with regards to Pica8. Recall that both the Gartner and Packet Pushers posts were discussing only data center NOSs. Pica8’s PICOS is a L3 data center NOS, but it works equally well in enterprise campus and edge networks and workflows. So, with PICOS you’ve got a single open, disaggregated NOS running across your entire enterprise – from the data center to the access edge and everywhere in between. It’s all managed by the same tool – AmpCon. And it comes with support from an experienced commercial vendor, Pica8. We don’t have to wait till 2025. PICOS is already flourishing in more than 1,000 enterprise networks in 40+ countries. If you’d like your network to be next, just get in touch.
Pica8 Earns Top 10 Spot on CRN.com's list of Cool SDN Networking Tools
There are far worse ways to start 2021 than to be named a company with one of “The 10 Coolest Software-Defined Networking Tools of 2020” by CRN.com. Even better, in these days of almost zero investigative technology journalism and pay-for-play marketing to get onto lists like these, it was a breath of fresh air to earn a spot on one of the endangered, merit-based “Top 10” lists where no money changed hands. So, a big “thumbs up” to CRN for putting Pica8’s open networking ThresholdTM SDN architecture right up there alongside Cisco’s DNA Center, Arista’s Adaptive Cloud Fabric, and Juniper’s Contrail Edge Cloud (among others). To riff off an old E.F. Hutton television ad, we made the CRN list “the old-fashioned way — we earned it.” CRN was motivated to put this list together because they foresee “a healthy growth outlook predicted for the SDN market for the next seven years.” Indeed, they should, as modern definitions of the SDN “market” no longer refer to the “over-exuberant” early SDN vision — and questionable business model — of replacing every network device on earth with the equivalent of a new flying car. Instead, “SDN” has morphed into the more enlightened view of discrete and, often automated, control of network behavior and security policies, which is exactly what “SDN” should refer to. (Ironically, in the very, very early days — before the fervor of university academics hijacked the software/hardware disaggregation movement entirely — this is what SDN was originally designed to do. What’s old is new again.) For the most part, this “new” definition of SDN also suits the traditional networking vendors just fine as they can now easily fit all of their proprietary — and uber pricey — software packages under the expanded SDN definition. This allows them to continue to sell generations of non-interoperable hardware — complete with built-in obsolescence — right alongside hugely expensive software suites, all without having to show any sort of even ephemeral roadmap involving SDN controllers, white box hardware, or open networking at all. And that’s a real shame. The dirty little secret hiding in this “new” world of SDN is that the state of the art in real open networking has advanced so far now that true open networking solutions, such as Pica8’s, mean that there’s no longer any engineering or ease-of-use reason to purchase expensive legacy networking solutions. Pica8’s PICOS® network operating system — the foundational building block of the Threshold SDN architecture — offers automated deployment and lifecycle management and is interoperable with not only existing legacy networking hardware but also with all major network access control (NAC) systems, such as Cisco ISE and Aruba ClearPass. It is the only networking solution on the market to offer users simultaneous control of every switch port in a network, whether L2/L3 or SDN/OpenFlow. Not even the legacy guys can do that. So, CRN, here’s a toast to you to start a bright New Year. And if you’d like to start your year by learning more about what a modern, open approach to networking looks like, download our white paper, “An Enterprise Approach to White Box Networking.”
The Benthic Sadness of Cisco Colony Collapse
Once upon a time, Cisco effectively was the networking industry, starting around the time I joined in 1989 to help the company put together its IPO. The cachet of being an early Cisco customer was very real, and, frankly, Cisco earned its moment in the sun back then, a moment that — to its full credit — lasted far longer than technology history would have deemed likely. In fact, one of the charts Cisco liked to show sell-side analysts during its IPO roadshow was a sine wave that demonstrated how no dominant technology leader of one “wave” ever became the dominant player of the next one. The mainframe leader (IBM) did not become the mini-computer leader (DEC), which, in turn, did not become the PC leader (Microsoft), and so on. The chart had a big “?” next to the empty sine wave slot for networking, which, of course, Cisco did ultimately win and happily filled in. (Not surprisingly, those sine wave charts have never seen the light of day since at Cisco as far as I can tell.) Now the new sine wave peaks are clear — Cloud, IoT, 5G and so on — and all have very little to do with Cisco today, leaving the company perhaps best described as “a dream of elegance on the crumbling edifice of the past” (to borrow an almost perfect phrase from the Japanese Wabi aesthetic). Today Cisco is way past worrying about cachet. It is, instead, forced to struggle with basic relevance while it goes about plundering its enterprise install base for revenue in a cash grab before AWS and crew turn Cisco’s high-profit bespoke hardware/software solutions into museum pieces. And open networking — inexpensive hardware plus inexpensive, but feature-rich, software like Pica8’s — in the enterprise campus is also amping up the existential pressure on Cisco. Almost every new open network campus deployment comes directly at the expense of some poor Cisco account rep who has to de-book that long-time customer from his/her forecast. Cisco knows all of this, of course. It missed the pivot to the cloud years ago trying to hold on to hardware gross margins, saw all the major web-scale data centers opt for open networking, and are now keeping a watchful — and nervous — eye on open networking’s increasing adoption rate in its cash-cow enterprise business. At some not-too-distant point Cisco will be forced to embrace the open networking business model and do more than just occasional head nodding and hand waving about its intentions here. But to those of us on the outside, that process is uncomfortably like watching the caveman invent the rock. As they’ve grown from my early days — when Cisco was a mere $27M/year revenue company — Cisco inevitably fell into a number of bad habits that largely stemmed from its basic DNA while the overall industry caught up and, in many cases, surpassed it in the market. Some of these habits — like making customers dependent on the complexity of its solutions to keep competitors out — worked, at least for a period of time. (I addressed some of these issues in earlier blogs like this one on Cisco’s “conservation of complexity problem.” Cisco was used to big margins from the start. It quietly raised the prices of its early routers twice just ahead of its IPO in 1990 to see just how much it could squeeze out of the market. Cisco never looked back and still tries to sell every customer an Airbus when the vast majority of them come in wanting, and frankly only needing, a Cessna. Simple, reliable, inexpensive, flexible and easy to operate is what customers are looking for. Kind of like the Cloud and open networking if you think about it. So Cisco, long known as “the masters of firmware,” is now desperately trying to reinvent itself as a software company via hugely expensive networking software suites. Exhibit A is the Cisco DNA Center automation framework, which can easily run into many millions of dollars to support even a modest-sized deployment. I almost hate to break it to Cisco that open networking now has a $10-per-switch-per-year solution in Pica8’s AmpConTM automation framework for open white box switches that does much the same thing. Amazingly, Cisco seems to think its enterprise customers won’t realize its luxury-tax software bundles like DNA Center and StealthWatch are as much vendor lock-down programs as anything else. Customers do, of course, and there are plenty of “look, the elephant is tip-toeing down the hall again jokes” flying around. In truth, as one of Cisco’s earliest and biggest promoters, this inevitable Cisco Colony Collapse is not particularly comfortable to witness. For me, one of the final nails in the coffin was the recent departure of thousands of Cisco’s best-and-brightest long-term employees in a combination of early retirement packages and layoffs. Anyone reading this post knows full well the “Check Engine” light is pretty much always lit in a large network, and Cisco, already under fire for lagging support, just said goodbye to many of the people who could respond despite its Covid-times pledge not to do that. In the early days Cisco could be thought of as the Burning Man of the networking industry — brash, innovative and responsive to the cultural and business trends. Now it’s more like Disneyland — bloated, expensive and full of customers waiting in very long lines. In closing, in addition to the Wabi reference above, Japanese aesthetics also embraces an element for “things that have lost their power,” such as the retreating figure of a sumo wrestler who has been defeated in a match. When I view what Cisco has become, this is the cause of the “benthic sadness” referred to in the title.
Why the Lights Just Dimmed at Cisco
In a clear echo of IBM’s ultimately futile efforts to cut costs in the early 90’s, October 5 was a watershed day for Cisco as over 2,000 of its best, and most senior, employees across the company took early retirement packages —technically, the Cisco Elect Program — and handed in their badges. We’re talking software engineers, SEs, TAC personnel, sales directors, product line managers, account managers, the works — most with over 20 years tenure at Cisco. Some of them had been with the company so long that I was actually their hiring manager at Cisco, and I left in 1995! As one member of the new diaspora put it on social media this week, “A lot of great talent that made Cisco is headed out the door today.” This new, diminished Cisco is worth a closer look. The people that “made” Cisco, who understood and represented its best interests, and who were trained in true customer advocacy, are leaving — in droves. And the 2,000+ that are now gone are just the beginning of this most recent talent outflow. In total, Cisco extended the ER (early retirement) offer to almost 7,000 of its top people. Many — perhaps most? — of the remaining 4,500+ who did not accept will now wait to see if they survive the coming layoffs that will be needed for Cisco to meet its stated goal of $1B in operational costs savings that Cisco told the Street about in August. There are two main themes roiling the Cisco alumni social media feeds about this event. One is the parallelism to IBM that I mentioned above, or, as another member of the diaspora stated, “It’s kind of sad to see Cisco playing the IBM game of layoffs and firings.” The other, far more dominant comment, is “there is life after Cisco.” While “There is Life After Cisco” is largely expressed in the forums as a form of personal encouragement for those who took the ER package perhaps less than willingly, it’s a phrase that current Cisco enterprise customers should also take to heart. With somewhere between 2,000 and 7,000 of Cisco’s best out — or on their way out — Cisco will be a less capable company when it can least afford to be. If you weren’t happy with Cisco responsiveness and support before, you don’t need me to tell you what’s coming. It’s fairly well accepted that Cisco already missed the overall industry pivot to the Cloud — and to Automation — so there’s obviously plenty of “life without Cisco” going on there. Now the combination of open networking and white box switching are proving to be an existential threat to Cisco both in the data center and, more recently with the strategic tie-up between Pica8 and Dell Technologies, in their home port of enterprise campus and access networks as well. If all 7,000 of the ER-targeted people do end up leaving, that will represent about a 10% reduction in Cisco’s overall workforce, a not uncommon number for Cisco to eliminate in the past. But, historically, those earlier reductions were for their worst performers, not their best. October 5, 2020 — a day that will likely be long remembered at Cisco. First, the company lost a $1.9B patent infringement case to a Virginia-based security company called Centripetal, and second, thousands of its best and brightest exited Stage Left.