Embracing Your Network as a Product

In this post, I want to explore the concept of Network as a Product (NaaP) and how this approach can revolutionize the way networks are operated, managed, and consumed. As businesses push toward automation and self-service models across IT, networks must evolve to meet these new expectations.

Networking has long been a critical pillar of IT, alongside computing and storage. Every business application—from the simplest file transfer to the most complex distributed application—relies on the network for connectivity. Yet, networks have traditionally operated in silos, with requests for changes or new services going through cumbersome, manual processes. These processes often involve coordination across multiple teams, all of whom must follow predefined, sometimes rigid, standards.

The underlying problem is that networks haven’t fully embraced the same automation and agility practices that computing and storage have achieved. We haven’t found a way to reliably streamline even the most trivial changes—until recently.

With the rise of cloud networking services, businesses are beginning to realize that networks can be consumed using a model similar to Infrastructure as a Service (IaaS). This shift turns the network into just another IT service that can be offered on a self-service basis.

However, while many organizations are adopting this cloud-first approach, network teams are often just getting started on their automation journey. For most, the idea of fully transforming their networks into consumable services feels daunting. This post is about demystifying that process and sharing a strategy for gradually evolving your network to embrace the Network as a Product approach.

What is a Network as a Product?

Let’s start with the fundamental question: What does it mean to treat your network as a product?

At its core, treating the network as a product means delivering it in a way that mirrors the user experience (UX) offered by modern IT infrastructure products. It’s about shifting from a technical, infrastructure-focused mindset to a product-focused mindset, where the network is a consumable service.

From the User’s Perspective

From the standpoint of a user (someone who consumes network services, such as application developers or end-users), a network as a product should:

• Offer a self-service experience: Users should be able to request and deploy new network services (e.g., creating VLANs, VPNs, or firewalls) with minimal friction. The outcome should be well-defined, predictable, and reliable.
• Provide a clear service catalog: A well-organized list of available services, with simple usage requirements (minimal input) and clearly stated inclusions/exclusions. This catalog should abstract away the complexity of the underlying infrastructure.
• Expose relevant service information: Users should have access to real-time performance data and insights about how the services they consume are performing. Transparency around uptime, latency, or bandwidth usage, for example, is critical.

From the Network Team’s Perspective

For the network team, delivering the network as a product means that the network itself should:

• Follow automated, repeatable processes: The network’s operation must be automated as much as possible to reduce human intervention and errors. This minimizes operational risks and increases speed.
• Build on a reliable core network: The foundational network infrastructure must be robust and capable of supporting the delivery of user-specific services without negatively impacting the overall stability of the network.
• Leverage strong observability tools: The network should have built-in observability to detect potential issues before they impact the user, ideally with self-healing mechanisms that automatically mitigate problems.

At its essence, a Network as a Product approach transforms the network from a traditionally reactive, complex system into a proactive, reliable service that users can consume effortlessly, similar to how they would consume a cloud resource.

Why NaaP Matters for Organizations

Today’s organizations are more dependent than ever on their network infrastructure. From hybrid cloud setups to multi-region data centers, or even vast global campus networks, the need for seamless interconnectivity is paramount. And yet, despite the clear demand for reliability, the complexity of these networks should never be the user’s problem.

Simplifying Complexity for Users

The network team must simplify the experience for users, regardless of the complexities behind the scenes. Whether users are deploying applications in the cloud, transferring data between physical sites, or securing communication across hybrid networks, they expect the network to "just work."

The key here is consistency. Networks in different environments may vary in terms of technologies used—ranging from virtual networks in the cloud, data center networks, to Internet connection for external routing. However, they all share a basic need to connect nodes. As long as the network provides a reliable, consistent user experience, users shouldn’t have to worry about the specifics. For instance, a consistent IP address plan across all network environments can help eliminate friction for users trying to manage applications across multiple network domains.

Adopting a Product Manager Mindset

A product manager mindset is invaluable when developing the NaaP strategy. In many cases, network teams don’t think of their work as "delivering a product." Instead, they think about configurations, routing protocols, or troubleshooting. To align with modern IT operations, the network team needs to adopt the same mindset that product teams have embraced. This includes:

• Defining services based on user needs.
• Translating these needs into actionable, deployable services.
• Ensuring services are reliable, seamless, and intuitive.

For example, one of the most common services in service provider networks is Layer 3 VPNs (L3VPNs), which allow geographically distributed locations to securely interconnect over shared infrastructure. In campus networks, a similarly common service might be security policies that ensure authorized users can access internal applications.

A simple way to begin? Look at your ticketing system and see what types of user requests are most common. Start by turning these frequent requests into self-service network services that users can deploy on their own.

Case Study: AWS Interconnect as a Service

Let me share a personal experience from 2017 when my team was tasked with simplifying interconnectivity between applications running in different AWS Virtual Networks. At that time, the solution required multiple API-driven actions from both the requester and the receiver of the connection. It was a tedious process prone to mistakes.

To simplify this, we built a Network-as-a-Service solution that abstracted the complexity away from the end user. Our system handled all the technical details of connecting applications between virtual networks, exposing only a simple interface for users to manage their connections.

We created an API-driven interconnect service that was so easy to use, it became the default choice for application owners needing multi-region connectivity. By abstracting the complexity behind the scenes and allowing users to focus solely on their application needs, we transformed what was once a tedious, error-prone task into a simple, self-service solution. More details in this conference video .

Network Automation: The Key to Network as a Product

There’s no way to deliver Network as a Product without network automation. Regardless of the technology involved, every network service requires changes to the network itself. These changes can be as simple as adding a VLAN, or as complex as configuring a new routing protocol across multiple data centers. However, these changes must be automated to scale efficiently.

However, network automation doesn’t happen overnight. Teams go through various maturity levels as they progress on their automation journey (I plan to write more about it sooner than later). To truly deliver NaaP, a network team must reach a high level of automation maturity, that allow orchestrating full-scale deployments across environments, ideally with a self-healing approach that also uses monitoring to support issue resolution.

One way or another, you need some plan to implement capable network automation solutions…

The Network Automation Architecture

In Network Programmability and Automation book (Chapter 14), we describe an automation architecture that includes the following components:

1. User Interactions: Providing users with intuitive interfaces tailored to their needs, from network operators to end-users.
2. Source of Truth (SoT): A data model that defines the intended state of the network. Automation depends heavily on how accurately the SoT represents the desired state.
3. Orchestration: Managing the deployment of changes across different systems and components, ensuring they align with the desired state.
4. Automation Engine: Deploying the actual network changes required to bring the network into alignment with the SoT.
5. Observability: Providing feedback on the network’s performance, comparing the actual state to the expected state, and triggering actions when anomalies occur.

Notice that none of these components a restricted to one solution. For example, your source of truth may be composed of different data sources, but all of them should provide a consistent representation of your network at a moment in time.

This architecture enables continuous deployment of network services, similar to the way modern software development teams deploy new versions of applications.

Two Types of Networks: Foundational and Service

To adopt the Network as a Product approach, it’s helpful to split the network into two distinct categories: Foundational Networks and Network Services.

1. Foundational Networks: This is the core infrastructure that underpins your entire IT ecosystem. It includes critical components like core routers, backbone links, and data center interconnects. The foundational network should be rock-solid and resilient, as any disruption could impact the entire business. Changes to the foundational network should follow strict controls, and automation here must be done with extra care.
2. Network Services: These are services built on top of the foundational network, delivered to end users. For instance, services like VLAN provisioning, VPN configuration, and firewall rules could fall under this category. Network services can be automated to a much higher degree, allowing users to request them directly, without worrying about the underlying infrastructure.

By isolating these two layers, network teams can more confidently automate and expose self-service capabilities for the service layer, while maintaining the necessary controls over the foundational infrastructure.

How Does an Automated Deployment Look?

So, what does an automated deployment process look like in the context of Network as a Product? It should follow a workflow similar to that of Continuous Deployment (CD) in software, with a strong emphasis on validation and observability.

Here’s a high-level breakdown of how this works:

1. User Request: A user (or network operator) initiates a request for a new service or network change.
2. Source of Truth (SoT) Update: The user’s request is captured and reflected in the Source of Truth, ensuring that the desired network state is updated. For network services, this should follow a design-driven approach that expands the minimum input from the request into all the necessary details to deploy the service.
3. Deployment: The automation system translates the SoT data into actionable tasks and deploys the necessary changes to the network.
4. Validation: The observability tools monitor the network for any deviations from the expected behavior. If everything is working as expected, the changes are gradually rolled out across the network. For higher-risk changes, an incremental rollout may be used (e.g., canary deployments).

Note: For more details about establishing a network validation solution, you could have a look at the Modern Network Observability book .

Risk Management in Automation

When automating foundational network changes, human intervention is often still required for final approval. On the other hand, routine service changes can be rolled out fully automatically because it’s a well-known and constrained operation with robust validation. As a reference, I don’t think that when you request a virtual network in a cloud provider there is a network engineer behind approving the changes manually…

For routine changes (i.e., network services), versioning of network services can help provide stability. For example, each service can have an immutable configuration that only changes when users explicitly choose to upgrade to a newer version. This practice avoids unwanted surprises from under-the-hood changes.

Network Validation: The Crucial Piece

A solid validation strategy is essential for building trust in network automation. Aside of pre-deployment validation (using analytical or virtualized digital twins strategies), the real and relevant testing happens in production. For foundational networks, you’ll want to deploy changes incrementally, with validation steps at every stage. For example, you can perform canary deployments by rolling out changes to a small portion of the network (e.g., 1% of sites) before expanding to the rest.

The validation can be extended to the service built on top of the network. For example, after the basic network validation is done from the network engineering perspective, it could be recommendable to notify critical applications to run their continuous integrations acceptance test on top of the new environment to get an extra check that the ultimate user experience is not impacted.

For network services, validation happens through extensive testing during the service creation phase. Once a service is validated, it should be immutable—users should only experience changes if they explicitly upgrade to a new service version.

Wrapping Up: A DevOps Approach to Networking

Ultimately, embracing DevOps principles is critical for network teams seeking to evolve toward Network as a Product. It means shifting away from a reactive, ticket-based model of operations to a proactive, service-oriented approach where the network is offered as a reliable, consumable product.

Treating the network as a product means thinking of it not just as a technical asset, but as a strategic enabler for the business. By automating network operations, providing self-service capabilities, and focusing on user needs, network teams can deliver faster, more reliable services.

I hope this deep dive has given you more insight into how you can transform your network into a product and the benefits (and challenges) of this approach. As always, I’d love to hear your thoughts, experiences, and any challenges you face in your network automation journey.