Skip navigation

The last blog (Will Cisco’s Insieme Networks Acquisition Rain on VMware’s NSX Party? – Part 1) spoke about how Cisco’s network hardware market dominance is being threatened by a number of factors with the most prominent ones being SDN and VMware’s network virtualization solution called NSX. Let’s take a look at Cisco’s answer to these threats.


Today’s  frenzy is about Cisco’s acquisition of its own spin-in startup Insieme Networks , which is billed as the company's answer to the combined market threats of commodity hardware, SDN-enabled legacy hardware and network virtualization from VMware in the form of NSX.


Insieme – SDN solution or SDN killer?

The Insieme answer named Application Centric Infrastructure (ACI) and Application Policy Infrastructure Controller (APIC) is hardware based and application-centric, unlike VMware NSX that is software-centric, providing Cisco’s counter-argument to the NSX software-first approach. Cisco seems to be betting big that the Insieme technology not only marginalizes the irritant of SDN, but can keep NSX in check as well.


Interestingly the Nexus 9000 switch includes both custom silicon ASICs and commodity silicon. Open standards-ish support for limited SDN capabilities are provided like the separated data and control plane, OpenFlow, or even Cisco’s own onePK. That should help maintain the loyalty of admins who love Cisco and want SDN.


Cisco’s ultimate answer to SDN is called ACI with APIC. With custom silicon, the switch performs better and provides more features at the cost of incompatibility with open standards SDN. The advantage here could still be with Cisco. Cisco’s history of performance, scalability and its application-centric nature, where the network is made aware of the application demands rather than application behaving according to the network, may resonate with customers more than networks that are quick to set up and reconfigure.

Get Your Popcorn Ready

Networks exist to deliver application services and every network admin strives to provide the best performance at the lowest cost. With Cisco promoting ACI as a solution for application-aware networks, users may still see more value with ACI than with NSX. Cisco has also painted software-centric approaches like NSX as not scalable, providing limited multi-hypervisor support and an integrated security challenge. It is yet to be seen what troubleshooting and monitoring looks like on NSX.

It’s most likely that Cisco will continue down the middle path like it has done with the Nexus 9000, supporting both SDN and custom silicon but recommending users stick with single-vendor hardware if they’re concerned about scalability, performance and features that commodity SDN or NSX cannot provide. So, while ACI may not kill SDN or NSX, it may dampen VMware’s vision of market share conversion without ACI clouding the NSX landscape.

Cisco’s primary revenue has been its hardware with custom silicon and software that provides highly scalable networking for enterprises, data centers and telecommunication industries. That threatens to change with networking vendors using off-the-shelf silicon to build commodity hardware, with only software differentiating offerings from competitors. Hardware from these vendors not only provides near parity performance with established ASIC-centric products but is more affordable, threatening Cisco‘s market share.


The threat from SDN

Adding to the threat is that non-proprietary hardware actively encourages and supports software defined networking (SDN) as a differentiator. With datacenters getting bigger, operators seek hardware that is not only inexpensive but is also easy to manage and quickly reconfigurable when changes have to be made. SDN delivers that promise, providing flexible networks at lower costs than established vendors. Using SDN, datacenter operators can separate the physical network from the control plane, enabling easier programming and quicker management of their network. Enterprises with huge data centers, such as Google, Amazon, Apple, Facebook, etc., have already moved to in-house developed SDN using commodity hardware.


VMware – Friend or Foe?

VMware, like Cisco, offers proprietary solutions that work well within its own ecosystem. They are also Cisco’s partners, like with the 1000v. But VMware changed this relationship with the acquisition of Nicira, a pioneer in SDN, for $1.2 billion. After seeing the advantages of server virtualization, enterprises and network admins are looking to run their entire datacenter offers on a compelling alternative. VMware NSX takes a software-centric approach, a path different from Cisco’s hardware-centric solutions.

NSX network virtualization, though it separates the control and data plane, is not the same as SDN.  According to Martin Casado, OpenFlow creator and chief architect of networking at VMware, “Network virtualization and SDN are two different things and somewhat incomparable. SDN is a mechanism and network virtualization is a … solution”. Something else about NSX is that it can work on any hardware, be it custom silicon hardware like those from Cisco or general purpose hardware and that I believe gives NSX an advantage over SDN. SDN requires hardware that supports OpenFlow or similar SDN protocols, which means capex for upgrades or new hardware.

Some might believe that competition from NSX vs. SDN is good for Cisco by changing the conversation away from open standards SDN. But after watching an NSX demo, VMware’s claims it can provide large datacenters the ability to bring up a scalable network in minutes leveraging on existing hardware was impressive. And existing hardware includes both proprietary and open solutions. Rather than simply knocking SDN out of the picture, this approach also cuts directly at Cisco’s proprietary SDN-alternative vision. To add to this, many of Cisco’s rivals such as Juniper, Dell, Arista and Brocade are eagerly supporting integration with VMware’s NSX network virtualization platform.


For many years it has been Cisco vs. everyone else. NSX and SDN are now out to change that and provide alternative platforms. But Cisco has an answer, let’s look at that in part 2 this coming Tuesday.

In October, SolarWinds acquired Confio, maker of Ignite database performance software.  In the DBA community Ignite is well known and widely used by top tier DBAs and database developers.   For the rest of the SolarWinds community, here are the key points that will help explain what makes Ignite such a popular solution.

  1. Response Time Analysis.   From the very beginning, Ignite was built to measure the TIME it takes for the database to respond to queries.  And Ignite does not just measure time to complete a query, but tracks the time spent on each step along the way, identifying the resource bottlenecks that most contribute to the delays.  

    Why is this important?   The purpose of a SQL Server, Oracle, Sybase or DB2 database is to deliver a query response to an application.  Knowing whether the server is busy doesn’t help the application user if they are waiting on a slow database.   Rather, the key to delivering better application response is knowing which bottlenecks are causing delays and how to fix them.

    Think of a real life comparison.  If you want to minimize the time it takes to drive to work, your best bet is understanding how much time is spent at each stop-light on the way, then figuring out how to avoid the long ones (Wait Time).   That is more effective than focusing on how fast your engine is running (CPU or server health).     More about Response Time Analysis.

    Ignite measures the time spent at bottleneck steps called Wait Types or Wait Events, then analyzes and tells the DBA or Developer how to get faster results. No other tool gives the same wait details, or ties them into Response Time Analysis. 

  2. Big Bars Bad.   Response time data is complex, with hundreds of Wait Types for every query processed, along with many other details like execution plans, locks, programs, users, and objects touched along the way.   Ignite makes it simple, clearly showing response times in the form of bar charts at every level of detail.   When you look for a problem in Ignite, just look for the “longest bar”, because that is the most critical problem to focus on.    Ignite users know that the longest bars are the key to their performance issues, and quickly learn from Confio that Big Bars are Bad.   Nothing else is as simple.
    Which query is the biggest problem?

  3. 4 Clicks to the Problem.   Serious DBAs use serious tools, and some of them have extremely complex screens of statistics that few DBAs or Developers can understand.  Ignite excels at making it easy to get to the root cause of the problem, typically in about four clicks.  This means that everyone on the DBA team, application developers, or managers can use Ignite without specialize training.  
    By clicking on the alarms that indicate problems, and following the big bars, Ignite users get right down to the root cause.   More details on Ignite.

Section of Ignite home screen, with red alerts designating the first click to find the problem

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.