A guide to distributed network architectures

What is a distributed network?

A distributed network is a collection of multiple, independently run networks that are collectively managed. In most cases, these networks are geographically separated to provide better reliability and offer multiple entry points known as points of presence to provide better performance to users who are spread across multiple physical locations. Each network within a distributed network architecture can interact with others for the purpose of service resiliency, performance gains and automated resource sharing.

While each network within a distributed network architecture can operate independently, management and monitoring are centralized. Thus, various network and network security policies can be created once and pushed out to the entire network. This ensures uniform policy across the entire network infrastructure. Likewise, all monitoring and alerting are operated out of a single NetOps management panel for true end-to-end visibility.

Examples and use cases of distributed networks

The number of distributed network use cases seems to be growing by the day. Here are two popular examples:

1. Secure Access Service Edge (SASE). Globally distributed SaaS architectures are one example of a distributed network. SASE is one SaaS use case that's growing in popularity thanks to the explosion of remote workforces. With SASE, end users can connect to remote applications and services through one of several independent SASE gateways that provides network security services for all business traffic flows. Each SASE node operates independently from all others and redirects users to alternative head-end locations when a more preferred node is identified.
2. Edge computing for IoT. The explosion of IoT to monitor various city, campus, building or plant operations is forcing the need for edge computing services. For IoT deployments that require low-latency network access for the collection and analysis of IoT data, a distributed network model consisting of multiple edge compute nodes is often required.

Centralized vs. decentralized vs. distributed networks

When comparing distributed network architectures with centralized and decentralized alternatives, some differences are obvious -- while others remain a bit vague. Let's compare the similarities and differences between distributed and centralized networks first, and then move on to analyze decentralized vs. distributed networks.

Centralized vs. distributed

A centralized network architecture looks like a traditional network. With this model, endpoints connect to a single application or resource in a client-server manner. If the central server or network the server operates on were to fail, an outage would occur. Thus, from a redundancy perspective, centralized architectures can be deficient when maintaining network and application services in the event of a major outage.

In remote workforces, legacy remote access VPN architectures often use a centralized network model. This is because the design requires all remote users connect to a single VPN head-end at the corporate network edge, creating a single point of failure.

In contrast to centralized networks, a distributed architecture uses a clustered model to service business applications. These network and server clusters are in constant communication with all others and can share resources and redirect users to different cluster groups for reliability and to improve application performance.

Decentralized vs. distributed

While it's easy to conceptualize the difference between centralized and distributed networks, things get more challenging when comparing decentralized vs. distributed networks. In fact, many people conflate decentralized and distributed, assuming they mean the same thing. In fact, the two models have distinct differences.

A decentralized network distributes workloads and data across multiple networks and systems, much like distributed systems. However, unlike distributed networks, where each node in a cluster contains all applications and data required to operate, a decentralized network architecture disperses various services, functions and data at specific locations. Thus, decentralized networks rely heavily on each other and cannot operate independently like a distributed network can.

Additionally, decentralized networks usually do not have a centralized control plane from where all systems can be managed. Instead, these separate workloads are controlled independently.

Visualizing centralized, decentralized and distributed networks

To better conceptualize centralized, decentralized and distributed architectures, take a look at the network diagrams below.

Note that, with a centralized model, all servers connect to a single centralized network from which to operate. Servers within decentralized networks, on the other hand, are linked in an as-needed basis depending on the specific application/service function that is required and the physical location of that resource. Finally, a distributed network operates as completely independent nodes within a full mesh design for maximum reliability and performance.

Advantages and challenges of distributed networks

The use of technology to drive business goals is at an all-time high. Compared to even a decade ago, we've witnessed monumental shifts in how businesses digitally transform their processes. This often requires radical architecture changes to their underlying network infrastructure.

Common examples of these business and technical shifts are the following:

• network and server virtualization
• cloud computing
• containers and serverless architectures
• edge computing
• work-from-home policies

As such, distributed networks offer the following advantages in an age where rapid business and technological shifts go hand in hand:

• Application and service reliability. Because each node in a distributed network cluster can operate independently from all others, outages to large sections of the network do not result in a service outage.
• Scalability. Nodes can be added or removed on an as-needed basis depending on the level of redundancy and performance required.
• Re-architect traffic flows based on business changes. New applications or changes to application usage can be rapidly addressed as north-south and east-west traffic rates and loads are adjustable, alleviating bottlenecks.
• Centralized control. Both network performance configurations and network security are centrally managed. This ensures that policy is uniform from end to end.

As with any new technology, however, disadvantages must also be considered. Currently, those disadvantages include the following:

• Architecture complexity. Compared to centralized networks, distributed network architectures have more layers of software abstraction. As such, those layers add to the overall complexity from a deployment and management perspective.
• Skills gap. In-house NetOps staff need to acquire new skills and knowledge in order to keep a distributed network running optimally. These skills are in high demand -- so it might be a challenge to find and keep technical talent within an organization for the foreseeable future.
• Cost to migrate and manage. Migrating from traditional, centralized networks -- the most common architecture today -- to a distributed architecture requires a significant investment when designing and implementing the new infrastructure. Once the network is operational, however, this investment can be recouped if the use of network automation and machine learning is implemented properly.

Applications, services and network architectures evolve

While we can pin down what an optimal network architecture looks like and consists of today, understand that future advancements are inevitable. This is a continuous process driven by business goals and the applications and services required to meet them. Thus, much like changes of the past that occurred to get us where we are today from an architecture perspective, note that this is a never-ending cycle where network performance, reliability and scalability continue to improve and evolve.