06 September 2017

Talking the language of Softwarization: towards Service2Vectors (part 1)

Cost reductions and new revenues flows are key business drivers for the sustainability of Network Operators. Telecommunications Infrastructures are growing in heterogeneity and complexity, but they should be at the same time agile and flexible, reliable and programmable...to cope with market dynamics (wih increasing "frequencies").
This is a new cycle of "complexity", in one word. It is ever-growing in Nature, by definition, at least up to when a "tool" is found to "tame it" and to make a "phase transition" to a new "state".
We know, that recent advances in enabling technologies such as SDN and NFV are offering the enablers of decoupling the hardware and software architectures and introducing the virtualization of resources (the so-called Softwarization of Telecommunication infrastructures). At the same time, the evolution of Cloud Computing towards Edge and Fog Computing, Artificial Intelligence, multi-level APIs, etc etc represent other technology trends which are intercepting SDN and NFV in shaping future Software Defined Infrastructures.
Still management, control and orchestration systems of SDI should make sure that the infrastructure services, characterized with specific KPI (Key Performance Indicators), are provisioned to Applications and Users upon their specific requests. But this implies carrying out operational tasks in a new way: management and control of both physical (e.g., physical nodes and IT servers, physical connections) and (millions of) virtual resources (e.g., virtual machines or containers, virtual links and virtual network functions), scheduling and end-to-end orchestration of  virtual network functions, and services...etc. In fact, Softwarization means that virtualized network functions and services can be dynamically allocated and even executed in the Cloud Computing and/or Edge Computing (e.g., in centralized Data Centre and/or in mini-Data Centre, which can be located in correspondence of network PoPs equipped with processing and storage capabilities).
Also, this is allowing to exploit the model of  Service Chaining (also known as Service Function Chaining) in SDI. In general, Service Chaining is about creating and provisioning a network service as a sequence or chain of interconnected network functions and services, by hooking the logical resources where they are executed through the steering of the traffic.
Obviously, just like applications, said network functions and services of a SDI can be modeled and developed by combining software tasks and/or Microservices and network primitives. As known an application can be modeled as a core part containing the application logic and adapters that interface the application with the external world. Examples of adapters include database access components, messaging components that produce and consume messages, or web components that either expose APIs or implement a User Interface (UI). Instead of developing monolithic application, Microservices architectural paradigm proposes split the application into set of smaller, interconnected services (called Microservices). Microservices are basically modular software components each of which runs a unique process which can be deployed independently, with minimal centralized management. For  example some Microservices can expose an API that’s consumed by other Microservices or by the application’s clients, other Microservices can implement a web UI.
One advantage is that these smaller components can be developed independently and scaled independently: this is improving agility in software development and operations, promoting resilience and scalability. Microservices can be used also for developing network and service functions in SDI: in fact a Virtual Network Function can be decomposed in a sequence/combination of Microservices and/or network primitives.
Generalizing, Microservices could be seen as any kind of packet processing primitives (also called network or service primitives) which could be dynamically composed to be executed in different hardware architectures. Example of said packet processing primitives could be: packet forwarding, packet inspection, modification (including dropping a packet), queuing, flow control and scheduling, or any other software tasks/functions (such as those one required to create any VNF), to provide access to nodes (e.g., node address, interfaces, link status) and its storage an processing resources. 
Part 2 to come next !

No comments:

Post a Comment