Where AT&T Leads, Cisco Cannot FollowPosted By: Nati Shalom on April 26, 2016
The Innovator’s Dilemma faced by vendors of proprietary networking stacks is well documented. The blogsphere and the trade media have well documented the disruptive, one-two punch of open source NFV and white box hardware that threatens to undermine their business models.
But just this week, at OpenStack Summit in Austin, we saw Sorabh Saxena, Senior Vice President of Software Development & Engineering at AT&T showcase on a keynote stage before more than 7,500 people (plus the online audience) just how mature this disruption is. His company, faced with multiplying demand for networking capacity over the next four years, has embraced NFV and white box hardware not so much as an inoculation against vendor lock in (though this is part of it), but as a necessary tool for agility and speed.
And yet, the existential threat to companies like Cisco is present, real and almost certainly the end of an era. In this post, I’ll explain what is happening and what we all should do.
But first, a bit of background.
Open Source has been at the center of some major disruptions in the high-tech industry. Linux changed the entire operating system landscape. Hadoop, MongoDB, Cassandra and now Spark lead the disruption in the way we manage data. Android changed the entire mobile world to name a few.
The networking world has been very late to join this open source disruption and was kept for a long time behind a walled garden. It didn’t take long for the wall around this garden to come down.
We are now facing a time in which open source disruption is hitting the networking world and making big waves in the form of NFV and SDN, and, like other similar disruptions, the first to be hit by that disruption are the incumbents like Cisco.
Get our free NFV White Paper today. Go
As in other, similar disruptions, the first reaction by those incumbents is denial which is later followed by other tactics such as camouflage (if you can’t beat them, join them). But, at the root of many of those disruptions sits the big elephant in the room. Those publicly traded companies have an inherent conflict of interest with this open movement that is rooted in their business and revenue model. A conflict that can’t be bridged easily just by sponsoring or even contributing to open source projects.
As with previous disruptions, this revolution will spawn a completely new generation of companies that was born to lead this disruption.
For the past three years, I’ve been actively involved in this movement and I’m still seeing lots of confusion that mostly comes out as fear of change by some carriers who want to join the movement but don’t know how.
So, for this post, I wanted to share my perspective on how carriers should respond to this change and avoid the risk of moving too late to a technology that is already fundamentally transforming telecom.
I’ve chosen Cisco as the representative of the incumbents, although their use case can be applied to the stories of other vendors of proprietary networking stacks.
Open Source NFV Initiatives Gets Real
The NFV open source movement has gained serious momentum over the past two years, with OpenStack being the main driving force behind this, by providing an open source substrate to sustain the NFV movement.
This has led to an influx of projects with a more specific NFV focus that have emerged over the past year, such as OSM which is led by ETSI, as well as OPNFV and Open-O which are under the auspices of The Linux Foundation.
Other projects such as Tacker (a Brocade-led NFV orchestration for OpenStack, project) and ARIA (reference implementation for TOSCA) have also been created to support those initiatives. The fact that open solutions for complex, full-fledged NFV environments are even available on-demand, demonstrates the speed at which the NFV revolution is moving.
Open Source Reshapes the Way Standards are Being Defined
What’s interesting is that standards bodies such as ETSI and MEF, which traditionally used to work in long cycles and in fairly closed discussion groups, are now redefining themselves to fit into the open source paradigm, and are embracing open source technology as a means to drive new standards.
The MEF, for example, will even be running an open Hackathon around a new flagship initiative, LSO (Lifecycle Service Orchestration), as a way to define their new API. Clearly, this is a big change in the way standards are defined in the telecom world.
AT&T Leads the Open NFV Agenda, a Tectonic Shift
AT&T recently announced their Enhanced Control, Orchestration, Management and Policy project (ECOMP) during the the Open Networking Summit. The project proves that open source can actually support the core backbone for one of the biggest carriers.
At the OpenStack Summit yesterday, AT&T won the OpenStack SuperUser Award for their contribution - the announcement includes fascinating statistics that show the scale at which AT&T invested in adopting an open source based stack, which includes 70+ OpenStack deployments with plans for 90% growth. They also trained more than 100 of their employee to learn how to work and contribute to OpenStack.
This, on top of the Orange Labs functional testing of OPNFV (although much smaller in scale) - another great use case that was presented on OPNFV last year - highlights another big shift that is happening as a result of this open source movement. The Orange Labs example illustrates how open source enables telecoms to build their own infrastructure without being dependent on the “high touch” vendor dependency of yesteryear.
Open Standards for NFV Orchestration and Modeling Gets Wider Acceptance
TOSCA is at the center of many of the new open orchestration projects and is becoming the clear winner of common orchestration modeling languages. Project ARIA, which was announced during Mobile World Congress 2016, is a new, open source project that aims to provide a reference implementation of TOSCA and make it easier for both network providers and carriers to embrace the standard through a simple library.
YANG is also known to be a popular modeling language for defining networking devices widely embraced by the networking community. Until recently, there was a big debate in the telecom world whether YANG should also become the standard modeling language for orchestration. The ability to combine TOSCA and YANG integration is gaining wider acceptance now, as this approach seems to provide the best of both standards - where TOSCA is responsible the service lifecycle and YANG controls the network configuration of the VNFs.
The Open Source Disruption in NFV and Cisco’s Built-in Conflict
Cisco is one of leading network providers and it is no surprise that NFV needs to fit into the center of its strategy. Cisco is also making fairly big investments in aligning itself with the open source movement, specifically around OpenStack, but there's one issue with this that stands out.
The Elephant in the Room
A quick look at Cisco’s revenue model for 2015, outlined here, reveals an internal conflict with their joining the open source movement (the 2016 reports shows a similar breakdown).
We can clearly see that Cisco’s primary streams of revenue come from selling network devices, and therefore moving to a software defined networking model would come at the expense of their current physical device business model.
Selling open source based solutions drives a completely different business and revenue model, and, despite all the effort that Cisco has invested in open source, these will never serve as a new growth engine at the levels that Cisco used to sell before.
Another point that is important to note in this regard, is that open source often comes with a demand for an open ecosystem by the users, i.e. carriers, in this case.
Cisco, on the other hand, was used to “playing solo” when it comes to networking, and their solution was built as a full Cisco stack. Cisco even went as far as buying companies that led new standards such as tail-F that led the YANG model & support.
Obviously, this model doesn’t fit well with the the open movement, in which carriers are looking for flexibility to choose their own stack, and not being dependent on a single vendor.
This puts Cisco in serious conflict between where the market is heading and its current business model. For publicly traded companies that are measured by their quarterly bottom line, it is hard to see how Cisco could make a shift into this new world without a complete shakeup similar to the one we've seen recently with Dell & EMC.
Cisco is Not Alone
While I chose Cisco as a means to demonstrate the dissonance faced by leading networking vendors in the wake of an open source revolution, they obviously are not the only player that will suffer a big hit by this disruption at the heart of its core business. Other players such as Ericsson, Nokia, and Amdocs, similar to Cisco, in being used to selling proprietary stacks and turnkey solutions, are also exposed by this disruption.
Maturity is Not Enough
The only advantage that Cisco and the other “high touch” players have is the maturity of their stack and brand.
Indeed one of the leading current deficiencies with choosing the open source route right now is the maturity of the stack, as many of the open source players are still fairly new and there is no such thing as a “fast forward” on maturity.
Open source solutions are also often times built out of many moving parts, which requires a completely different skillset and organizational structure for adopting and embracing an open source strategy.
Having said that, it is clear that if we follow the maturity argument on any of the examples that I mentioned before, we would have chosen Oracle over Hadoop or MongoDB, or Blackberry over Android we now know clearly that those who have taken that route have lost the game completely.
In addition, maturity can be a fairly tricky thing as many of the “mature” solutions are, by definition, built out of old architecture and concepts. So, by choosing those solutions you're basically betting on building your future stack on technology of the past. That’s not going to work - sorry.
AT&T serves as a great example of how telecom organizations can overcome this limitation, by building an infrastructure and an organizational structure that fits with this open movement.
Final Notes - The Blackberry vs Android Dilemma in NFV
Many of the carriers are now evaluating their first steps toward NFV. For many of them this journey looks scary, as they have gotten accustomed to being “hugged” by the big vendors, and all of a sudden need to take ownership of their own stack.
At the same time, starting a new NFV initiative using old habits is worthless, as it will probably cost even more than the current system.
Instead, carriers should learn a lesson from previous disruption, follow in AT&T’s footsteps, and be careful not be tempted to buy into the “big hug” from their old partners who now find themselves in a conflicting position with their business goals.
Let me explain what I mean by lessons from previous disruption:
- Learn to work with new vendors - Carriers should be ready to work with new players that come with open source DNA and open source business model. While many of these players may be new to the market, and less mature by the old-world standard, they have much stronger alignment with the carrier's business goals and could play better as a “change agent”.
- Partnership with multiple vendors vs turnkey solution by a single vendor - Carriers should adopt a partnership strategy with their vendors and less of the old customer/vendor relationship, in which the expectation was to find a single vendor that will deliver a turnkey solution for all their needs. To do that, carriers need to adopt an integration strategy to allow faster adoption of new technologies by different vendors as well as simplify and shorten the business engagement process, and with that, reduce the barrier for new vendors thus increasing the competition and reducing their costs.
- Control your stack and cost - In this world, carriers need to also have that development skillset in order to have much stronger ownership of their stack and therefore cost.
- Embrace webscale best practices - The shift toward cloud-based infrastructure requires a shift toward a cloud-native strategy. Rather than reinventing the wheel it’s best to learn from the best practices of other industries that have made the shift toward cloud, such as Netflix, and embrace webscale best practices such as continuous development, automate everything, containers etc.
A Path Forward—What We Do Next Matters
The bottom line of all this is that carriers that want to survive this disruption have to learn how to control their stack as this is the only way in which they could control their costs and speed of innovation. Without it, they stand no chance of winning at this game.
Unfortunately, there's no shortcut and this move is going to be painful—but we could still make it smoother by introducing new ideas to shorten the learning curve such as the new NFV lab and making the product simpler to use as well by better aligning and collaborating with others who face similar challenges, even if they are competitors, because the challenge is far greater than one organization can solve.
Major consumers of networking stacks have shown us a path forward. Forged in the hackathons of open source projects, and powered by the silicon of white box ODMs, NFV is no longer an idea with a few, isolated test cases. As AT&T showed yesterday before an audience of thousands, the technology is mature enough to deploy globally in dozens of data centers, forming the framework of networking plant that will manage network traffic for, arguably, the world’s most trusted brand in network performance.
So, what should we do? We should do all we can to join hands with telecom operators worldwide to advance these open source technologies. Incumbent vendors have nearly zero incentive to do so. If we want to be a part of the revolution that will redefine networking, we need to help the side with the most to gain from success.
Let’s not set ourselves up for a similar destiny to that of Blackberry, or Nokia for that matter.