When the networking world talks about disaggregation, it is almost universally a discussion of white box switching with the objective of driving down costs. It’s not surprising that those deploying network equipment in the highest volumes — the hyperscale cloud providers — are some of the biggest champions for the white box movement.
But does this mean disaggregation’s impact on multicloud will be limited to decreasing costs in the larger public clouds’ supporting infrastructures?
Disaggregation Is More than Cost
While disaggregation is primarily implemented to cut costs, it is useful for much more. In fact, at its core, disaggregation is more about control than cost. By breaking tightly integrated systems into their constituent components, end users ultimately gain greater choice and flexibility to build fit-for-purpose solutions.
As a result, disaggregation improves performance. Whether it’s real-time applications like player-vs-player gaming or financial applications, for those enterprises needing to deliver a superior experience, the ability to mix and match components to minimize latency can make all the difference.
Disaggregation Is More than Hardware and Software
The industry’s maniacal focus on white box has detracted from other examples of disaggregation in networking. Decoupling the management of devices from the devices themselves has led to the entire SDN movement, which has been key in driving operational efficiencies across the enterprise network. Indeed, movements like SD-WAN would be largely irrelevant if not for the ability to use cloud-based management across heterogeneous environments. In fact, disaggregation makes it possible for operations teams to leverage abstraction as a means of coping with the complexity inherent in large, distributed networks.
Disaggregation also shows up in unexpected ways. In larger devices, a chassis system will be populated with line cards. The line cards and chassis are typically paired — line card A goes into chassis A, line card B into chassis B. Breaking this coupling is also disaggregation. What if the chassis could be re-used across different types of line cards, assuming the identity of whatever is populated inside? This would allow for a different sparing model and would allow a device to be redeployed in different use cases just by swapping out the line cards. By decoupling components, the possibilities for how to deploy a device or a piece of software expands, ultimately granting an enterprise greater control.
Multicloud Drives Diversity
While disaggregation can be useful in today’s networks, it is an absolute prerequisite for tomorrow’s.
The entire IT industry is moving towards cloud. And while most are focused on early workload migration to a single public cloud, it seems certain that for enterprises of even moderate size, the future will be multicloud. Whether it’s the fact that different clouds have different capabilities, or the realization that single supplier strategies limit economic leverage, most enterprises will end up in multicloud architectures in the not-so-distant future.
One thing to know about multicloud is that it requires much more than just the cloud. The whole premise of multicloud is that regardless of where an application is served or where a user is accessing it, the experience ought to be the same. For a uniform experience and security posture, multicloud must extend end-to-end, from public and private cloud all the way to the on-ramps that exist in both the enterprise campus and branch. The infrastructure must be essentially invisible, granting consistent policy and control across a diverse operating environment.
This has an important, unavoidable implication: multicloud will necessarily be diverse. Connectivity inside the data center will rely on merchant silicon. At the data center edge, it will likely be custom silicon. In the cloud, it will be provided by virtual networking devices. In the branch, x86 and ARM will dominate. And all of this will exist in a multivendor environment.
The only viable way forward to multicloud is to disaggregate tightly integrated systems. Both the network operating system and multicloud orchestration must be decoupled from the underlying platforms, allowing for multivendor control. Put simply, there has to be a way to mix and match the underneath bits while maintaining consistency in the over-the-top parts that drive multicloud orchestration, meaning anything built without disaggregation as a goal is likely to be insufficient over time.
What It Means for Enterprises
Ultimately, enterprises will not make the move to multicloud in a single step. The needs of today must still be met. There is no appetite for a disruption in service, and most companies lack the freedom to embark on a transformation in a single movement.
As companies execute against their naturally-occurring expansion and refresh opportunities, there are ways to prepare. With each decision, architects and operators should explicitly think about how the underlying infrastructure will integrate into a multicloud orchestration solution. With each evaluation, IT teams should assess whether the solution is more monolithic or modular. At every product boundary, are the interfaces well-defined and open so that they support a disaggregated collection of components? If there are end-to-end visibility requirements, how will integration with tools be completed?
In practice, disaggregation needs to evolve from vendor principle to enterprise responsibility. For multicloud to deliver against its promise, it’s going to require changes in standard practice within enterprise teams. Enterprises simply cannot reap the rewards of an architectural revolution while staying firmly planted in legacy design.
Feature image via Pixabay.