Traditionally, service design has been dictated mostly by network topology and the technology chosen as the transport for these services. Network engineers designed the network based on the initial service requirements and customer presence. As customer demand grew, network teams had to research and determine where to add core/edge nodes to satisfy forecasted demand for services. They also had to consider where on the network to increase capacity to provide reachability and ensure up-time (availability) for these services.
During the life-cycle of the network’s operation, traffic engineering was at the heart of creating paths across the network to meet service SLAs or specific route requirements. A significant amount of time was spent reviewing the network topology offline, coming up with augmentation plans, and writing implementation documents to execute these augmentations. Of course, the problem with forecasting demand was that it was a shot in the dark, albeit an educated one, often materializing entirely differently than anticipated. These projects could take weeks, if not months, as the work involved numerous teams. We all know what happens when many teams collaborate within a big company- meetings, conference calls, and slow progress. This translates to a lot of valuable time wasted for everyone involved, which could have been spent augmenting service features that customers demanded, in a much shorter amount of time.
To complicate things, service requirements rarely filtered to network and service design teams directly from customers, resulting in even more implementation delays, since a clear understanding of requirements by network engineers was critical to ensure customer expectations were met. Although this is a very simplified vignette of a typical network engineering team’s responsibility, one can clearly see that the networking team’s time and resources were not used efficiently or optimally in the traditional model.
Network Engineers Benefit From Abstraction
With NetFoundry, the network is represented by just a few lines of code. Everything about it is virtual, not physical. We use the Internet as the core underlay, enabling the network reach globally and at scale without limitation. Network engineers no longer a need demand forecast meetings and endless discussions on how best to augment the network to reach potential customers. We don’t have to put in requests to lease last mile circuits to reach customers’ locations, then wait for weeks or months for these orders to complete. Since our core network has no hardware dependency, it can be built on any virtualized environment, public or private. With NetFoundry, every customer gets their own dedicated virtual network overlaid across the Internet backbone and the power to micro-segment connectivity using AppWANs as they see fit, instantly.
By abstracting the network above the infrastructure and across the Internet, the NetFoundry network team can focus on improving your customer experience, adding more endpoint features at the edge of the network, more integrations, and more simplicity. For example, our endpoints can interact with the customer’s onsite physical/virtual networks through dynamic routing protocols to advertise routes to reach applications as services being added to the network. Skills can evolve without hinderance towards DevOps tools and concepts such as Infrastructure-as-Code, making deployment of NetFoundry endpoints through automation platforms dead simple.
The NetFoundry platform gives the power back to the customer. Networks spin up in minutes with built in, multi-dimensional security for packets in transit and resiliency across the Internet, so traffic engineering is simplified. Full mesh between end points is easily established by logical association and cloud brokerage. Now, network engineers can focus on maximizing their customers’ quality of experience rather than wasting away on endless configuration calls or waiting months for circuit installations.
