There are a lot of issues that network-management people worry about. We all have heard about faults, failures, breaches. But want to know what long-term problem is keeping the smart members of the network leadership of enterprises up at night? It’s an empty chair. Their chair, at the table that makes the plans that set network requirements and directions today and for years to come. These leaders used to sit in that chair, but now they say there’s no place for them.
Application designs determine network requirements
We used to build networks from primitive pieces, like digital trunks and routers. Then we built them from services, like IP VPNs. That transformation was jarring to many who’d cut their teeth on real private-network technology, but they were still a big part of the game. Today, we’re still building networks from services, but the services of today are application services that include implicit network features. The really new network is built from connectivity services that are included in cloud and even data-center hosting packages. Application planners design these services, and the decisions they make frame the building-blocks of the network. One chief network officer said he’d gone from building technology to stocking shelves.
In some ways, more application centricity could be a good thing. Twenty years ago, companies’ network budgets were roughly half dedicated to sustaining current infrastructure and half to support new business projects that brought their own benefits. Today, few companies get even a fifth of their budgets from new projects. Our chief network officer isn’t just stocking shelves, he’s restocking them. New applications could open new business cases, drive new budgets and new network plans.
They are doing that, particularly in cloud computing, but the networking piece of the new application paradigms is part of the cloud, and application design decisions are setting network requirements. Often they set requirements that can’t be met. Several network leaders I chatted with in December told me about projects that built cloud software in a way that could not possibly have met either the cost projections or the quality of experience mandated by the projects’ business case. They also said they would have recognized the problems immediately had they been in on the decisions from the first. “A bunch of programmers put this together with state-of-the-art software techniques,” one said. “We needed state-of-reality techniques.”
Application planning needs input from network pros
And here’s the reality. Network professionals need to be involved, heavily involved, in the application planning decisions that are really driving network evolution for enterprises. They have a lot to contribute in the critical area of application architecture, the set of decisions that determine what an application does, how it’s connected, and what it costs.
The reason for project failures that those network leaders told me about was simple: over-componentization. Cloud-development treatises emphasize microservices, meaning tiny, scalable, distributed, components. You can build applications that way and enhance how the cloud can make them available and scalable, but every such component you add also adds a pair of network connections. Latency goes up accordingly, and one enterprise found their cloud implementation delivered three-second latency when their old data center front-end introduced a third of a second or less.
Costs also explode. It doesn’t do any good to componentize the applications and then bunch them into a monolith when you host them, so each microservice component is independently hosted. That’s not a path to economical operation, so it’s no surprise that most enterprises say that their cloud costs have overrun, and often badly overrun, estimates.
Problems with having application architectures dictate network decisions by default don’t end with the cloud, either. More and more enterprises use containers and the popular Kubernetes orchestrator tool to deploy data-center components of their applications, including database access. Kubernetes uses virtual network technology and supports virtual-network plugins. So do the public-cloud providers, so the cloud piece of applications is based on virtual networks. If you have multiple clouds (multi-cloud) and also cloud-to-data-center (hybrid cloud) applications like almost all enterprises do, then you could have three different virtual-network models within your application platform, and probably a corporate VPN besides. It’s not just ships passing in the night, it’s whole fleets.
Focus on information flows
For operations reasons alone, the multiplicity of network services that make up networks of the future would be a challenge, and network professionals are already meeting it. Network operations isn’t the real problem, though. Even simple questions of how the elements involved in each information flow can address each other demands some understanding of both the rules of element connection and the way all these virtual service networks can be interconnected. Without some influence on how those network services and the application platforms that use them are combined and used, things can arise that can’t be fixed. They have to be prevented.
In the world of the future, and even much of the world of today, applications and users float around in a sea of interconnected hosting facilities. We have the Internet, where most of a company’s customer-facing activity starts, and that plays a growing role in employee access to information. We have the cloud, which is the front-end of applications pushed out of the data center and into a distributed, elastic, pool. We have the data-center network, used by data-center virtualization technologies to connect application pieces, and we have the corporate VPN, which is sometimes MPLS, sometimes SD-WAN, and sometimes both. We’re not networking sites any longer, we’re networking information flows. Application developers assume those flows exist, but network professionals have to assure them, and make them “assurable”.
We can’t build applications without considering those information flows, without perhaps even being dominated in our thinking by those flows. We can’t build networks without interconnecting services that are really designed to host application pieces. We’ve separated things that, at some level at least, can’t be separated. We need to get back the network professionals’ seat at the decision-making table, but it’s not just a matter of claiming a place, they have to claim a role. That means that there has to be a real exchange of views during application design, which in turn means that there has to be a basis for the exchange. Network people can’t speak network to programmers, and the other way around won’t work either. They have to find a common ground.
Workers aren’t in fixed locations today, not after COVID and work-from-home, and network professionals have dealt with that. Information flows now accommodate worker mobility, and they can accommodate application-component mobility, too. If network professionals can claim the role of the information-flow architect, and learn the way application design impacts those flows, they won’t have to slip into that seat at the planning table, and maybe participate in collective seat-polishing. They can play an essential role.