A key part of planning a network strategy is understanding the possible business requirements and how network technology can meet those needs. I prepared some rough diagrams to outline the functional areas for a network strategy today and the results were confusing. I reworked the diagrams, and then established a progression in the strategy over the last ten or fifteen years.
Conclusion? A modern network strategy is messy. Here is what I have today.
The 2000’s
In the 2000’s the functional areas for a network strategy looked, roughly, something like diagram below. Two physical networks of public and private WAN (aka Internet and MPLS services) with branch/campus at the edge and the data center at the core. Third-party connectivity was most often IPsec VPNs, although MPLS services were common.
This was the era of routers and dedicated bandwidth. Most engineer time was spent solving physical connections and L2/L3 issues. It was the close of the “era of connectivity” when connecting sites was enough.
The Early 2010’s
In the early 2010’s, the move to colocation data centers was well underway as the fashion for owning and operating data centers changed.
The concentration of customers in colo sites led to the emergence of interconnection (IXC) providers in the telerooms with pre-installed bandwidth and edge networks to more rapidly support new connections. The interconnection providers offered better bandwidth in the colo sites and interconnection to existing private WAN.
IXC providers delivered some early automation on their interconnection services, primarily to offer customers faster service delivery than their service provider i.e. new ports delivered in days and bandwidth changes within hours.
This was the era of L2 DC Extension for “transparent” service location and disaster recovery, and new ways of connecting bandwidth. Connectivity was assumed and ‘era of bandwidth’ started.
The Late 2010’s
In the latter part of the decade, SD-WAN entered the strategic plans for most companies. While you could run SD-WAN on private MPLS, most companies chose the public WAN for better bandwidth, faster provisioning, lower cost, and greater flexibility. Some customers chose to use both.
A key aspect of the SD-WAN movement is the assumption that bandwidth exists but is not used to maximum effect. Most SD-WAN deployments use public WAN because it is faster and cheaper.
The era of bandwidth was passing the baton to application networking. In application networking, edge network devices can fingerprint applications and then forward them intelligently over available bandwidth. A long but slow decline of MPLS services becomes inevitable as customers take advantage of Internet bandwidth and rely on SD-WAN features to find optimal application performance.
Early SD-WAN application networking is rapidly evolving into SASE, where application security is a basic feature. Identified network flows are combined with security metadata for decisions about firewalling and logging. Operational features of SD-WAN controllers will be adapted into security features of operational logging, authentication, and configuration management.
In this era, connectivity and bandwidth give way to application performance and visibility.
The 2020’s and Off-Premises Cloud
The slow burn of “public cloud as an off-premises data center” location will solidify into a mainstream fashion.
The trend of “someone else’s computers” or “what’s in AWS stays in AWS” transforms to a more integrated and interconnected networking. As the public clouds release more and more software services, the complexity of connectivity continues to rise and it’s harder to maintain a coherent strategy based on IP routing.
The level of interconnected-ness becomes critical as connectivity from branch, campus, and distributed (remote) workers becomes a default requirement. On-prem to off-prem data flows are still rare but are strategically an obvious requirement. More common is the use of SaaS or cloud-hosted services.
The cloud companies bow to customer demands and implement back doors using private WAN into their infrastructure, but with a number of restrictions, gotchas and limitations.
The era of overlay networking dominates this landscape. Overlays was driven by SD-WAN outside the data center and by encapsulation in IP fabrics within the data center. Overlays are now common for secure application forwarding. Service Meshes are widespread in various forms for virtual machines (eg. VMware NSX) and containers.
The emergence of Data Processing Units (SmartNICs) are likely to lead to overlays extending into the physical machine.
Strategy Vs Implementation
As I prepared this diagram, I was considering how the “network”, as a whole, is complex. As I review the diagram I suspect that there is more to be added.
Here some thoughts I’m mulling over:
- Most network products/solutions available today address only limited areas of an overall strategy.
- Stitching overlays together seems unlikely. Federation/unification should be possible but hard. Easier to deploy a unified overlay.
- SD-WAN will extend to embrace distributed workers replacing ‘remote access VPN’ over time.
- Having both private & public WANs is undesirable due to complexity. The Public WAN (Internet) is more useful overall, motivating the retirement of MPLS.
- Some functional areas are mostly proprietary e.g. AWS, Azure networking APIs
- Note that definitions of open are gray and murky e.g. an ‘open access’ API is not a networking standard
- Public cloud networking includes a range of app services such as DNS, LoadBalancer, Firewalls etc.
- More than connecvity, bandwidth. Application services.
Federation Or Unification Questions
Is it better to deploy a product that is consistent in all FA’s ? Or to use a federated SDN controllers?
Products exist in function areas of public cloud, private cloud, SD-WAN. Will these converge on a single unified software controller or will a federated model emerge?
What are your thoughts? Can vendors unify into a single network solution or will interoperability deliver a unified application network?
