If you like survey data, here’s an interesting fact for you. Every year since 2000, when I started surveying enterprises on the question, the most important factor driving investment and change in enterprise networks was the data center. It’s like the network is the tail of a big, fuzzy, maybe-largely-invisible dog, and it’s time we look at where that dog might be leading us.
Today’s virtual private networks (VPNs) evolved from the days when companies leased time-division-multiplexed (TDM) lines and connected their own routers. That approach focused companies on how to network sites, and they now think about networking people instead. But people are half the story; the other half is what the people are doing, which is accessing (increasingly via the cloud) data-center applications and databases.
Data-center architecture has been evolving, largely because of virtualization and the concept of resource pools rather than dedicated hosts. We don’t build monolithic applications now, we build componentized ones, and we smear application components across a pool of servers, changing application-to-host relationships as our process loads change and things break and are replaced. The data center is now a lot more dynamic than it used to be, which means the data-center network has gotten a lot more agile, more elastic. We have “horizontal” traffic between application components and “vertical” traffic between applications, cloud front-end GUIs, the internet, and users. We have a dynamic fabric.
SLAs for latency guarantees
Fabric architectures for the data center are essential because of the issue of latency. Componentization of applications, the separation of databases from applications, and the increased interactivity of applications overall have combined to make applications sensitive to network delays. That sensitivity is addressed in the data center by fabric or a low switching architectures, but it also impacts the rest of the network. Few CIOs have included latency requirements in their SLAs in the past, but more are doing so now. In 2023, CIMI Corporation survey data shows that over half of the new network contracts written will include latency requirements, up 15% from 2022 and double the level of 2021.
Mesh/fabric architectures connect everything to everything else with minimal delay, but universal connectivity isn’t always a good thing. To control connectivity, data-center networks can employ either explicit connection control—software-defined networks (SDN)—or a virtual network. Both separate connection control from traditional IP discovery-and-advertise models of flow management, and since they were first developed for cloud computing, they’ve even gained some acceptance in the WAN.
Where, as it happens, a variant on the virtual networking that started in the data center, the software-defined WAN (SD-WAN) is gaining traction. SD-WAN emerged as a way to leverage the internet to connect small sites to the corporate VPN, but today it’s growing as fast in the cloud as in small branch locations. Since the cloud is an extension of the data center, SD-WAN and data-center network technology may combine to create the network of the future. That’s all the more likely because many vendors, including VMware, Cisco, and Juniper, supply both technologies.
The cloud is part of the data center
Wait, you might be saying! The cloud is an extension of the data center? How can that be when we’re migrating everything to the cloud? Well, it’s true. What’s moving to the cloud is the agile, elastic, front-end of applications, the parts that demand scalability. Transaction processing, database hosting, and most analytics tasks are staying where they are, which splits applications into two distinct pieces that are connected by the network. The fact that cloud and data center are not an either/or, that “hybrid cloud” is (and always has been) the inevitable model for enterprise computing, is only now being reluctantly accepted. That means that we’re only starting to understand the impact of the cloud on application design and hosting, how the data center will influence the cloud, and how their symbiosis will impact the network.
One impact we can be sure of is around security. The facts that the user-to-application connection is increasingly a user-to-cloud connection, and that the Internet is the foundation of connections to the cloud, translates into a shift in security thinking. Things like secure access service edge (SASE) and security service edge (SSE), which are cloud-resident, become the front-line security mechanisms. SASE, which typically includes an SD-WAN/virtual-network piece, means that connection or session security (a network function) will play a much larger role, because session security can communicate authentication from the point of user access in the cloud, through any cloud components, and on to the data center. All these trends would tend to shift enterprise focus from routers to appliances and also increase the use of hosted—particularly cloud-hosted—instances of network technology. That could empower new vendors in the space.
We can expect another impact from the division of functionality between the GUI and the transaction processing piece of an application. It’s clear that some editing and user-assistance features of an application could reside in the cloud as part of the GUI or in the data center. The latter case would be particularly likely if some access to a database is required for validation. Some application components might thus be spread between data center and cloud, and it’s also possible that some components that are normally run in one place could be backed up or scaled using the other as a resource. This increases the extent to which applications would be componentized and the need for a fabric to optimize horizontal traffic in the data center, but it also tends to increase the value of virtual networking as a means of addressing software components that might be in a variety of locations.
The final network impact created by the cloud/data-center hybridization of applications is the reduction in load balancing that may be required within the data center. If the scalable components of an application are largely located in the cloud, then the cloud-to-data-center connections may not benefit from scaling and support for load balancing among instances may not be needed. In contrast, the cloud may require load balancing to support its own ability to scale with workloads, possibly through use of a service mesh.
OK, let’s sum up.
The data center is called that because (Duh!) it’s where the data is, where transactional, mission-critical, applications are run. Data-center policies and connectivity are set by that data and application set, and because that’s what users of all types are trying to access; that policy/connectivity combination sets network requirements. There’s always been a tight relationship between data center and network, and as cloud usage and online access dependence grows, that relationship is only going to get tighter. Plan your network without the data center, and you do so at your peril.