Für die meisten IT-Menschen geht die Konsolidierung der Rechenzentren einher mit der Server-Virtualisierung, dem Einbinden der Storage-Strukturen in das Ethernet und der Veränderung der Netzwerkarchitekturen in den Datencentern. Hierfür gilt der allgemeine Konsens, dass die Datacenter-Netzwerke wesentlich flacher konzeptioniert werden müssen, um verlust- und blockierungsfreie kurze Verbindungen zwischen den Netzressourcen garantieren zu können.
Leider endet der technische Konsens allzu oft vor der Türe der Hersteller von Netzwerkprodukten. Spricht man mit Technikern dann wird man wahrscheinlich eine interessante Debatte über die Vorzüge des von der IEEE veröffentlichten Shortest-Path-Bridging (SPB) oder dem von der IETF propagierten TRILL (Transparent-Interconnect of Lots of Links) führen. Auf der Herstellerseite beginnt jedoch die große Verwirrung. Von Cisco erhält man gegenwärtig nur reine Lippenbekenntnisse zu TRILL. Das Unternehmen behauptet, dass es TRILL-ähnliche Funktionalitäten bereits in seinen Produkten realisiert hätte. Bei genauerer Analyse des momentanen Produktangebots erkennt man jedoch, dass die von Cisco propagierten TRILL-ähnlichen Funktionen sehr viel mehr Gemeinsamkeiten mit Shortest-Path-Bridging (SPB) aufweisen als mit TRILL. Als fester Bestandteil des "FabricPath" steht bereits "Jawbreaker" am Cisco-Horizont, die das Unternehmen noch weiter in Richtung einer proprietären Netzarchitektur treiben wird.
Juniper versucht sich bis jetzt den Themen SPB und TRILL aus dem Weg zu gehen und treibt seine proprietäre "QFabric" voran. Ähnliches gilt für Brocade mit seinem Virtual-Cluster-Switching (VCS). Spricht man mit HP, dann erfährt man, dass das Unternehmen beide Standards unterstützen wird.
Durch diese Techno-Debatte verwirrt die Netzwerkindustrie ihre Kunden und selbst IT- und Netzwerkprofis gehen im Strom der sich widersprechenden Argumente unter. Den meisten Unternehmen ist es egal, mit welchen technischen Tricks die Netzhierarchien reduziert werden. Deren Aufgabe besteht darin den Betrieb ordnungsgemäß zu gewährleisten und die Geschäftsprozesse am Laufen zu halten. Natürlich ist dies eine starke Vereinfachung, aber das Ziel der Kunden besteht darin ein Datacenter zu realisieren, welches eine niedriger Latenz und Fehlerrate bei erheblich reduzierten Betriebskosten garantiert. Technische Akronyme und schwierig voneinander zu unterscheidenden Systemarchitekturen helfen der IT nicht weiter und verwirren nur den Kunden.