How Consulting/Services Industry Enables Open-Source’s Journey Towards Maturity?

The hype around open source solutions in the networking world is probably a decade old but the open-source history dates back to as the 1970s. Linux is probably the first success story in the open-source ecosystem – setting an example of how collaborative development led to more innovations, more flexibility, and more efficiency. Eventually, the industry could find monetization gains in this open-source solution, with vendors like REDHAT/IBM offering paid support and services for this free software. Linux was followed by Apache – an open-source cross-platform web server software. The success story of Linux/ Apache was enough to push the open-source idea towards the telecom domain. Open-source solutions soon dominated the IT world – telecom industry, which was dominated by proprietary technology models, saw a revolutionary change with expensive closed hardware being replaced by intelligent software on commodity hardware. The open-source ecosystem soon spread out at all layers of the disaggregated networks. Multiple industry consortiums like Linux Foundation, CNCF, ETSI, and ONF have been working in collaboration to develop open-source components for the next-generation disaggregated telecom networks.

Open-source consortiums (Linux Foundation, ONF etc.) are working aggressively towards open-source initiatives around orchestration, programmability, and automation in the networking domain. Industry vendors are turning towards opensource initiatives for accelerated 5G roadmaps. But there is still a large customer base that is reluctant to give up proprietary vendor solutions in favor of open source solutions. Consulting/Services companies working with these customers (OEMs, telcos, operators) face unique challenges in the advocacy/curation of open-source solutions to them. This blog article details out some of the challenges that the industry foresees in accepting open-source solutions in building big/complex systems and how the consulting/services industry, offering system integration services, is helping out in product evaluation, integration/augmentation of open-source solutions as per the business use cases of their customers and curation/maintenance of the customer solutions as these open-source solutions move towards maturity.

Challenges of Open Source Solutions

The adoption of open-source solutions is attractive in terms of faster time to market but they come with the additional demand for a continuous upgrade strategy. There is always a risk of hitting a blocking issue or bug when these open-source solutions are dropped into a production environment. Unless the solution has a sufficiently large developer community backing it, getting fixes for any such bug becomes a herculean task. Regular contributions from a responsive developer community are very critical for the mass adoption of an open-source solution. One needs to factor in the time and cost investment involved in picking new releases/fixes of open-source solutions for getting critical bug fixes or new features added by the community. Therefore, the telecom industry still sees a lot of resistance from many enterprises, in accepting open-source software.

Most of the production-ready open-source solutions are complex to understand and integrate. They involve a learning curve which at times is beyond the capacity of many organizations. The open-source developer community focusses more on innovation and less on usability & stability. These open-source solutions expand speedily in the feature list but supporting documentation and stability always take a lower priority. Hence integrating these open-source solutions in a production environment becomes a daunting task.

Another challenge often witnessed when using open-source solutions in production-grade systems is when they become orphaned due to lack of community support or new use cases entering the market. This risk applies to bigger open-source initiatives also when developers stop supporting or updating older programs. For instance, HoneyComb and HC2VPP were quite popular options to configure VPP devices via netconf or restconf. But since the last two years, no support or fix is being provided for HoneyComb/HC2VPP and all their developers have moved to another open-source option Ligato, /which they claim is more fit for cloud-native applications.

Entry of System Integration services

Operators & enterprises are looking for a more open network based on h/w and s/w from different vendors and open-source solutions, rather than from anyone big vendor. This requires stitching these different components together. This has led to the emergence of system integration services from the consulting/services industry who offer their skills in the latest cloud and software-based technologies to build these open networks. It enables the operators/enterprises to focus on their core technologies (applications) and rely on these consulting companies to gauge, integrate & maintain the open-source alternatives as per their business use cases.

From Vision to Reality – Product Evaluation

The first stage of stitching in open-source solutions into bigger systems is to evaluate the solutions with respect to the business/technical requirements stated by a customer. There might be multiple open-source solutions catering to a requirement. For instance, software-defined networking (SDN) is posed as a technology enabler in next-generation networking. Service providers, operators, and enterprises are contemplating replacing their traditional networking devices with SDN based devices and use SDN based applications to program the network fabric based on their business use case. On exploring the SDN market, they are bound to face tough decision making, with numerous open-source SDN controllers pitched in the market.

Taking the example of two of the most popular options: OpenDaylight(ODL) from Linux foundation is more fit for cloud and data center deployments. ODL has a vast range of YANG based networking models to control the topology or the underlying network in a data center. It provides applications to integrate with VIMs like OpenStack (such as VTN Virtual Tenant Manager) or southbound protocols that are used in data centers, such as OVSDB. For the telco domain, ODL has limited use cases and southbound protocols, such as BGP-PCEP. On the other hand, Open networking Foundation owned ONOS is more focussed on topology discovery and east-west communication between multi-site SDN instances, to ensure the state synchronizations. Thus, it is more fit for the telco domain. It has many use cases and applications for telcos, such as CORD, Packet Optical, SDN IP etc. Another one in the market is Tungsten Fabric, previously known as openContrail, which integrates well with cloud orchestration software to provide services such as service function chaining and tenant network isolation but it is restricted to manage networking on hosts, not on physical routers and switches. Service providers that offer Private Cloud, Virtual Private Cloud (VPC), or Infrastructure as a Service (IaaS) require a networking platform that can support multi-tenant network virtualization. Tungsten fabric is a good choice for them.

Consulting/services companies offer their experiences in these open-source alternatives and help their customers gauge these products as per the customer needs. For instance, when choosing the SDN controller, they try to understand the following:

• What kind of network is the customer responsible for – is it a data center or is it a private cloud deployment at the edge or is it a service provider’s end to end network?
• What kind of inbuilt network models and use cases does each SDN controller have? Customer-specific applications need to use these models to communicate with an underlying network device.
• How does the customer plan to program his devices, is it Direct Fabric Programming where the SDN controller communicates directly with SDN-enabled switches or does he want Overlay programming where the SDN controller does not rely on programming the underlying network switches and routers. Instead, it builds a virtual overlay network on top of the existing underlay network.
  Based on the responses to this kind of questionnaire, the consulting/services companies can help operators/enterprises choose the SDN controller which deems fit as per their requirements. They help the customers gauge these options based on industry feedback and their own experiences with these open-source alternatives when working with similar customers in the past. There are instances when the customers themselves are unclear on some of these questions and rather look forward to closer interactions with the consulting/services companies. These companies need to consider the risk of insufficient knowledge or incorrect assumptions made by the customer while answering such questions. Detailed discussions between stakeholders can mitigate this risk to some extent.

For complex decision making on behalf of their customers, consulting/services companies might run proof of concepts around multiple open-source solutions catering to a business need. This helps to estimate the amount of effort and the complexity involved in integrating these open-source solutions in the customer’s production environment. It also gives rudimentary feedback on the stability of these solutions.

From Vision to Reality – Product Integration & Community Support

Once the product evaluation stage is crossed and an open-source alternative has been chosen to cater to a business need, the next stage is to integrate this (and maybe other open-source solutions) into a bigger system – as per the final use case of the customer. Most of the developer community responsible for such open-source solutions focus more on adding new functionalities to their solution to make it more competitive than other similar solutions in the market. With limited time and resources, this leads to compromises on testing and documentation. Many market surveys done on these open-source solutions quote harrowing experiences of the vendors trying to integrate these solutions.

For instance, OpenStack is one of the most popular virtualization infrastructure manager (VIM) for private cloud deployments. Their survey reports indicate how the deployment and operational complexities and the lack of proper documentation hinder the acceptance of OpenStack in a production environment. Operators/enterprises frequently rely on consultancy/services companies (who are already covered in scars from previous deployment experiences with other customers) to help them set up their private clouds based on OpenStack or analyze their logs in a production environment and resolve the issues by taking upstream OpenStack releases which might be fixing these issues or coordinating with the OpenStack development community to figure out any workarounds to avoid these issues.

On the one hand, the consultancy/services companies help operators/enterprises integrate these open-source solutions. On the other hand, constant interaction between these companies and the open-source development community helps the developer community improve on their products. Based on the feedback received or issues reported as part of the integration activities of these companies, the developers associated with the open-source solutions can prioritize their release plans. Since the consultancy/services companies get to interact with a varied customer base, having different expectations from an open-source solution, their feedback can help the developers decide the future roadmap of their solution, leading to higher acceptance across the industry.
Once the product evaluation stage is crossed and an open-source alternative has been chosen to cater to a business need, the next stage is to integrate this (and maybe other open-source solutions) into a bigger system – as per the final use case of the customer. Most of the developer community responsible for such open-source solutions focus more on adding new functionalities to their solution to make it more competitive than other similar solutions in the market. With limited time and resources, this leads to compromises on testing and documentation. Many market surveys done on these open-source solutions quote harrowing experiences of the vendors trying to integrate these solutions.

For instance, OpenStack is one of the most popular virtualization infrastructure manager (VIM) for private cloud deployments. Their survey reports indicate how the deployment and operational complexities and the lack of proper documentation hinder the acceptance of OpenStack in a production environment. Operators/enterprises frequently rely on consultancy/services companies (who are already covered in scars from previous deployment experiences with other customers) to help them set up their private clouds based on OpenStack or analyze their logs in a production environment and resolve the issues by taking upstream OpenStack releases which might be fixing these issues or coordinating with the OpenStack development community to figure out any workarounds to avoid these issues.

On the one hand, the consultancy/services companies help operators/enterprises integrate these open-source solutions. On the other hand, constant interaction between these companies and the open-source development community helps the developer community improve on their products. Based on the feedback received or issues reported as part of the integration activities of these companies, the developers associated with the open-source solutions can prioritize their release plans. Since the consultancy/services companies get to interact with a varied customer base, having different expectations from an open-source solution, their feedback can help the developers decide the future roadmap of their solution, leading to higher acceptance across the industry.

From Vision to Reality – Product Maintenance

Bringing up a system using open-source alternatives is lucrative in terms of faster time to market and lesser development effort. But this is not without side-effects and does not involve a one-time deployment or integration effort.

One crucial factor when picking an open-source solution is the number of developers associated with it. Fewer people in the developer community of an open-source solution means a greater risk of the solution getting orphaned. This kind of an open-source solution, if picked as an integration candidate, needs hands to fix the issues faced in the production environment. Another side of the story is when an open-source solution has larger community support. This mostly leads to lots of feature enhancements and frequent releases of the solution. Integrating this kind of open-source solution demands regular release upgrades. There can be instances where some feature gets deprecated in new releases of an open-source solution and the existing end to end system has some operations based on this feature. For instance, OpenStack recently deprecated one of their telemetry services – any system which had designed some automated scaling logic based on this service, requires a change. This kind of product maintenance is also needed when using these open-source solutions.
This is where the consulting/services industry has proven its mettle. They offer product maintenance services ranging from fixing bugs in small-sized open-source solutions or upgrading releases and picking new features/fixes for bigger systems. For instance, in an OpenStack based private cloud, when setting up initially, one can choose the latest release. But OpenStack community provides a new release every 3 months. Any operator/enterprise here has two options – either choose commercial OpenStack versions offered by vendors like RedHat and Mirantis. These vendors have their own release plans aligned with open-source OpenStack versions and hence their customers get continuous release upgrades by paying high maintenance costs for their private clouds. Another possibility is to involve the consulting/services industry for this kind of maintenance – these companies offer services in terms of regular release upgrades and coordinating with open-source developer community for bug fixes, providing them with test data/observations required by the developers.

A crucial aspect for product maintenance of an end-to-end system leveraging open-source is, to keep a constant vigil on the new open-source solutions which can work as alternatives to the previous choices made. Consulting/services companies, often as part of their RnD initiatives, invest heavily in upskilling their workforce on the trending open-source solutions which help them guide their customers into migrating from one option to another. For instance, OpenStack was the de-facto choice for private cloud deployments a few years back. But with applications migrating to the containerized environment and stringent high availability requirements, many of the private cloud deployments are transitioning to Kubernetes. Kubernetes is the most popular container orchestration tool and unlike OpenStack, Kubernetes has built-in high availability and service discovery. This does not mean that Kubernetes will replace OpenStack in all scenarios. There will be instances when both Kubernetes and OpenStack will be used together where Kubernetes offers better stability and OpenStack offers better security mechanisms. This kind of migration/integration requirement needs sufficient hands-on experience on both these private cloud management platforms.

Many of these consulting/services companies participate in the technical discussions of these open-source solutions highlighting the kind of issues they are facing when integrating these solutions for their customers. In fact, there are Hackfest events organized every year for big-sized open-source solutions like OpenStack, Kubernetes, OpenSource MANO, etc. which is open to all and sees active participation from these consulting companies, where they get a deeper insight into the architecture of open-source solutions. This gives them higher confidence in offering these open-source solutions to their customers when working on their business requirements. Since these consulting/services companies concentrate on smaller parts (i.e. the open-source solution being integrated), of their customer’s end to end network, they get more time/opportunities to focus on these open-source solutions. Better understanding with respect to the design/architecture helps them fix issues and contribute back to the developer community, which augments the stability of the solution.

Conclusion

With the emerging focus on open-source hardware and software in the next generation networking, many leading operators and enterprises are actively participating in these open-source solutions. But most of these big players try to align these open-source solutions as per their own respective use cases. This is where consulting/services companies, working with varied customers, bring in a broader outlook to these open-source solutions. These companies offer system integration and product maintenance services for various open-source solutions, thus improving acceptance of these solutions across the industry. This is proving advantageous for all the stakeholders. Operators/enterprises get more time to focus on their actual product/solution. Consulting/services companies have monetary gains and continuous upskilling when working on these open-source solutions. And lastly, with more hands-on experience in open-source solutions, these solutions gain more stability and maturity.