In the telecom and networking industry, the next big wave of technical advancement is Network Function Virtualisation (NFV) and Software Defined Networking (SDN). To clarify, NFV refers to the virtualisation of network functions such as firewalls and routers that are hosted on general-purpose compute hardware and consumed in a cloud model. And SDN refers to the programmatic management of network functions – physical or virtual.
I have written about the benefits customers will see as a result of being able to consume ‘network-as-a-service’ before, but as with all new technology implementations there are hurdles that must be overcome by every organisation looking to embrace NFV:
Standards and technical limitations: There are various bodies that are working relentlessly to define industry standards for easy adoption of NFV. However there are still several gaps and we don’t have standards for everything from day one. Apart from that there are many open-source technical projects that claim to be aligned to standards but are either not production ready yet or have technical shortcomings. On a positive note, many commercial vendors are availing this as an opportunity and facilitating stop-gap solutions. That’s good, but the big question is – Are these vendors going to retrofit their products – aligning to the standards once they are matured and adopt open source technical enhancements? I think considering this when choosing a vendor or a technology is a must as eventually the industry will mature and a bit of forward-planning with an open partner-vendor relationship will ensure a smoother ride in the long-term.
Embracing service-based approach: This is a paradigm-shift on how we provision, consume and manage networks. Going forward the industry will see “network-as-a-service”, which is composed of network functions (physical and virtual; across multiple-domains; overlays and underlays), with flows defined between them and a “service policy” associated with them. The service policy will bring a policy-driven approach where a technical metric(s) and/or a business metric(s) governs the lifecycle of the network service. For example, if the throughput exceeds trigger scale out (technical metric); on this day of the week reduce bandwidth (business metric).
A service-based approach will be a new way of delivering network solutions and this will impact the companies organisational model, both people and process, across teams – products, sales, delivery and operations. This will also impact the IT systems as there will be a need for automation across domains – transport, packet and new domains such as NFV. In my opinion, it’s a big change that will have wide ranging impact but as a trade-off will allow organisations to offer more bespoke on-demand services to their customers which are attuned to their business and technical requirements.
Agility: Being agile for any telco organisation is a big challenge but it is essential as we enter the software defined world and consume networks in a more on-demand way. Agility has to be embedded into our DNA across the roles from product management, software development to service delivery and assurance. This requires embracing new processes like agile development and new organisation models like DevOps that foster agility and innovation but at the same time provides sustainability with advancement. Bringing a turnaround change to adopt agile methodologies and DevOps in a telco environment can be daunting. As such in my opinion it needs to be embraced initially into product/software development and underlying infrastructure development, laying down the impetus for the change to follow in the rest of the organisation.
Build vs. Buy: This is another big dilemma in the NFV journey. As aforementioned, standards are not fully defined and technologies have shortcomings so the big question becomes build vs buy. ”Building” a NFV platform involves a huge-cost and organisations must be ready to invest in resources to work closely with standard organisations and open source communities in order to ensure consistency with the industry. This may also require extensive in-house engineering and testing before hitting the production line.
On the other side of the argument, “buying” means organisations have to rely on the vendors to provide off-the-shelf turnkey solutions along with capabilities that allows the buyer to customise as per the product/business requirements. In such a case, selecting a vendor who embraces open technologies and is future-centric in thinking is essential.
In my opinion as its early days, we need a pragmatic approach here. What is commodity (such as infrastructure) should be considered to be bought, as saving time and effort will pay back by moving fast. And what’s specific (such as customer portals) should be considered to be build in-house, as this will provide better customer-experience and competitive-edge.
I’m sure the industry will overcome these challenges eventually. However, in this rapid world of innovation with everyone aiming to be pioneers, the service providers will have to take smart-decisions and continuously evolve their products and architecture alleviating these challenges whilst the industry matures.
Chetan Narang is Platform Architect, Network on Demand, at Colt
What's your goal today?
1. Are you on the Colt IQ network?
Our network connects over 31,000 buildings worldwide powering companies such as Hitachi, Atos, Forbes, Arthur D Little, Brussels Airlines and thousands of others. Find out if you're Colt connected now.
2. Learn about digital infrastructure
We've written thousands of guides and white papers, regularly publish content on our blog and host regular events on everything from enterprise network connectivity, to cloud, digital transformation and the hybrid workforce.
3. Join our team
To learn more about joining our team of over 5000 people around the world, and to browse our current open roles visit https://careers.colt.net/.
