Service Provider Software Updates: To Update or Not

But my love for updates doesn’t stop with regular updates; I gladly embrace the role of a beta tester. As a proud owner of a Google Pixel smartphone, I eagerly jumped into the beta program from day one and I extend the same enthusiasm to any application that offers beta updates. While I’m well aware of the potential side effects and hiccups that might arise, I usually navigate them with finesse – all for the thrill of staying at the cutting edge. 

This is me – a risk-taker who understands the delicate dance between risk and reward. However, for service providers (SPs), the stakes are much higher. Any network disturbance or outage could have dire consequences, including customer attrition, revenue loss, and a diminished net promoter score (NPS). As a result, SPs approach system updates and patching with caution, often following the “if it ain’t broke, don’t fix it” philosophy. 

Yet, updates are undeniably important. They effectively address known security vulnerabilities and introduce valuable features. For SPs, these features are pivotal, enabling them to meet the dynamic requirements of their business clients. In the intricate balancing act between risk and reward, updates pose a constant dilemma. 

Maintenance window challenges for Service Provider updates  

Service providers address this challenge by using maintenance windows. These are strategically scheduled timeframes during which crucial updates and maintenance tasks are performed on live networks. Often scheduled during off-peak usage times, maintenance windows are carefully chosen to minimize impact on operational hours and disruption to users. By planning updates in advance, SPs can enjoy the benefits of software updates and patches while still meeting their service level agreements (SLAs).  

However, these maintenance windows also present significant challenges. Coordinating schedules across diverse teams, time zones, and locations can be intricate and time-consuming, especially when peak demand expands more and more. 

Another challenge is the operational complexity of maintaining a large-scale distributed network under the maintenance windows limitations. This involves a growing multitude of interconnected locations, devices, vendors, protocols, and software components. Managing updates across this complexity without introducing errors or vulnerabilities can be daunting. 

Finally, even during maintenance windows, changes can introduce potential risks to network stability and security. Operators must constantly assess and mitigate these risks by communicating clearly and effectively within their teams and with customers, testing updates before using them, and having backup plans in case anything goes wrong. 

It is clear why SPs view maintenance windows more as a partial remedy rather than a complete solution.  

The need for a granular architecture of the network operating system 

In order to eliminate or reduce maintenance windows, vendors over the years have introduced hot patches and in-service software upgrades (ISSUs). These solutions attempt to allow SPs to patch or upgrade live system software without the need for network downtime. But to deliver this experience, the underlying software architecture must possess the capability to upgrade specific components without impacting overall system behavior.  

This underscores the need for a granular architecture of the network operating system (NOS). One particularly effective approach involves embracing the cloud-native paradigm, employing microservices and containers. This approach allows each software element to be isolated and independent from the other elements. The more granular the software is, the simpler it is to patch issues without affecting the rest of the system. 

Additionally, a granular NOS architecture accelerates the delivery of bug fixes by reducing research and development (R&D) and quality assurance (QA) efforts. This is because the software components are smaller and more modular, making it easier to make changes to them without affecting other components. 

Traditional network evolution 

The problem is that the networking industry’s sluggish pace has caused innovation to stagnate. Traditional vendors make changes slowly, and telecommunications networks continue to function much like they did decades ago, despite shifts in market needs. As a result, a task like transitioning a legacy network operating systems (NOS) to a cloud-native framework in the traditional and cautious networking realm is both challenging and time-consuming.  

In real life, some traditional vendors have moved parts of their software to a cloud-native framework. However, this has not led to the level of software granularity required. As a result, hot patches are deployed only in specific scenarios, and the ISSU concept is met with skepticism by SPs due to poor performance. 

Make changes without disruptions 

Given all of the above, it is clear that big changes will come only from new and disruptive players. It’s just easier for a disruptive software company like DriveNets to offer the software granularity needed as its NOS was designed from scratch using a cloud-native framework. In contrast, traditional vendors with older software designs would need a lot of effort to transform their network and keep supporting existing customers and hardware. 

DriveNets’ cloud-native NOS offers service providers a significant software granularity that allows them to update and patch only specific elements within their network. For example, a Border Gateway Protocol (BGP) routing element can be updated without affecting an Open Shortest Path First (OSPF) element. The shift to smaller containerized elements within the cloud-native NOS is the only way to allow reliable hot fixes and updates with fewer maintenance windows.  

However, software is just one piece of the puzzle; infrastructure design also plays a vital role in boosting reliability through granularity. DriveNets utilizes distributed disaggregated chassis (DDC) to build networks like cloud. This means breaking down the large monolithic routers into smaller, more manageable building blocks. 

Picture it like building with Lego bricks. Instead of one big core router, service providers can create a network entity by combining smaller hardware elements into a cluster. This cluster works together as a single network unit, but each tiny element also maintains its own independence. So, when updates are needed, they can be done on one piece without affecting the whole cluster. 

With DriveNets’ approach, SPs gain control at both the software and hardware levels. They can make changes, updates, or reconfigurations to individual parts without causing disruptions to the entire system.  

It’s always better to replace or fix a specific Lego piece than having to rebuild the entire set. 

A granular cloud-inspired approach to software updates  

Service providers are highly skeptical when vendors mention ISSU. You can’t blame them. Vendors’ performance to date has been mostly poor, and the benefits of ISSU are not always clear-cut. While a successful ISSU can resolve their update concerns, a single failure in the mechanism could cause significant damage. As a result, SPs are cautiously on the lookout when a vendor promises a foolproof ISSU. 

However, this doesn’t mean SPs aren’t looking to minimize the operational efforts behind maintenance windows. The cloud holds the solution – cloud providers have wholeheartedly embraced granularity in both software and hardware. This approach brings in the flexibility to make changes, updates or replacements to any part of the network with minimal impact on the entire system. Is it an ISSU? No, it’s not. However, it might be a refined update solution, where small updates are meticulously integrated into granular software elements, one by one. 

As SPs gradually adopt this granular cloud-inspired approach, trust will build and update-related concerns will gradually vanish. This will lead to improved security, faster feature introduction, and significantly reduced operational overhead for service providers.