Buying a disaggregated network

How do you buy a disaggregated network and still keep it whole?

Ever since SDN was first suggested, the idea of disaggregating networking software from the hardware it runs on has been appealing. After all, it’s been so long since we bought integrated computing hardware and software that we can barely remember it (remember those Wang word processors?).

Disaggregation brings choice for network operators, making vendor lock-in a thing of the past. It increases innovation, as carriers can take advantage of the latest silicon developments without having to wait for their incumbent vendor to adopt and test them. And, let’s face it, it radically reduces costs. Networking equipment vendors have enjoyed extremely high margins on hardware that is now available at the fraction of the price, running on the same silicon, and manufactured in the same factories as their branded equipment. That is all about to end!

So far, so good. But what about procuring a disaggregated network? How should you scope out the project?  Established networking vendors are not keen to offer their software without the high-margin hardware attached, which leaves many start-ups and smaller companies filling that innovation gap – but are these untested brands too risky? And, of course, the established networking world comes with a single point of integration – ‘one throat to choke’ – if something doesn’t work.

Let’s look at these issues one by one.

Managing scope

One of the mistakes we’ve seen people fall into is what you might call ‘procurement by feature set’. If your requirements specification list includes all the features and interfaces your existing vendors have ever offered, then you will be confined to the same old solutions – and costs and inflexibility – that you always had. To benefit from a new approach, it’s likely you’ll want to make some operational changes – adopting web 2.0 tools, for example. So, it’s important to scope out the project with a broader view of the business objectives, rather than simply a universal protocol list. Consider some service or feature rationalization, for example, as part of the project goals and consider the operational benefits of moving the networking equipment into the same environment as your cloud IT operations – such as deploying software containers on a Linux operating system. And, of course, the support requirements that you’ve traditionally applied to hardware procurement, won’t apply to the software component of the solution, and vice versa.

You could even challenge your software vendors to offer innovative pricing structures, like a bundled price for all of your subscribers, regardless of how many physical switches you needed.

Supporting legacy services

It's all very well deploying networks for the future, with cloud cost levels and automated operations. But what about those legacy services that  you still need to run? Rather than try and deliver every service feature you have in your current portfolio on the new disaggregated network, use it as a service cross-connect. That way you can use your existing equipment to keep supporting the 'long-tail' of services that need niche features, and still slash the costs of the vast majority of your simpler connections by deploying them on the new network.

Mitigating risk from new suppliers

It’s conceivable that traditional vendors could enter this new space, which would be comforting for buyers. But for now, it seems it goes too far against their vested interests, and they encourage their customers to continue to buy integrated systems, just as they’ve always done.

So that leaves buyers faced with a new and relatively unknown set of suppliers. Bare-metal-switches are now widely available from companies such as Edge-core and Delta Networks. Although these might seem like unfamiliar brands to a carrier, there are a few things that should be reassuring: firstly they use the same (and often newer) silicon that is inside existing systems from traditional vendors; secondly, they are built on the same production lines (vendors don’t build their own equipment these days); and thirdly, these ‘small’ brands can belong to ‘big’ companies. For example, Edge-core is part of a company with over $1Bn turnover, that manufacturers much of the established vendors’ kit already going into carrier networks.

And what of the software players, like RtBrick? Well, firstly RtBrick is well funded with investors that include Deutsch Telekom Capital Partners and Swisscom Ventures, and staffed by some of the best routing engineers in the world. And secondly, the very nature of starting software development from scratch has freed RtBrick and others from the technical debt that traditional vendors have to support, meaning its software is leaner, simpler and less prone to bugs – that is, inherently lower risk.

But most importantly the very nature of disaggregation means you can change out software suppliers if you need to, without touching the hardware infrastructure you’ve invested in – the best risk mitigation you can have.

And perhaps the over-riding consideration is that the highest risk approach might well be business-as-usual.  As the industry embraces a new ‘cloud-native’ way of working, to carry on as usual is to be left in a world of vendor lock-in, increasingly complex systems and a higher risk of failure.

Single point of responsibility

Perhaps the most disconcerting issue is a shift towards the carrier owning the network integration. Of course, in some ways, this isn’t new. Carriers have always had the skillsets to build and operate a complex network using many vendors, including switching and transport equipment, OSS and billing systems. And, to some extent it is an operational imperative for carriers to develop new cloud-technology skills in-house, in order to compete in the new world. Kicking off a disaggregated network project is a good first step in that process.

But that doesn’t help if something goes wrong. So, what can you do?

Firstly, make sure your software vendor takes responsibility for testing and problem-solving with the silicon providers. At RtBrick our software is composed from discrete building blocks, which makes it far easier for us to test individual features with new silicon than it is for a traditional vendor using old monolithic code. And we work hand-in-hand with the bare-metal-switch vendors to ensure you won’t be left picking up the pieces.

If that feels like a step too far, there is still the option of buying the solution through an integrator partner, who can take overall project responsibility.

But perhaps the most important message here is that the networking world is going down an irreversible path towards disaggregated systems. That means carriers will need to develop the skills to pull these systems together, and the sooner those projects get started, the better.

So, buying a disaggregated network will require some changes. At RtBrick we like to think we can help support and advise you through this process. And remember that the upsides are very significant: a step-change in flexibility, lower risk in the medium term and huge costs reductions.