Don t Fly Blind Through the Clouds: Avoiding the Pitfalls of Virtualization

Transcription

1 By Pablo L. Martinez, 06 May, Don t Fly Blind Through the Clouds: Avoiding the Pitfalls of ization These days, clouds don t have a silver lining. It s more like a vein of gold in particular when virtualization is added to the picture. ization involves abstracting a function from its hardware into a logical instance that can be manipulated in software. This makes the implementation of these functions more elastic and faster, with on-demand instantiation and dynamic fine-tuning of performance. ization mitigates some of the operational challenges of traditional networks, thus making possible new ways of doing business for communication service providers (CSPs). Not only that, virtualization enables a more systemic, cohesive treatment of the business, allowing CSPs to manage customer experience and the network as elements of a common orchestration scheme. However, realizing these benefits involves re-orienting operations to deal with more fluid network services and functions, and to stay in control of automation. Success depends on having the operational experience and discipline to properly visualize, organize, characterize and assign functions to hardware resources in a stable, controlled way.

2 Letting functions fly in the clouds The objective of telecom virtualization is to enable the on-demand instantiation of network and IT functions in a format easier to load-balance, scale up/down and move dynamically across hardware resources distributed over the network all while maintaining the continuity of services and keeping service quality consistent. As shown in the following diagram, these virtualized network functions (VNFs), which are the manifestation of ETSI s s ization (NFV) initiative, are combined to form network services which may also include functions running on dedicated, specialized hardware (i.e., physical functions). Application Service Service Physical ization Layer Hardware Infrastructure (Resources) Software Defined ing (SDN) goes a step further to abstract the network into a single entity easier to program and, therefore, automate. SDN makes the network programmable (via APIs), so that NFV s elasticity can be automatically and dynamically managed thus enabling just-in-time (on-demand) operations.

3 So, what will be different? NFV/SDN s abstractions introduce new software entities, such as VNF managers and virtual infrastructure managers, to handle the proliferation of software endpoints. Inventorying these endpoints requires additional dimensions. The decoupling of network functions from hardware resources creates flexibility, but that flexibility results in complex mappings between functions and hardware. This is due to a VNF s ability to manifest itself fluidly across distributed hardware resources, which can be dynamically added, modified or removed. OSS - BSS Orchestrator Physical s Manager Hardware Infrastucture Manager Hardware Orchestration is another impacted area. With NFV/SDN, it has a bigger scope than in traditional OSS. To manage the benefits of NFV and SDN, orchestration needs to consider all aspects of a function s lifecycle from instantiation, SLA-aware resource allocation, proactive scaling/load balancing/migration, charging/billing, security, assurance and termination. These aspects need to be harmonized into a common service model to properly drive workflow indexing in service catalogs.

4 Making sure everything flies faster To fully realize the benefits of NFV and SDN, OSS software will have to work harder and do more. The inventory data model has to document new layers of abstraction and the dynamic interdependence among its entities. These entities include the applications, network services, virtual and physical functions, and the hardware resources either owned or accessed from third parties. In addition, inventory systems will have to work tightly with configuration management databases (CMDB) supplemented with automated discovery and reconciliation capabilities to track resource configurations as they change over time. This is needed to optimize hardware utilization and to find suboptimal configurations or redundant instances of virtual functions, since these can waste hardware or impact ecosystem interactions. An accurate, up-to-date inventory is critical when automatically assigning resources and triggering work orders for activation. With virtualization, the activation process needs to consider additional factors, such as workload balancing across pools of hardware resources. It also needs to work more in tune with dynamic optimization algorithms, which need to factor in computing and storage capacity requirements to make sure VNFs get properly dimensioned hardware. The elasticity and programmability of NFV and SDN take automation to the next level where an orchestration platform is instantiating and dynamically morphing VNFs, and where networks are capable of reconfiguring themselves continuously in real

5 time. However, automation consumes electric energy. As a result, orchestration needs to factor in aspects of building facility management when coordinating workloads to manage energy costs as well as performance. This automation is also faster. With NFV and SDN, the network is so elastic and programmable that there is no need for extensive pre-provisioning of the network as it is required today. provisioning could be executed on-demand at the point of sale. But just-in-time operations still require supervision. This is where Big Data analytics may play a role by helping CSPs to anticipate the behavior of automated networks. Of course, virtualization s higher reliance upon software makes user access control more critical. Orchestration needs to be highly accessible to support the new operational environment, third-party ecosystems and legacy OSS. This requires northbound APIs that are properly exposed via the service catalog. API exposure involves authentication, authorization, encryption and data integrity, along with the partitioning of the software into different administrative domains to allow third-party access. The sky is the limit As CSPs begin to virtualize whether to add cloud services for customers and partners or to modernize their telecom network the benefits will be clear. Decoupling applications from dedicated hardware, and making hardware far less of a concern overall, will reduce CapEx and make it easier to create cloud ecosystems with third parties. By removing some of the limitations imposed by the hardware, services and networks can be more responsive to customers needs. There is, however, one caveat: just as with traditional networks, the software to manage virtualization will be key to delivering these benefits. Already, OSS is beginning to evolve with the virtual future in mind, and this evolution will only accelerate in the next couple of years. It won t be long before CSPs are flying high, not flying blind, through the clouds. Ericsson 2015