Originally written by Mat Mathews at the Plexxi blog.
A good friend and business colleague once regaled me with his definition of a good corporate lawyer: “A good lawyer never says ‘no’; she says ‘here’s how’.” I thought this was an interesting and telling description – not because it conjured up creative interpretations of the law and loop-hole sleuthing corporate counsels – but that it imagined a seasoned practioner who understood the plasticity of her infrastructure (in this case the law) and the end goals of her client and therefore would often find innovative solutions that yielded business advantage. Plasticity in this context means that a seemingly rigid structure, like the law, can be deformed to meet a new need. Examples of this range from the mundane structuring of contracts to limit the downside of risky deals to the industry redefining methods of companies like Uber that challenge conventional practices and laws.
Laws and Networks - both meant to be broken?
A similar notion can be applied to networking infrastructure. It is often repeated that networking infrastructure is ‘rigid’ and ‘complex’. Other than just being evocative marketing terms, these words signify a level of resistance to adaption. Marketeering aside, business leaders are in fact expressing that what they want or need to do cannot be done – either feasibly, in a timely manner, or with an appropriate risk profile due to infrastructure obstacles. Every time connectivity needs change (think mainframe networks to multi-protocol client/server networks to IP routers/switches to remote access VPNs to high density data center switches, etc.) a new set of technologies, platforms, protocols, and ultimately infrastructure is put in place. For many years this may have been ok, and possibly even expected. Yet, for probably the past decade, the increasing pace of change of business needs and the continuous uncertainty of competitive environments have forced businesses to push harder on the aspects of their organization that prevent rapid change, that don’t exhibit plasticity.
SDN, the movement
Enter networking infrastructure, and more specifically SDN. While the canonical definition of SDN is accepted to be something about a decoupled control plane, there is also the notion of SDN the movement. This notion of SDN bears not an architectural definition, but rather embodies a user-led reaction to this lack of plasticity in their infrastructure. How are network engineers expected to say “here’s how” when their infrastructure requires generational shifts or years of standardization to catch up to yesterday’s demands? In many ways, SDN is nothing more than the desire of users to bring a level of adaptability to the uncertainty and change they experience in their business to the infrastructure.
Haven’t we heard this before?
Network plasticity is most likely not a new idea (either that or it’s naïve and unachievable.) Many a marketer has talked about the coming age of infrastructure that is fluid, dynamic, software-defined, change-ready, yada yada yada. Yet most of what is described by this fluid, dynamic, software-defined infrastructure is generally related to the shrinking, scaling, or movement of physical resources to match a desired processing need, ultimately to meet a utility cost objective. What network plasticity is about, however, is a more fundamental notion that connectivity needs will change ahead of generational or architecture product lifetimes, and that the answer cannot be to put the business needs on hold until the products catch up. What plasticity affords is a fundamental deformation of the primary design use-case into one that was a priori unforeseen – a set of carefully planned escape valves that allow their operators to say, “here’s how.”
Will current networks bend and snap?
Many networks conceived for the world of client-server computing are being tested and stretched for the needs of highly distributed, edge-processing, no-central data store, scale-out applications. While the industry attempts to move the architectural needle forward with new encapsulations to remove restrictions of L3 boundaries, bigger buffers to accommodate the predominance of server-to-server flows, new chipsets, new interface technology, better Ethernet storage traffic handling, etc, it is still not assessing the fundamental desire to prevent the need for this catch-up game in the first place. At some point, applications will decide for themselves how they would like their various components to be connected and will be able to express policy, SLA, risk profiles, and other constraints and objectives that ultimately translate into a set of network behaviors and topologies. Will the underlying infrastructure be capable of handling the resulting permutations of requirements without deriving an exhaustive and limited set of supported behaviors? Will it be able to grow with the increasingly sophisticated demands of these applications to achieve what may previously have been thought to be unfeasible? This largely depends on how we as an industry approach plasticity as an inherent infrastructure trait – perhaps the only one that really matters anymore.- See more at: http://www.plexxi.com/2014/09/plasticity-networks/?utm_source=feedly&utm_reader=feedly&utm_medium=rss&utm_campaign=plasticity-networks#sthash.L0IWOzC9.dpuf