Getting Your Head Out of the Labs: SDN PoC to Deployment

Service Providers know what’s coming down the road; Network Automation to create composable infrastructure using Software-Defined Networking and Programmable Data Planes. The past five years have shown us that software and Over-the-Top players have the power to disrupt the telecom industry. Software, as well all know, provides a much more rapid realization of business objectives with dramatic cost efficiencies. A tool to support the transformation to more software-centric networks, virtualization is being adopted by Service Providers keen to get started. Building on virtualization, they rightly sense that the best way forward is to leverage open source code and adopt open standards. The source code and the standard definitions were all available online and could simply be downloaded, it seems reasonable to assign teams and get something up and running in a lab.

With all of the consortiums, standards bodies, and open source projects vying to fill various gaps in the ecosystem, many Service Providers choose to focus on one of the most critical leverage points, the SDN controller. The Software-Defined Networking (SDN) controller serves as middleware, or an abstraction layer, between business logic and the network element domain. Business logic includes service provisioning, which relies on pushing configuration data down into the network. The SDN controller takes on this heavy load of maintaining connections and handling the details of device configuration to simplify the business logic. This is a common story - we’ve seen it many times - and if often ends in the same way. 

Here is an example of how it goes from there:

The team had some initial successes, but only after a lot of grunt work in building, deploying, and testing an initial snapshot of the open source code. Using the codebase to support a standardized interface proved challenging as the standard models were large and complex. The team had to climb steep learning curves on many new technologies, from Java libraries to build and test tools. 

The installation did indeed perform some limited functions well, and it looked as though some interesting use cases could be implemented on the new platform. It was time to consider launching services into production on the new platform.

When the team began to address scaling, performance, and security concerns, and face the challenges of integrating the platform into both the network domain and the existing business applications, the project ran aground. There were just too many technical challenges facing a small team of ‘newbies’ to the underlying technologies. 

The organization remained convinced that the trend towards open systems, with multi-vendor integrations through open sourced technologies was still the end-state they must achieve. They needed a dedicated team of experts in the relevant technologies to make their ambitions reality. The question became - how to best find and utilize such a team? Build or buy?

In the open source world, it has become common for an organization to partner with a team that has been purpose-built to support an open source project. While retaining all the benefits of open source, the important details of getting the platform to work at scale can be off-loaded to those who have the know-how and experience. 

An open source code base in itself represents thousands of hours of work and the expertise of many highly skilled contributors. There is tremendous value stored in the code. And the open source community can help ensure that bugs are fixed and new features are carefully added. But to capture this value in a production environment can be challenging. The codebase itself does not address even such prosaic issues like installation, testing, and maintenance.

Open standards are important as well - something open source helps drives the development of -  to provide a means for interoperability between systems. Network elements typically expose their functionality with vendor-specific API, leading to a tightly-bound integration between business systems and the device domain. Using standardized interfaces, either at the network element or a layer up in the SDN controller, allows Service Provider logic to become loosely-bound to the network layer, be device-independent, supporting a multi-vendor network in a cost-effective way. 

Along with the adoption of open source, organizations often find it helpful, if not necessary, to evolve new practices and skillsets, and let go of older less efficient processes. For example, Introducing Continuous Integration and Continuous Deployment (CI/CD) pipelines greatly improve the efficiency and reliability of iteratively developing a solution. Decomposing functions into microservices, each with its own API, speeds up development as each can be individually deployed and tested.

This is when our phone over here at Lumina Networks rings. The Service Provider understands that we have the expertise to support deployment of their project and to train their teams in the process. We become part of the team responsible for the open source OpenDaylight (ODL) SDN controller, offering support and services to help them succeed in their migration towards network automation. 

Why Lumina? 

Simply put - we’ve been here, and successfully done that. With several tier-1 transformations projects supported, we’ve helped take open source network control to production environments many times. Our teams of software and open source experts have learned what works, and what doesn’t. We’ve built these learnings into our controller and continue to lead and contribute to the ODL project. In partnership with our customers, we’ve made the ODL code base more scalable, secure, and feature-rich. 

Our development team provides critical extensions to the core controller to address real-world needs, and applications to enable common use cases, and tools which provide flexible extensibility to offload complexity from business logic.

The Lumina NetDev services team is dedicated to helping Service Providers install, integrate, and validate their SDN solutions to execute on their business objectives. Our team of experts help Service Providers design proof of concepts to evaluate our solutions in their labs and then work directly with their technical teams to transfer knowledge not only on the controller but on the tools and processes to efficiently capitalize on SDN. This expertise helps our customers in-house, but can also be reversed to help champion needs in the open source community. 

Lumina support provides Service Providers a ‘single throat to choke’ for immediate issue resolution.  

The promise of network automation to cost-effectively increase service agility is real, but the details are tricky. The industry is starting to see a lot of success when Service Providers partner with companies that they align with on a philosophical level, like Lumina. 

For more information about how we support open source transformation journeys, please visit our website

Additional Resources: