Editor's note: We've previously heard from experts who argue that although fabrics are good for SDN implementation,...
they are not necessary. This expert answer explores an alternate opinion on the need for fabric in SDN.
Why do we need fabrics if software-defined networks are the next big thing?
There's been discussion surrounding an ongoing puzzle for many IT organizations: If the future will be all about software-defined networks, what about these things called fabrics?
It might be best to start by asking yourself, "What am I really trying to achieve?"
For many, the answer is simply more manageable networks. That can mean a variety of things, such as less fragility, more automation, fewer points of management with less repetition and more streamlined management processes, and more flexibility in terms of topology and elasticity.
Fabrics directly address all of these parameters, permitting the industrialization of network operations, which allows data center operators to scale the number of networking devices and volume of traffic per administrator.
This is a fundamentally different goal than SDN's, which -- at least in its current incarnation -- mainly serves to define and execute change to policy and specific services easily. This too can allow network admins to scale their efforts, but in a much different way: this is about fine-grained segmentation, customization and precision delivery.
It's possible to implement either without the other. But the health and maintenance demands of the physical network aren't eliminated in a software-defined network scenario, and SDN brings additional levels of abstraction to be managed. Fabric resilience and automation can help free administrators to concentrate on learning and optimizing new SDN environments. In addition, overlay traffic still depends on there being sufficient capacity in the physical networks it traverses, making fabrics' active-active nature very valuable.
Finally, most fabrics have a centralized management construct, which reduces the points of integration with external controllers and orchestration tools. Externally defined network policies and applications can be pushed once to the principal management device and immediately be propagated to all relevant nodes without multiple calls to the controller cluster or management system.
To slightly modify a key point from a very good blog post by Tom Nolle, infrastructure policy will always have to be isolated from, but have visibility into, connection dynamism. Fabrics effectively contain that dynamism and keep it largely self-managing while providing a first layer of management abstraction to simplify integration with SDN controllers and orchestration frameworks.
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.