Data centers

10:47 AM
Greg Ferro
Greg Ferro
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%
Repost This

Cisco ACI: Proceed At Your Peril

Cisco's new SDN platform, Cisco ACI -- despite some positive features -- is confusing, unproven, and burdened with Cisco's complicated past.

Cisco's new SDN platform -- despite some positive features -- is confusing, unproven, and burdened with Cisco's complicated past.

Cisco's recently announced ACI strategy is going to be tough to sell to customers. It's confusing and only one of several Cisco SDN strategies, and it doesn't ship until mid-2014 at the earliest. In the meantime, other SDN vendors are shipping real products and customers are using them. The challenges Cisco ACI has to overcome, combined with the company's sad history of failed software projects, will make many customers think twice.

In a previous article, I looked at the features and functions of Cisco ACI, and explained all the benefits that ACI brings to the table. This article examines the challenges and weakness in the Cisco's ACI SDN strategy.

Lacking leadership

A few weeks have passed since ACI's launch, and I've had time to take a more critical look at the details. The most interesting comment I've heard was that ACI is "entirely predictable and lacks leadership." It is clear that many perceive ACI as a "me too" SDN strategy. Cisco ACI is similar to all other SDN strategies: Network controllers, network applications, and software services combining to provide automation and orchestration is now a well-known story in the networking industry. For those who are interested in SDN, Cisco is obviously late to the market, launching with a marketing strategy containing few details and an incomplete product announcement.

Cisco dominates the networking market today with a hardware-centric product focus. Therefore, delivering a hardware-centric SDN vision in the early days is an obvious choice for the company. Customers who don't understand SDN might feel assurance that Cisco is articulating some long-term strategy. But more advanced buyers are still searching for the reasons why custom hardware is necessary for SDN. It should be noted that ACI also has a software-only capability, but it was largely buried at launch.

While there were a lot of expectations leading up to the ACI launch, the result was a "promise of futures." Cisco will ship a few products to selected customers in the next year or so for early testing. The only product available before year-end is a low-cost 10 GbE switch made from Broadcom Trident silicon. Cisco is struggling to maintain market share in that segment.

Tough sell

The ACI platform has many moving parts including software and hardware, and will take years to achieve momentum. It took Cisco 90 minutes to explain the entire product and technical strategy to me. Customers are being asked embrace and buy into Cisco's very specific and very large network vision of the future. It's a vision that leaves a lot of questions unanswered.

Adopting ACI will require strategic engagement to change the entire infrastructure strategy in the datacenter. Implementing a single ACI instance will require wholesale change to some long-held business models governing change and operational management through automation. Many companies are still using ITIL business models that drive a project-driven change model with limits on initiating change. It is not clear how Cisco ACI will convince customers to replace longstanding business processes and overhaul networking.

One of ACI's strongest features is that it can integrate with and even "emulate" your existing network. In practice, this could lead to sales questions about the value of networking anyway and may steer customers toward alternate vendors.

Customers may also take pause when they consider project complexity in terms of deployment and professional services. Cisco has a checkered history of developing software; consistently failing to develop or maintain products during the last decade. A long line of failed software products from acquisitions or internal development suggests a systemic business problem. Customers remember abandoned strategies like Application Oriented Networking and products like CS-MARS and CiscoWorks. Some will question whether Cisco can do software, as well as its commitment to all of its products.

In addition, the hardware-centric model has some risk. If Cisco continues to focus on hardware as its core value proposition, then it may not be able to make the transition to software and applications. Remember that Insieme started as a software spin-out because Cisco felt it was not able to innovate and create software internally. That Insieme incorporated hardware products into ACI at the last minute suggests that parts of Cisco feel the only possible solution is a hardware solution.

Another warning will be understood best by those who remember the last major spin-in of Nuova Systems, which resulted in Cisco UCS servers and Nexus 5000/2000 switches. The early versions of these products had poor software quality and almost no features. Cisco has worked diligently to smooth out the pain points, and five years later the products are stable and reliable enough. Customers are right to question early versions of ACI that have resulted from a rushed startup. Who wants to be stuck in a cycle of hardware upgrades for new features such as those required for UCS and Nexus hardware?

Some last words of caution relate to the partnerships that Cisco publicized to demonstrate commitment to the ACI platform. Those same vendors signed up to partner with VMware and a number of other vendors. The current rumor mill suggests that Cisco is mulling a purchase of Embrane. If that were true, such an acquisition would put Cisco at odds with many of its "partners," because Embrane does network orchestration for load balancing, firewalls, and more.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
kiliasov
50%
50%
kiliasov,
User Rank: Apprentice
12/23/2013 | 4:26:52 PM
re: Cisco ACI: Proceed At Your Peril
You have a strong point there. Like any other architecture/framerwork/approach from Cisco - ACI is focused on securing it's place on top of the hill. It's just the way it is.
It does look like another long-cooking arch. play - Borderless Networks. Which is still not fully realized after 3 years. That said, I think ACI has better chances to succeed since it was designed from scratch, there's less legacy luggage to weigh it down and concept is new and attractive to enterprise customers.
That comes at price off fully committing to Cisco view of the word with no elegant way out. And I agree that more and more customers are not willing to subscribe to that view.

p.s.
Nowadays the badge says - Network as the Platform :)
afewell
50%
50%
afewell,
User Rank: Apprentice
12/17/2013 | 10:25:06 PM
re: Cisco ACI: Proceed At Your Peril
Great post Greg,

I also want to congratulate Joe on the launch, its not the way I would have done things or the approach I would take, but it is a more programmable and software driven approach. At the end of the day I suspect there will be some more common models for SDN, but I hope we never get back to the way where networking was where everybody had to do everything the same exact way. I think OpenStack lays the groundwork where, with time, hopefully users will be able to transfer there complete workloads and policies freely between infrastructure vendors and cloud providers.

Where I really fault Cisco both with UCS and ACI is, they really want to convince the market that we all need them to do this for us because certainly none other than the great Cisco could solve networking problems. And that is just so full of FUD its crazy. Why is it that enterprises want to do elastic cloud networking and self service ... is it because Cisco was pushing this? NO! This model was driven by cloud providers and now enterprise IT is clamoring for it because their execs have seen it working in the public cloud.And even after the public cloud was already delivering elastic cloud networking for distributed computing, Cisco comes out with UCS and regardless of what you may say about it, it was built for the opposite traffic pattern of distributed computing. So nice try to build a closed converged management model, but built on FEX's? Could there be anything more myopic? And it was all completely unnecessary as both self-service and elastic networking were already working in production over more open technologies and architectures.

Now Joe you were right when you pointed to Google's demonstration at the 2nd ONS and highlighted how no enterprise could do similar, Google had to create all the software. But the key point of looking at Google here is that they manage to do all the magic they do using standard components driven by flexible software. Google, Amazon etc were already way ahead of Cisco on delivering next-gen networks, all over standard, low-cost gear (eg F10). Clearly enterprises need someone to do the software piece if they wanted a google-like model, where was it that we needed all the proprietary to go along with that? The industry is changing Joe, look at OpenStack and OCP - while I think you guys getting into openstack is great, isnt there a bit of cognitive dissonance in putting out a solution for OPENstack that requires closed & proprietary hardware and even locks-in customer workloads and policy?

So I would ask, are google and the web 2.0's all going to adopt ACI & APIC? Because if not, what is it exactly that we NEED ACI to do for us? Is it really the only way to deliver next-gen networks? Or is there a more open way that is already way ahead of where Cisco is delivered in a way that is more commensurate with how the open x86 industry has worked. Another good question here is, what will Open Compute Project standardize on? I would be beyond shocked if the ACI model were standardized for OCP.

For elastic networking and self-service, I dont see anything ACI would be able to do that there arent already more open ways to accomplish.

But then we get to policy abstraction with APIC and to me it seems like this approach is misguided. I think Cisco knows that the vast majority in enterprise are not aware of what telecoms and the internet2/GENI community have already been working on this exact problem for years, at least since Directory Enabled Networking in the late 1990's. There are already numerous research projects and industry initiatives working on this challenge, but we all know from history this aint going to work with one vendor trying to play bully about how to do it. This seems to me to be the same problem that killed Cisco's SONA. Something like SONA should have happened, but you simply arent going to get all the app providers happily bowing down to Cisco's network-centric myopia and bully tactics. Bottom line is that solutions dont only emanate from the networking domain, but all the Cisco stuff will come packaged in a vehicle they think they can most effectively execute upon - e.g., the solution to all problems is the network since that is where Cisco has the dominance. If Cisco ever gets dominance in any other category, I imagine that would change.

Another clear proof point here is VMware. Cisco is out claiming that only a vertically integrated approach that marries hardware and software will work. But really? Think about server virtualization. A decade ago, I could only virtualize a few workloads and when I did there would be wild imbalances between cpu/ram/disk. Over the past decade the industry solved those challenges and provided a consistent annuity of value to enterprise IT. And we solved it together as an industry, and at the end of it all not only the dominant VMware is better, but for enterprise consumers they have more robust virtualization choices than ever before where vmware, msft, xen etc ALL got the hardware improvements needed at as fast as a pace as was possible and the ultimate benefit went to the consumer who has more choice than ever. But, that is how the open x86 industry can work, a far cry from the mainframe-like networking industry, UCS shows that Cisco is bringing the unhealthy monopolistic practices with them from the networking industry and now trying to bring those same negatives to other domains. And Joe, I dont mean this as an attack, I am not saying the Cisco solution wont work I am sure you'll get it working. But its definitely not the only way, its definitely not the first to deliver elastic networking, it seems highly unlikely it would ever become the norm for public clouds and that alone should provide assurance to customers that it is simply a means to an end and definitely not the only good means to the same end. There are plenty of ways to innovate forward in a more industry friendly manner, and that is my recommendation to customers not just for ACI but for any proprietary tech - in my view there is only one time where proprietary should make sense, and that is if there is a CRITICAL business need and no functional open solution. That should be the cost of any innovator of proprietary tech, they should have to be sufficiently ahead of the market to create a business benefit large enough to compensate for the well-known downsides of lock-in, and in my view there is no way Cisco has done that here. They havent done anything new, they simply have taken things public cloud providers have already implemented in production and re-envisioned them in a proprietary and vertically integrated cloak which is completely unnecessary and only really stands to benefit Cisco - imho.

In my view Cisco will continue to struggle from the 'innovators dilemma' in this regard imho. So much of Cisco's problems can be explained by the paradox .... one side of the Cisco badge card says "No Technology Religion". the other side of the card says "The Network is the Platform" - and they are stuck in that paradox.
ReturnoftheMus
50%
50%
ReturnoftheMus,
User Rank: Apprentice
12/17/2013 | 2:35:56 PM
re: Cisco ACI: Proceed At Your Peril
Ooooh, that was scathing, however the transition to software and services was never going to be easy, especially when 3 out of earned $4 earned comes from shifting boxes.
Overall, I'd have to say (in the Greg vs. Joe debate) I think Greg just edges it eventhough the article itself was rather incoherent. In particular I thought that the abandoned strategies were well highlighted, all too often we've seen Cisco marketing get way ahead of themselves, promising the earth then silently discarding their grand initiatives, hardly what you'd class as being committed to their own cause.
However, you'd have to credit Joe for providing some much needed clarity, thankfully I can now view ACI as a new methodology, the Nexus 9000 Series as a new spine/leaf architecture and the APIC as an different type of SDN controller, I think?
Joe Onisick
50%
50%
Joe Onisick,
User Rank: Apprentice
12/16/2013 | 2:47:27 PM
re: Cisco ACI: Proceed At Your Peril
Nexus 9000 in NXOS mode utilizes optional VxLAN (standard) and standard routing/switching protocols. ACI relies on VxLAN and ISIS for it's topology (standards). I'm not sure what's convoluted there? Additionally SPB only solves the bridging problem which is a small portion of what SDN or ACI is working to solve.
PMITCHELLNA
50%
50%
PMITCHELLNA,
User Rank: Apprentice
12/16/2013 | 12:06:15 PM
re: Cisco ACI: Proceed At Your Peril
While everyone is tripping over themselves trying to come up with an SDN strategy, we have Shortest Path Bridging shipping and in use TODAY. Advantages.... It's an IEEE standard, proven multi-vendor support and best of all... simple. Vendors like Cisco come up with convoluted, proprietary solutions that eventually lock you in. But hey. As an industry, we like it so.
Joe Onisick
50%
50%
Joe Onisick,
User Rank: Apprentice
12/16/2013 | 1:05:49 AM
re: Cisco ACI: Proceed At Your Peril
Chris,
I absolutely agree with you, nobody is expecting a deep end dive into ACI. Documentation is rolling out weekly and emulators that include data plane capability will be released as we move forward.
Especially with a new operational model customers will want to test and engage in small environments, we welcome that. I think two of our advantages here are a) the hardware can be tested in advance of the ACI model, b) if the ACI model doesn't turn out to be right for a given deployment the Nexus 9000 offers a wide variety of benefits in it's NXOS mode (meaning you didn't by an advanced doorstop if you choose not to go with ACI.)
I appreciate the feedback!
Joe
ChrisKane
50%
50%
ChrisKane,
User Rank: Apprentice
12/16/2013 | 12:43:56 AM
re: Cisco ACI: Proceed At Your Peril
While Greg's post could have been tempered a bit more, I agree with the cautionary tale. Much like Doug's comment, customer and partners alike would likely be best served by a wait-and-see approach.

Regardless of vendor, how many of us would suggest installing something with less than six months of time on the street? Whether you work for an enterprise or support one, installing something so new into the production network is rarely viewed as a good idea. It seems that all of a sudden a philosophy of recommending gear just because its shipping is a good idea.

Perhaps the wait-and-see approach can be mended a bit if the infrastructure you are proposing to introduce this gear into is of an isolated, subset area. In other words, not the heart of a business critical data center.

The added benefit of letting these ACI and Stand Alone related products bake a bit will be letting the details and design guides associated with them get published and refined. If Cisco wants to reduce the delay then we need more documentation, emulators and stick time. Both for Stand Alone and for ACI.

A tempered approach will prove prudent for all of us that depend on successful implementations.

Thanks for a stirring debate,
-chris
TelcoWelder
50%
50%
TelcoWelder,
User Rank: Apprentice
12/15/2013 | 11:48:33 PM
re: Cisco ACI: Proceed At Your Peril
Hard to argue with the facts!
ToddC904
50%
50%
ToddC904,
User Rank: Apprentice
12/15/2013 | 10:52:24 PM
re: Cisco ACI: Proceed At Your Peril
There goes Joe's Xmas card from Greg...
Joe Onisick
50%
50%
Joe Onisick,
User Rank: Apprentice
12/15/2013 | 10:36:31 PM
re: Cisco ACI: Proceed At Your Peril
**Disclaimer I work as a TME for the Cisco BU responsible for Nexus 9000 and ACI, I am biased**

Now, with the professional act of claiming my bias out of
the way I thought IG«÷d add some color and technical accuracy to your opinion piece. LetG«÷s start at the top:

G«£despite some positive features -- is confusing, unproven, and burdened with Cisco's complicated pastG«•

ACI being confusing may have more to do with the audience, and pre-conceived notions/ideas in this case.
Plenty of customers worldwide are quickly grasping the power and potential of the ACI model. Unproven is simply silly, itG«÷s a new methodology so like all other new methodologies itG«÷s unproven. There is no G«ˇprovenG«÷ SDN
technology available today, there are technologies being tested and used in limited fashion for the purpose of proving them.

G«£Cisco's recently announced ACI strategy is going to be
tough to sell to customers. It's confusing and only one of several Cisco SDN strategiesG«•

ACI is not an SDN strategy. ACI is a methodology for deploying applications based on a common framework for operations and development teams and the simple concept that application requirements are defined by connectivity and policy. SDN focuses on defining existing network constructs with software. Openflow is
all about 5-tuple matches trying to identify applications/traffic based on network information. Network virtualization simply replicates the network and identifiers into a hypervisor shifting cost and management around without moving the needle forward from a business perspective. A conversation about SDN is a networking conversation, an ACI conversation revolves around G«£how do you deploy applications and what do they require?G«•

Cisco has several SDN solutions, as they should, providing customers options is not a bad thing.
XNC, OnePK and OpenDaylight are fantastic options for customers and all supported on the Nexus 9000 platform which can optionally be software upgraded
to ACI.

G«£It is clear that many perceive ACI as a "me too" SDN strategy. Cisco ACI is similar to all other SDN strategiesG«•

ACI is a far cry from other SDN offerings. As stated above SDN focuses on the network, ACI focuses on the application. With ACI network configuration becomes irrelevant and instead you focus on logical configuration of connectivity and policy based on application needs. Even the APIC controller is the exact opposite of SDN controllers. SDN and network virtualization controllers try to reinvent the wheel by pulling forwarding and address distribution into the controller. This lacks scalability and is unnecessary. To put that in perspective imagine building an OpenFlow controller for the internet (hint: not going to happen.)

Within ACI the APIC is only in charge of connectivity and policy for applications, forwarding is built on time-tested ISIS topologies between VxLAN VTEPs and forwarding tables are populated by natural learning
with no need for flooding and no latency penalty for using the 1,000,000+ hardware address database. The APIC controller never sees a packet or frame and is never part of the data path for any reason.

You actually contradict your own point further down with G«£Adopting ACI will require strategic engagement to change the entire infrastructure strategy in the datacenter.G«•
If both of your statements were true this would mean that all SDN solutions require this, luckily both statements are incorrect.

To continue on changing business operations in the data center: yes ACI enables better business models and operational models, yes ACI can further enhance DevOps practices, no ACI doesnG«÷t require that. Like Cisco UCS these processes can be advanced through the operational model, but RBAC and maintenance features can be used to maintain the existing models as is, ITIL or otherwise. More importantly customerG«÷s operational models can grow fluidly within the system as those models evolve, change is good Greg.

G«£While there were a lot of expectations leading up to the ACI launch, the result was a "promise of futures.G«•

Are you arguing that we announced ACI too early? I assume thatG«÷s based on your vast product marketing and product management experience?

G«£The only product available before year-end is a low-cost 10 GbE switch made from Broadcom Trident silicon.G«•

This is 100% inaccurate and a simple Google search would have helped you there. The Nexus 9508 modular
platform is currently shipping with 36x 40GE port line-cards. This platform offers the industry leading full line-rate 40G density at 288 ports in 13RU. 10G and fixed options will be available early next year, on time and on target. Yes the price points on our 40G platform are low,
and lead the industry without sacrificing value add.

Saying G«£Cisco is obviously late to the marketG«• is not news, John Chambers stated this himself: G«£We waited too long to addressG«• SDNs (http://www.networkworld.com/ne.... Recognizing this is the first step to correcting it which is what ACI does.

G«£The ACI platform has many moving parts including software and hardware, and will take years to achieve momentum.G«•

IG«÷m sure you said the same about UCS which was a combined hardware and software model and extremely successful (see below for details.) The fact is this is a policy driven model which started with the concept of what is required for deploying applications then designed software and hardware from the ground up to support that.

G«£It took Cisco 90 minutes to explain the entire product and technical strategy to me.G«•

IG«÷m sure the person who spent 90 minutes with you would have appreciated that information at the time, rather than in this format. With most audiences the light bulb starts lighting very fast and no more than 30-60 minutes is required to understand whatG«÷s being done. Every audience is different I suppose.

G«£One of ACI's strongest features is that it can integrate with and even "emulate" your existing network. In practice, this could lead to sales questions about
the value of networking anyway and may steer customers toward alternate vendors.G«•

IG«÷m not sure where youG«÷re going with this one. ACI does not G«£emulateG«• a network, thatG«÷s the ATM Lane-esque network virtualization solutions. The logical build of an ACI deployment can utilize existing network constructs for grouping objects and applying policy, i.e. keep using VLANs and subnets. At the same time the model opens up a world of possibilities for grouping objects completely free from network constructs for the purpose of connectivity and policy.

G«£Cisco has a checkered history of developing software; consistently failing to develop or maintain products during the last decade.G«•

With any large vendor some products succeed and some do not. Where Cisco has been very successful with software driven models is in cohesive solutions. Cisco UCS is a great example of this. Cisco UCS ties together a new software driven operational model with stateless compute hardware to deliver compute services. Four years into UCS the incumbent vendors still donG«÷t have an answer and Cisco UCS is a $2B annual run-rate and #2 in blades. You spend plenty of time trashing UCS in the article but the numbers and customers speak for themselves.

G«£In addition, the hardware-centric model has some riskG«•

Calling ACI a G«ˇhardware centricG«÷ model will get you more
views but isnG«÷t accurate. The ACI model is a policy driven model. The policy model weG«÷re building will be contributed to OpenStack Neutron, OpenDaylight and
OVS. The model itself has no hardware requirements. We use the Nexus 9000 and extensions into other Cisco products to accelerate what ACI offers through hardware. I know that using hardware to accelerate software is a new concept, it has only been used since, well since forever. For example all of that magical software virtualization stuff on the server side is accelerated via virtualization feature sets built into the x86/64 processor. Networking today doesnG«÷t have that, so we built it.

G«£That Insieme incorporated hardware products into ACI at the last minute suggests that parts of Cisco feel the only possible solution is a hardware solution.G«•

A combined hardware and software model was always the intent of what Insieme was building. We wouldnG«÷t have hardware shipping now and custom ASICs shipping in the beginning of the year if they werenG«÷t in development from the get go. Again, itG«÷s best to note
unverified opinion as such, and back facts with some reference.

G«£Insieme started as a software spin-out because Cisco felt it was not able to innovate and create software internally.G«•

The Cisco spin-out model is well documented and proven. It is not based on lack of capabilities within Cisco but on several business factors including:

Dedicating people to a specific task without the
tie to prior day job. Accelerated deployment and innovation. Attracting new outside talent. Etc.

G«£Customers are right to question early versions of ACI that have resulted from a rushed startup.G«•

In what way is Insieme a rushed startup? Is that based on the company being started with a specific intent and set of timelines and meeting/exceeding those? Innovation can happen more quickly with the right funding up front. An advantage of the spin-out model is up front capital which allows for teams to be brought
online and integrated quickly. Spin-outs donG«÷t suffer from the trickle effect of multiple funding rounds.

G«£Some last words of caution relate to the partnerships that Cisco publicized to demonstrate commitment to the ACI platform. Those same vendors signed up to partner with VMware and a number of other vendors.G«•

VMware is 90% market share leader in hypervisors, Cisco 70% in networking; partners will work with both because itG«÷s profitable for them and exposes them to new customers. At the size of both companies there are always bits of coopetition, just ask Juniper about their virtual firewall experience with VMware.

Hopefully this clears up some facts and detail for your
readers.

Cheers,

Joe
Page 1 / 2   >   >>
More Blogs from Commentary
Edge Devices Are The Brains Of The Network
In any type of network, the edge is where all the action takes place. Think of the edge as the brains of the network, while the core is just the dumb muscle.
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
VMware's VSAN Benchmarks: Under The Hood
VMware touted flashy numbers in recently published performance benchmarks, but a closer examination of its VSAN testing shows why customers shouldn't expect the same results with their real-world applications.
Building an Information Security Policy Part 4: Addresses and Identifiers
Proper traffic identification through techniques such as IP addressing and VLANs are the foundation of a secure network.
Hot Topics
3
Converged Infrastructure: 3 Considerations
Bill Kleyman, National Director of Strategy & Innovation, MTM Technologies,  4/16/2014
2
Heartbleed's Network Effect
Kelly Jackson Higgins, Senior Editor, Dark Reading,  4/16/2014
White Papers
Register for Network Computing Newsletters
Cartoon
Current Issue
Video
Slideshows
Twitter Feed