The popularity and success of server virtualization has enabled the datacenter to become extremely well automated. This has allowed the datacenter to respond to business needs faster and with greater levels of efficiency. The problem is that the underlying network infrastructure is still wedded to a highly physical design that requires a great deal of hands-on manual process that is slow and inefficient. SDN and network virtualization speak to the heart of this disconnect between datacenter practices and network operations. No matter which type of SDN or network virtualization approaches you embrace, it is not possible to have a discussion without the mention of APIs (Application Programming Interfaces).

APIs can add programmability to almost any platform. However there are caveats. Not all APIs are created equal. Not all APIs are well documented. APIs can go away or become very restrictive at a vendors whim.  For example, you may or may not remember last August when Twitter started to “lock down” or become more restrictive with how and who uses their API. The reasons given were that Twitter wanted to monetize the platform and they felt that the changes they have made would allow them to do so. There are many blog posts and comments on how and what those changes mean. This particular article on that topic I found an interesting read, because it got me thinking about what that means to SDN, as so many folks are embracing an API approach to SDN and network virtualization. Sure APIs do by definition make a platform more programmatic, thereby giving users great control and customization of how they use a particular resource and how it integrates with their infrastructure. However, the Twitter story is a cautionary tale. The vendor owns the API. If you build a business or perhaps plan to move your entire infrastructure over to an SDN model that relies heavily on vendor supplied APIs, it is important to fully understand what that means and if that could become restrictive or problematic over time.

The future of networking is NOT going to revolve around CLI. I believe very strongly that it will require network engineers to be able to program. Jeremy Schulman (@nwkautomaniac) spoke at Networking Field day and recommended that “If you don’t know how to write something in Python or Perl or even Java, you need to begin picking it up.” He even suggested the online website called Codecademy for network engineers to dip their toes in the programming waters. Be careful what you wish for; if you asked for greater programmability of the networking infrastructure then it means learning a new skill set or risk being left behind.

Tools like this have become the defacto workhorse in the datacenter for provisioning, configuration management, and orchestration of VMs. From what I understand, since Puppet is a declarative programming language it encapsulates a larger construct that obfuscates the underlying complexity of programming and gives it a Jean Luc Picard-like power to point & click to “make it so”. This helps lead to more automated deployment processes in the datacenter.

The NOC, in sharp contrast, has remained stubbornly resistant to automation and EMA has research data that supports this phenomenon. One of the major sticking points has been and continues to be change & configuration management of network devices. The process is largely manual, making it slow, inefficient, and subject to errors. This is particularly bothersome for sysadmins, when they make a request to network operations as part of a deployment scenario, say for a new VLAN. The networking component has quickly become the long pole in the tent.

Configuration management and new resource allocation have been a thorn in the network administrator’s side forever. There was a brief flurry of activity around what is commonly referred to as NCCM (Network Change and Configuration Management) tools, but the market evaporated after a series of acquisition by large system vendors.  That market struggled to find footing and only the most progressive networking departments appeared to embrace the technology. However, the glaring disconnect between the automated datacenter provisioning, configuring and allocation process and the manual networking one is becoming more problematic. So it is no small wonder that datacenter sysadmins are attracted to the promise of overlay network solutions and the allocation nirvana it hypes.

Could it be Puppet to the Rescue?

Could this be the one language to rule them all?  The Puppet language has been designed not only to configure servers, but networking and storage as well. Puppet Labs began incorporating the ability to configure networking devices into its product release around this time last year.  In the initial release, support was limited to Cisco devices, however a subsequent blog post here indicates that F5 devices can also be managed using Puppet, through modules that advantage of the iControl API. In January, Puppet Labs introduced a new module for managing NetApp storage devices.

The Juniper Puppet for Junos OS is actually still in early adopter release, and is composed of two software components:

• A native Puppet agent and libraries, which are installed on Junos OS devices. This is distributed as a Junos OS package.
• The netdev Puppet module is a vendor-neutral network abstraction framework developed by Juniper Networks and contributed freely to the DevOps community. The module provides new resource types for basic network abstractions such as VLANs.

The Junos OS devices appear as just another “node” in the Puppet managed infrastructure.

We don’t know yet how network administrators will feel about running Puppet agents on networking equipment, which would give sysadmins the freedom to allocate resources at their whim. However, we cannot ignore the roadblock that network processes are creating in the datacenter and DevOps. It might be time for network administrators to at least become familiar with Puppet, so that they can understand how it works and interacts with networking equipment. Puppet on networking devices is still in the early stages, but I believe its full potential has not yet been realized. It may turn out to be the point at which true convergence can begin. If nothing else, it seems like it might be a good starting point.

The road to true network virtualization is going to be long and arduous. But perhaps some of the first steps are about solving some basic sticking points, so that we can begin to move the conversation forward, rather than having networking be the boat anchor that holds back the rest of IT and the organizations they support.

Who said that network virtualization has to follow the lead of datacenter dictates?

The first step to true network virtualization is not about workarounds, APIs, and overlays, but the decoupling of the operating system from the hardware platform. In mid February, Juniper Networks invited me to attend an analyst day and discuss their recently announced efforts around SDN. Juniper is taking this to heart. One proof point is that they hired Bob Muglia from Microsoft and he is a software guy. Bob is determined to shift Juniper from a hardware-oriented company to one focused on software and services. Bob Muglia is a 23-year veteran of Microsoft where he ran Microsoft’s $19 billion a year Server and Tools Business. Muglia is created for successfully growing sales as well as improving operating margins, so he has the software and business creds, but the challenge lies in prioritizing software within a networking company.  This is no easy task for any networking company. Juniper brought in a heavy hitter to coalesce and drive Juniper towards a more software-oriented architecture. Juniper’s recently announced revamping of its licensing strategy is an important first step in that direction which I already discussed in a previous blog.  My take away from the Juniper meeting was that Bob has a vision and he has no intention of minimizing the role of the networking component, but rather has his eye on adjacent touch points like load balancing. Once you start talking software, watch out, because now networking guys can climb up that same OSI stack that everyone else is clamoring to reach down into by building that functionality into their core operating system. Remember NetManage? They sold a TCP/IP stack until the TCP/IP stack became a part of the Windows operating system.  Network equipment vendors have operating systems that can be extended.

Cisco is taking a slightly different approach from Juniper, and some will argue that they are further ahead. The problem is that Cisco’s efforts appear a bit more scattered and disjointed, so it is hard to get a clear picture of what the final product will look like. However, Cisco is working towards building greater programmability through APIs, controllers, and overlays, but of their own making. Cisco Open Network Environment (called Cisco ONE) includes the One Platform Kit (onePK), which provides a set of APIs for developers that work across Cisco’s routing and switching operating systems. Other efforts include a controller that is rumored to be in the works under the spin-in company Inseime. Cisco’s recent acquisition of vCider will provide the basis for the overlay component. I would suspect there are other competing efforts within Cisco that will eventually solidify as the most promising solutions win favor. I also fully expect Cisco Prime, the management platform, to play a bigger role in this strategy moving forward. While the Cisco approach does need time to firm up and coalesce, it is very much well underway. Cisco has both a vast installed base as well as a legion of CCIEs to draw upon to drive their virtualization efforts forward and it would be a mistake to think that they cannot change the game.

Also, in case you doubt the ability of networking vendors to leverage their position into new markets or adjacent markets take a look at the recent Arista Networks announcement around their new tap aggregation solution called DANZ (Data ANalyZer). This clearly takes aim at Gigamon, NetScout and Big Switch, all who play in the network monitoring switching space. This is a small adjacent market and not one we would expect Cisco to have an interest in, but it underscores the ability of networking vendors to go after new markets. If the game is to commoditize the core routing and switching functionality, then you can be sure there are other areas in which these companies can find purchase.

SDN is a catalyst for networking vendors to find ways to make their environments more extensible, and to me that means having a predatory eye towards adjacent markets and even moving up the stack. Just like with server virtualization, network virtualization does not mean the underlying physical infrastructure simply vanishes. The physical networking gear is not going away, but rather it is evolving. Yes, SDN and OpenFlow might have forced the change sooner rather than later, but there is a lot of engineering talent at all these companies and they will rise to the challenge. There is no reason for them to play by rules set out by other vendors. The network touches everything and if networking vendors are going to retool their internal designs, then you can be very certain they will do so to ensure greater functionality, and that includes stepping into and over adjacent markets to remain relevant, protect their position in the market and at the same time being responsive to customers changing needs. No small feat, but these are not small companies to be trifled with. Stay tuned, because I think it is only going to get more interesting.

With this announcement Juniper is take the first step in decoupling the operating system from the hardware platform, which is kind of network virtualization step one. Think of this as the client/server movement for networking equipment. Step one – decouple the operating system from the hardware platform, but that is not so easy or straightforward. Typically the operating system is both embedded and wedded to the hardware device that it ships on. It is not transferable. When companies go through a network equipment refresh that means all new operating system licenses must be repurchased in addition to the equipment. Juniper is proposing a new licensing model that:

• Decouples the operating system from the hardware permanently, implementing a “VM”-based application design.

• Creates licenses that are not just transferrable, but that can be moved across different architectures, such as x86 or different cloud-stacks, whether they are public or private. This is a game changer.

• Pay as you go licensing model and a move away from software keys and true-up penalties – the bane of software license administration.

• Perpetual Lifetime licensing– I would like a dollar for every customer conversation I have had that starts, “We had no idea our maintenance license had expired.” In the new model the software license and maintenance will always be current and supported.  No more software expiring with underlying hardware – all updates, bug fixes, version upgrades are included.

Server virtualization has worked out very well and reduced the datacenter footprint and, more importantly, has allowed datacenter IT to address the rapid pace of change in today’s business environment. The natural assumption is “Well, why not use the same approach to virtualize the physical network infrastructure?” In short, it hasn’t worked out that way.  While many would be quick to place the blame squarely at the feet of the networking equipment vendors, it is just not that simple. The problem is that everyone seems to forget that server virtualization did not transpire overnight. Not too many years ago, server hardware, operating system and application platforms were welded together. It took a long time and many technology shifts – in particular, client/server along with commodity server platforms and more intelligent client devices.

The virtualization of the networking infrastructure will happen in steps. While overlay networks attempt to jump-start the movement, the reality is that overlays still rely on the underlying physical network, so it is just a work around. True virtualization of the networking layer is going to be hard and it is going to take time. Anyone who thinks it is going to be easy or any one vendor has the problem solved is going to be sorely disappointed.

And to be very clear, APIs are not a solution. It just foists the responsibility of connectivity back to the poor networking engineer who has to write and maintain the scripts that work with the flood of APIs hitting the market all in the name of SDN nirvana. Juniper is proposing a logical first step in decoupling the physical equipment from the operating system layer. For everything else, the APIs and SDN platforms (that are really middleware) are just jury-rigging to get to networking programmability and do not represent a true change to how things are done at the network layer. True SDN is about changing how we build and design our networks, but the reality is that this change will take time and lots of false starts before this becomes reality. Kudos to Juniper for taking this first major step toward true network virtualization, because I feel confident that they will still be in the game when all these fly-by-night SDN players are dust in the wind.

Related articles

• Juniper finally talks SDNs (networkworld.com)
• Juniper finally talks SDNs (computerworld.co.nz)

First and foremost, the people currently driving this effort the hardest are service providers and not the average enterprise network engineer. Service providers are always on the hunt for ways to reduce CAPEX and increase service based revenue streams. That is not to say that enterprise IT shops do not want to reduce CAPEX spending, but what is good for the service provider is not necessarily good for the enterprise, at least not yet.  While service providers often have teams of engineers that can design, build and support custom deployments, enterprise environments often lack the same depth of internal resources.  So for now it would appear and we plan to test this in an upcoming research report, enterprise networking pros are still largely in the research and perhaps early testing phases of SDN, but not yet deploying this technology. Further digging has also led me to believe that SDN is bifurcating in two major directions – one that addresses the needs of the system operations teams responsible for server virtualization deployments and one that addresses the needs of network operations teams responsible for physical networking hardware.

Two Approaches – Two Audiences

Currently two SDN approaches appear to be gaining the most attention: one that centers on SDN controllers and is mostly being driven by equipment vendors and the other initiative emphases building overlay networks.  The first approach is the one that centers on separating the forwarding and control planes and would make use of a software-based controller to handle the communication between the physical and virtual components.  A number of vendors such as IBM, NEC and HP have SDN controllers today. This method would have the best use case for network engineering teams that want to either flatten or simplify their physical networks that have become fragmented and difficult to expand. In theory this approach would allow them to more rapidly address performance issues since it would reduce the need to physically move cables or racks of equipment.

The second approach would be to create an overlay network that tunnels through existing network infrastructure, but that runs and is configured independently. VMware began adding the bits and pieces of this within their core platform and will seal the deal with the integration of Nicira.  The audience, the server virtualization team, can create private tunnels between their own internal infrastructures and/or one or more cloud service providers without direct involvement of the network operations or engineering teams.

Shades of Gray

What is not so clear is how things like soft switch/vSwitch technology will play into both of these approaches. Are they going to be the glue between the physical and the virtual? Soft switches are already out and in the market, so do they side with the controller approach or the tunneling approach or can they play both sides? Also what about monitoring and troubleshooting regardless of which approach, who owns that, who provides the tools? No one has said boo about the role SNMP will play, but clearly someone needs to take up the gauntlet and either extend existing SNMP MIBs or write new ones. There is much at stake here as everyone jockeys for position. VMware’s clear intention to take on the whole network virtualization puzzle its own way is clearly putting it at odds with vendors such as Cisco.

At the same time this message clearly resonates with the IT consumer community, who feels current network designs are becoming roadblocks to remaining competitive in the market. There are other signs of vendors trying to address this frustration. While Cisco’s onePK provides a set of network device APIs to improve network programmability, it is an interim step not a long-term solution. OpenFlow-based SDN controllers are already on the market and if a culture can grow up around them, fortified with features that would improve cross platform interoperability and greater application awareness, this could at least (for the near term) keep existing networking solutions relevant and viable as the market evolves and comes more into focus.

At the end of the day, I just do not see these two initiatives resolving themselves into a single clean cohesive solution, but rather fragmenting along the way drawing into question both scalability and interoperability of these approaches as they mature. This is about making existing infrastructure more flexible and adaptive and at the very least both initiatives address it in their own way.  It hearkens a change to the status quo, but whether for the better or worse in the near term it is hard to say. In any case, networking remains a hot topic and SDN will be the buzz for 2013.

Related articles

• Brocade bolsters its SDN game, buys Vyatta (zdnet.com)

While the general announcement focuses on what will be accomplished in each of the three target areas of cloud networking, cloud orchestration, and mobile, it is the how that is most intriguing.  To achieve this goal Cisco is swapping out its own ADC (application delivery controller) product, ACE, in favor of the Citrix NetScaler solution. In case there was any doubt, check out the link that once and for all puts to rest any questions regarding the fate of the Cisco ACE product line. The web page is titled “Welcome Cisco Customers”.  You will note that Cisco will “continue to fully support existing customers of its Application Control Engine (ACE) product line”, but the future is clearly with Citrix NetScaler.

The plan is for Cisco and Citrix to jointly integrate the Citrix NetScaler application delivery controller (ADC) to coexist with other Cisco network and security services, such as Cisco Wide Area Application Services (WAAS) and Cisco Adaptive Security Appliance (ASA). But wait – WAAS? That is Cisco’s WAN optimization platform. What does this mean for the future of Citrix’s own WAN optimization platform Branch Repeater? Now here lies an area of contention. Both companies have WAN optimization products that fit the branch, datacenter, and mobile client.  If WAAS becomes the defacto datacenter solution, which appears to be the intention, then it seems logical to want to use the same code base for the branch and mobile WAN optimization clients. Citrix does not break out individual product revenue, but in looking back through various SEC filings even though the Branch Repeater is considered part of the NetScaler product group it is unclear how much of that revenue it is generating on its own. Previous references dating back to 2011 indicate that Branch Repeater revenue was at best flat and other references give the impression that the product was struggling to find purchase among the Citrix buyer base. Citrix has a good product team supporting the Branch Repeater, but if it comes down to the numbers and balancing the Citrix/Cisco partnership against time to market demands, then it is hard to imagine the companies juggling the resources necessary to keep both sets of products current moving forward.

The SDN Catalyst

Clearly there is a trend afoot among not just networking vendors, but all IT infrastructure players and the catalyst is SDN (software defined networks). SDN, even in its infancy, is a disruptive initiative. It threatens the status quo; therefore vendors are looking to solidify their position and figure out how to best position themselves to ensure their ongoing relevance in the market. Companies are eyeing emerging SDN-oriented companies and gathering them into their fold, with Cisco grabbing vCider and VMware snapping up Nicira. More will follow. Vendors are reviewing their own portfolios and jettisoning efforts that are not making headway, Juniper Networks just killed off their own WAN optimization controller, announcing an EOL of the WX/WXC solution in favor of reselling and promoting the Riverbed solution. Riverbed has been slowly and carefully expanding its value proposition and solidifying its position in the datacenter, expanding into ADC and application-aware network performance management.  It is interesting to watch which companies are developing closer ties, like Cisco and Citrix, and those which might be drifting farther apart, like Cisco and VMware. It marks an end to the status quo.

This is clearly a group effort, kind of like watching a bike race with each team jostling for the ideal position, but with the best results coming from working in tandem. That is not to say there won’t be some wheel suckers in the mix, however this is not a one-man race, but an evolution of the network, as we know it. It will take time and the power of the collective minds of many smart individuals to make the shift from concept to reality.  We have a long way to go and it looks to be a very interesting ride.

Related articles

• Cisco, Citrix forge ADC alliance (networkworld.com)

The stimulus for this blog came about after I read a recent F5 case study that talks about the use of the BIG-IP Local Traffic Manager (LTM) and BIG-IP Global Traffic Manager (GTM) ADCs to provide high availability and fast-loading web pages for a digital food content provider. This study is a great example of delivering web content, on a global scale, to multiple device types over the public Internet 7×24. This case study highlights two interesting points. First, it points to the challenges of using the public Internet for content and application delivery. Second, it demonstrates the criticality of performance and in this case it is a make or break factor for this particular business model.

The customer is Allrecipes.com – a content provider that specializes in topics pertaining to food, primarily as a large global community recipe swap. Before you give a derisive snort, first look at the numbers. The company claims a membership base of 7 million users with 25 million unique visitors to their sites each month and over 750 million visitors on an annual basis. The company experiences extreme seasonal traffic spikes with the largest being just prior to and on Thanksgiving Day resulting in a doubling of typical traffic volume from 1 million pages viewed per hour to 2.2 million. The company requires that a web page load in less than 1 second. The company maintains four global datacenters and has websites in 17 countries and the content is localized from the corporate headquarters in Seattle. Customers access the site from 160 countries worldwide. The company has also begun publishing applications for tablets and smartphones that tap into this content. The company maintains blogs as well as being active on social media sites such as Facebook and Twitter.  The primary challenge for the company is to be able to deliver this content 7×24, globally, on multiple device types. The reason that Allrecipes.com implemented the F5 solution is for primarily the following reasons:

• No single point of failure
• Consistent levels of performance regardless of point of access or type of device
• Ability to offload tasks from the web servers to the F5 devices
• Ability to customize through iRules to gain specific performance tweaks
• Reduce page load times to under 1 second
• Ease of use and management
• 7 x 24 support

As enterprise customers look towards the public Internet as a delivery mechanism, lessons can be learned from companies such as Allrecipes.com. When making use of the public Internet there are aspects of the delivery model that you no longer have control over. So it is very important to test the viability of deployment over the Internet to make sure performance falls within reasonable parameters under a number of different conditions such as geographic location and device type. The next step is to determine where the sticking points are in the model and decide if there is anyway to iron out the wrinkles. If the web servers are subject to traffic spikes, then an ADC/LB would be a big help in evening out performance problems during high traffic volumes. If the problem is more complex and exists along the delivery path, then there are many options ranging from classic WAN optimization solutions for branch connectivity over private WAN links to a multitude of hybrid solutions that take advantage of both private and public Internet connections such as those from Akamai, Talari or Aryaka to name a few. Pushing applications out to the Internet is not as simple as it might appear at face value and requires careful strategic planning for not just performance concerns, but security issues as well. So before embracing the Internet as a low cost delivery mechanism, understand that it requires a support infrastructure to ensure its success.

You may still be wondering why I chose this example – it is because it points to how rapidly and globally our consumption and distribution of content has evolved. This simple little community recipe swap has morphed into a four datacenter, globally distributed entity serving up 2.2 million pages of content per hour during seasonal spikes in traffic. People are accessing content from their device of choice (DoC) 7×24. If you don’t think that this will impact how the corporate enterprise interacts with its own customers and employees, then you are asleep at the networking switch. Long before the dusts settle on the fabric/SDN/OpenFlow debate, corporate enterprise IT departments risk fighting a losing battle to control content, device, and access, if they do not find a way to embrace the shifting sands of consumer driven compute and demand.

On April 3, Blue Coat announced version 9.0 of the PacketShaper operating system that runs on the Blue Coat PacketShaper appliances. The focal point of this announcement, in addition to added support for video and other rich media, is IPv6 visibility. Blue Coat makes a case for what you don’t know might be hurting you. Blue Coat argues that the growing number of IPv6 enabled endpoints (i.e. smartphones and tablets) coupled with dual stack implementations of routing code, address management, and WAN services (with IPv6 turned-on) are generating new unseen traffic on the enterprise networks, which Blue Coat is calling “shadow networks.”  In a report by Arbor Networks, DDoS attacks are being reported on IPv6 enabled networks. The report goes on to state that network operators are concerned about having sufficient visibility and mitigation capabilities to protect IPv6-enabled properties. Users expressed further concerns that IPv6 security features were not yet on par with those found on IPv4 devices.

While Akamai’s business model requires that they adopt IPv6 sooner rather than later, even though only .5% of their current Internet traffic is IPv6 today, Akamai has spent nearly two years getting its network infrastructure ready. Akamai has dedicated a web page to IPv6 readiness and migration. In April, Akamai began rolling out built-in IPv6 support for its major product lines. What is worth noting is what was uncovered in the testing process. First, Akamai observed malware, which is already out there and can scan and attack sites over IPv6. Second, Akamai also discovered that several major ISP networks are not peering with each other over IPv6 and thereby causing backbone routing issues. For a globally distributed enterprise doing IPv6 on their own, it would mean that some percentage of IPv6 clients might experience connectivity issues which may be difficult to detect and troubleshoot from inside the corporate data center since the problem is on the service provider end.

Options for the Enterprise

Any business with an outward, public facing Internet presence does not want to prevent legitimate IPv6 traffic from reaching its web-based applications. However, the prospect of updating all the firewall, networking, and web server equipment to accommodate IPv6 is a daunting prospect from both a resource and financial perspective. So what can an enterprise do in the near term to protect against IPv6-based threats on their network? There are two possible options that do not require a major forklift upgrade to the existing infrastructure. Companies that have existing ADCs can leverage built-in IPv6 Web Application Firewalls (WAFs) and other IPv6 enabled security features available on these devices if they have not already done so to prevent DDoS attacks and help mitigate security risks that IPv6 traffic might represent. A second option would be to leverage services like those of Akamai, in which case Akamai servers become the public facing Internet. Since, Akamai servers are already dual-stacked configured, customers do not need to make any changes to their backend infrastructure. Either of these options provides at least an interim step to protect against threats from IPv6 until internal IPv6 policies and upgrades can be fully implemented. In the meantime, it seems that security issues and concerns might just be the tipping point for IPv6 readiness and adoption. It would also appear to be a point of convergence for IT security and networking teams to work together, since visibility and mitigation in this case, go hand in hand.

Note: For more information on IPv6 enabled ADCs, Network World recently preformed a Clear Choice test on IPv6 enabled ADCs.

Thoma Bravo is a private equity firm that focuses on making investments in established companies, primarily in the US, that have a history of profitability and with earnings greater than $10 million. They do not invest in startups, but rather established businesses. Thoma Bravo implements an approach that is referred to as “industry consolidation” or “buy and build” investing. Network infrastructure vendors fit nicely into their model that looks at “fragmented industries to identify high-potential sectors.” This approach would not be possible without the willingness to understand the business and how it plays in the market as a whole. Thoma Bravo looks for ways to grow revenue through internal as well as external stimulus. Thoma Bravo seeks to find synergy between companies and integrating them to expand their revenue opportunity. The current technology portfolio contains a mix of storage, security, management, and networking infrastructure companies. In some cases the companies are stand alone entities and in others such as Attachmate, Thoma Bravo created a privately held enterprise software holding company, Attachmate Group and through that holding made further acquisitions that include: Attachmate, NetIQ, Novell and SUSE.

Most recently Thoma Bravo has had an eye on networking infrastructure vendors and in February 2012 acquired Blue Coat Systems (web security and WAN Optimization) for 1.3 billion. In April 2012, the company invested almost $11 million dollars to acquire a majority stake in InfoVista (network management targeted largely at service provides) and take the company private.  Then again in April 2012, Thoma Bravo took a controlling interesting in Network Instruments (network and application performance solutions) of which the financial terms were not disclosed. In conversations with both Blue Coat and Network Instruments the overall impression was a positive one with both companies very excited over the infusion of cash into their business. Both companies were comfortable with the Thoma Bravo business model and felt it would allow them to grow the business more quickly than they could have on their own. Network Instruments is a perfect fit for Thoma Bravo and meets the criteria as a mature company with solid revenue growth. In January, Network Instruments reported that their 2011 revenue grew 21% compared to 2010. Blue Coat made a few missteps in their attempt to take on Riverbed head to head when they acquired Packeteer in 2008. At the time Blue Coat was publicly traded and direct comparisons between Riverbed and Blue Coat’s WAN optimization were not favorable to Blue Coat. With this acquisition Blue Coat is no longer publicly traded.  This will give Blue Coat time to regroup and get their WAN optimization story more in line with their core strength, web security, rather than trying to go head to head with Riverbed. InfoVista has been in the market for more than 17 years as a network management player with a solid presence in the European telecom market. InfoVista is no longer publicly traded. Spending by European telecom providers has been slow to recover making it difficult for InfoVista to grow revenue.  Thoma Bravo is focused primarily on US-based companies, so perhaps this can translate into some new US-based market opportunities for InfoVista.

The IP Network is a Critical Business Element

This is a good time for network infrastructure vendors. The growing dependency on the IP network within the enterprise makes the network a critical business element. Security, performance, and managing the health of the network are crucial components regardless of whether the technology is in a local datacenter or in a hosted cloud environment. Thoma Bravo is making investments in components that will remain critical now and for the foreseeable future.

The Thoma Bravo business model is about investing in established profitable companies, not start-ups or failing entities. There is good news here for customers, because Thoma Bravo only invests in organizations that they feel have genuine growth potential. The company is reportedly hands off, but does monitor company financial progress and will restructure the company if necessary for greater profitability and efficiency.  This is a much better scenario than if any of these vendors had been acquired by another large IT vendor. Network infrastructure vendors who are acquired by large IT companies rarely enjoy a long period of autonomy, if any, and the talent typically departs shortly after any contractual obligations are filled. In this case, the companies get the benefit of cash inflow, but without the heavy hand of bureaucracy and culture shifts found in large takeover acquisitions. Chances are good at least for the near term that the companies will be reinvigorated and without Wall Street breathing down their necks can better focus on the business at hand. This is a win/win for both customers and the vendors. There is even potential synergy with these three acquisitions, as we look forward towards greater IT role consolidation moving forward. It will be interesting to watch and see how this progresses.

OpenFlow and SDN

While server virtualization has decoupled the application from the underlying hardware neither has been decoupled from the physical network. The networking layer has remained stubbornly physical with little or no sign of moving away from that model. There are two sides to every argument: one being that the networking functionality is too highly specialized and requires purpose built hardware and components to scale and deliver stability. The flip side is that the networking vendors do not want to give up their model and have made little or no effort to decouple the hardware from the networking operating system software. These are not new arguments, but cloud has brought it to a head. Cloud computing is stymied as long as the networking layer remains in the physical plane. Oh sure there are ways to work around it and hybrid cloud solutions are clearly the near term solution, but the sheer momentum of cloud pushed along by the mobility movement demands a change to the status quo and that change is coming in the form of Software Defined Networking or SDN.

OpenFlow is step one in achieving SDN. It is a communication protocol that operates at Layer 2 and that abstracts the forwarding plane away from its underlying network switch or router hardware. It makes it possible to work with equipment from multiple vendors. HP recently announced support for OpenFlow on a number of its networking switches. OpenFlow is vendor neutral, unlike MPLS, with a goal to keep it simple and effective. At its core the goal is to remain faithful to the following concepts:

• A separation of the data and control planes with a well defined vendor agnostic API/protocol between the two
• A logically centralized control plane with an open API for network applications and services
• Network slicing and virtualization to support experimentation at scale on a production network.

Network virtualization vendors such as Embrane and Niciria are taking it to the next level and leveraging this abstraction away from the physical layer and building virtualized solutions that are no longer hampered by the underlying hardware layer of the network and better yet are vendor neutral in design. These early market entrants are largely working as orchestration solutions linking networking resources to cloud services. The caveat here is what role does the networking team play in this new model? If application teams can “point and click” to spin up new resources that include the underlying networking hardware that previously had to be manually configured and provisioned, could that result in an unbalanced or unstable network?

We are still in the early stages of SDN and network virtualization, but I would like to see some more thought given to the management aspect of the underlying networking hardware in this model. It is easy to understand the need to simplify and improve the provisioning of resource down to the networking layer, but at the same time network stability cannot be compromised. Also the more abstracted something is the more difficult it is to troubleshoot. So assuming network virtualization by design is meant to bypass and avoid bad network segments, what if a problem happens up at the virtualized layer of the network? Who owns the problem and what tools do you use to resolve those issues? This feels like something in between middleware and a thin overlay network and that would provide an interim solution until networking hardware can evolve.

Related articles

• Andreessen Horowitz-Backed Nicira Pulls The Curtains Back On Disruptive Network Virtualization Platform (techcrunch.com)
• Meet Nicira. Yes, people will call it the VMware of networking. (gigaom.com)
• Nicira OpenFlow: Networking’s Next Big Thing? (informationweek.com)