The world of networking tends to be bistable: we either centralize everything, or we decentralize everything. We started with mainframes, passed through Lotus 123 hidden in corners, then to mini’s and middleware, then to laptops, and now to the cloud, to be followed by fog. This particular cycle of centralization/decentralization, however, has produced a series of overlapping changes that are difficult to decipher. You can somehow hear someone arguing about disaggregation and hyperconvergence through the fog—but just barely.

How can we make sense of this?

What’s important is to think about how businesses can, and likely will, use the primary new ways to deliver information technology services. First, there, hyperconvergence, which is a single company combining storage, compute, and network into a single package. Hyperconvergence allows companies to purchase a single “item” that contains everything they need to add capacity to a data center, or to build a “mini data center” in a remote office. There’s no need to think through which switch to buy to support a specific number of servers or storage, etc.—you just choose a size and hit the “buy” button. Hyperconvergence effectively outsources much of the basic design that needs to go into building processing power.

Efforts like Open19 are likely to move hyperconvergence out of the realm of integrating solutions from a range of manufacturers and into the realm of custom built solutions based on white box solutions. A good integrator could use standard components to put together racks of equipment for specific applications at a lower price than individual components from multiple vendors.

The second side of this triangle is disaggregation. While top tier hyperscalers, like Google, have been working towards building their own networking solutions for years, the ability to build a custom solution on commodity hardware has always been limited to this highest tier of operators. Companies like LinkedIn, however, are breaking down the scale barrier, bringing disaggregation to mid-scale data center and cloud networks. When operators with hundreds of thousands of servers, rather than millions, can build custom networking solutions out of publicly and commercially available components, disaggregation is clearly moving down the scale of scalers, towards the higher end enterprise.

Finally, we have the cloud. As it’s often been said, “the cloud is just someone else’s computer”—but cloud solutions are proving effective for many applications, particularly for narrow applications and smaller companies. Of particular interest, some applications (such as sales management and real time communications) are thriving in the cloud.

Given these overlapping and intersecting trends, what is the future of network engineering? If you listen to the cloud folks, everything is moving to the cloud, and private networks will “go away.” In this case, the average network engineer has just a few choices. Either morph into a programmer/cloud manager, go to work for a cloud company, or find another line of work. If you listen to the hyperconvergence folks, cloud is useful but the real future lies in buying complete systems rather than component parts. The average network engineer in the hypconverged world has more choices, of course, as there is still a local, privately owned network. At the same time, however, much of the work of specifying and building the local, privately owned network is pulled into the hyperconvergence companies themselves. And, of course, if you watch the hyperscalers—the folks who actually build the cloud—commodity hardware in customized solutions is the future.

Which of these three is it to be? The reality will probably, as always, be something different than any of us expect—but here is a guess to try and help the average network engineer to find a way through the morass.

First, we can assume that software as a service, particularly for some classes of software, are here to stay. Sales automation and tracking, for instance, seems like the perfect sort of service to place in the cloud on a permanent basis. Second, we can assume that hyperconvergence is here to stay. Most companies are struggling to hire real engineers; hyperconvergence gives companies without a big staff access to a level of expertise the big component vendors always promised, and yet couldn’t always provide (or perhaps never provided, depending on your point of view). Finally, as the tools and processes needed to build more customized solutions move from millions of servers to hundreds of thousands, the disaggregation space is bound to get more interesting.

Given these assumptions, a likely market scenario is this: smaller and larger companies will continue to explore, and purchase, common services in a cloud format where it makes sense. There will still be internal IT services, but they will be increasingly split. Smaller companies will move more solidly into the hyperconverged space, buying IT as a block of compute, storage, and network rather than as component pieces. The hyperconverged end of the market will see IT professionals move towards management and automation tasks, rather than towards design and specification.

For larger companies, disaggregation is going to be way forward. Once you reach a certain scale, business should control design, rather than technology considerations. This particular space is where disaggregation will shine, and hence will provide the most value add for money spent. Network engineers who want to work in this space will need to go beyond the CLI, moving towards a broader set of knowledge across many different areas of information technology, and reaching into business to let business goals drive the network, rather than vendor based technology decisions.

In short, the network engineering space is going to split along the same lines as the market, between those who deal with disaggregated solutions and those who buy and manage hyperconverged solutions. Everyone in the network engineering world is going to need to interact with, and perhaps even manage, cloud based solutions along the way.

Which all means this: as a network engineer, you are going to be faced with a choice between one of these two paths over the coming years. The choice might not always seem to be stark or obvious, but the undercurrent of network engineering is going to point in one of these two directions.