An Aggressive Pivot Towards Programmable Networks

April 9, 2019 Arthur Nichols

I enjoy my job immensely. Having the responsibility to evaluate new technologies for introduction into our network at a time when the pace of change is unprecedented and only accelerating, ensures I’m constantly exposed to new and often amazing innovations. As a self-anointed ‘infophile’, I thoroughly appreciate diving deep into the inner-workings of how technologies function and exploring how best to incorporate them into our world-class network and services. I’m thankfully surrounded by many truly brilliant engineers here at Windstream Enterprise with a similar affliction.

But, here’s the thing, as a telco/ISP industry, we have grossly failed the overwhelming majority of those we serve by extending our love for what should remain esoteric protocols, standards, and componentry into how we expose our products and services. In many cases, there are legitimate reasons why the industry has gone down this path.

Employees utilizing a programmable network

Making networks accessible

For one, the path often requires massive investment to keep up with the never-ending arms races amongst carriers. Shifting from a 4G network to a 5G-enabled network is a good example. Publicly highlighting the underlying technological investment conveys performance improvement—or at least the perception of performance improvement. This goes far beyond a marketing discussion however. It’s more about how customers interact with services to achieve their desired outcomes and experiences. At Windstream Enterprise, we focus on delivering the best customer experience and keeping that experience as straightforward and intuitive as possible. A big part of this focus is enabled by to our aggressive pivot toward programmable networks (PN). The chief mission of our PN strategy is to make networks accessible. Achieving this vision requires abstracting the complexity of networking and enabling our customers to focus on what matters to them: their content and experience.

Determining software defined

In my experience, it generally takes a deep mastery of complex subjects to describe it in layman’s terms. Don’t believe me? Try teaching physics to a kindergartner. We’re squarely in the age of ‘software-defined everything’, which often carries the promise of simplified, accessible networking. I believe much of the IT industry recognizes the many software-defined platforms and solutions are anything but simple. There are many criteria one might apply to determine how software-defined something is:

Can it be virtualized easily?

 Is it “cloud native”?

Is the control plane separated from the data plane?

Are there robust and open APIs for consumption?

I would submit that software-defined in the context of managed services should be synonymous with simplified and accessible. If otherwise, question it heavily.

Historical network deployment vs. a programmable network deployment

Moving beyond the somewhat abstract and buzz-word laden view, perhaps it’s helpful to take a common deployment example and unpack how it might look in a historic approach and a programmable network solution. Let’s take the fictitious nationwide retailer Acme Tires Inc. Acme leverages proprietary point-of-sale and inventory software hosted in their private data center. They’re no strangers to network blips and have determined that every minute that a retail store loses connectivity for this application equates to $5,000 in lost revenue. So, it’s vital this app maintain high availability. It’s also requisite that the connectivity be highly secure as it’s handling credit card transactions.

What’s that look like historically? (brace yourself for the techno-jargon that follows)

Likely an MPLS connection at each store where the point-of-sale traffic is marked with the appropriate DCSP values of AF21 or AF22 applied from the LAN interface of a router segmenting by 802.1q VLAN then traversing a private MPLS VRF and leveraging eBGP peering to advertise link state on a CIDR block-level to enable failover of the data center between redundant UNIs. The data center probably leverages VRRP for a redundant hardware deployment as it’s aggregating multiple sites. I could go on and on, but you get the point; lots of complex protocols that need to be setup precisely to ensure expected performance. Otherwise, the assistant store manager’s tendency to play Fortnite from her cell phone may cause credit card transactions to take minutes to complete or customer phone calls to be choppy.

Once established and all the bugs are worked out, maybe the setup works well to the extent everything remains static. But how many business or home networks remain static for long these days? What happens when corporate headquarters decides to shift from the proprietary CRM running in the data center and adopt Salesforce in the cloud? How does the new network admin who wasn’t around for the initial access‑control‑list based policies go about figuring out the appropriate changes to ensure things continue to work smoothly in the new setup? How do they know how much traffic the current setup is generating or the baseline performance? You’re probably beginning to get a sense of the strain and challenges the traditional MPLS L3VPN model suffers as more and more shifts to cloud.

How does that look different in a programmable network solution?

For starters, rather than being provided a complex mapping of DIFFERV to MPLS EXP values and associate queue handling, perhaps the IT administrator is provided with a few questions via an intuitive interface to guide them through setting up security and prioritization policies of what’s most important to their business.

Prioritizing the customer experience

Maybe as a business owner or IT administrator, you’re given a few questions or an intuitive user interface to guide you through setting up the policy of what’s most important to your business. Is Salesforce the absolute most critical application for you? Click the radio button and the programmable network takes the complexity out of treating that traffic in a secure and prioritized manner. Programmable networking doesn’t end at application-level prioritization though. It extends to ensuring higher reliability, greater visibility, simplified connectivity between sites and the cloud, and intuitive self-service capabilities.

The bottom line is, technology that only serves to further complicate our lives should never be embraced. That’s why approaching solutions from the customer’s experience first and continuing to bring to market world-class solutions that our customers love is our priority here at Windstream Enterprise. And, with a little discipline from geeks like myself, truly simplifying the experience without all the technojargon that no one should ever have to care about.

The post An Aggressive Pivot Towards Programmable Networks appeared first on Windstream Enterprise.

 

About the Author

Arthur Nichols

Art Nichols is the Vice President of Architecture and Technology at Windstream where he is responsible for network evolution, hardware and software certification, and technical product development for all business units in the organization.

Follow on Linkedin More Content by Arthur Nichols
Previous Article
How Businesses Gain from Integrating SD-WAN and Security
How Businesses Gain from Integrating SD-WAN and Security

Security can no longer be an afterthought. It must be designed as a fundamental component in SD-WAN deploym...

Next Flipbook
SD-WAN: DIY or NSP?
SD-WAN: DIY or NSP?

SD-WAN provides the agility, performance and efficiency needed in today’s highly competitive market. But is...

×

Have questions? Chat with a Windstream network expert

First Name
Last Name
Company
Phone Number
Thank you!
Error - something went wrong!