Cloud-native Transformation

The rapid adoption of web-scale and cloud technology is resulting in the global transformation of all industry sectors including telecommunications. Clear evidence of this transformation is seen in the 3GPP 5G mobility standards where cloud-native technologies are fully embraced in the 5G stand-alone (SA) signaling core. As a consequence, mobile operators are moving to a web-scale architecture and making the paradigm shift from managing dedicated appliances (hardware and software) to loosely coupled software services that run on commodity hardware. The evolutionary path from developing and operating monolithic appliances to cloud-native applications is no trivial undertaking and requires a solid understanding of micro-service architecture.

Originally, the multi-processing (MP) paradigm was the only way to implement a concurrent Unix based network server application. An application process spawned by the operating system was given a single thread of execution and its own private memory address space. Simple network server applications typically had a single daemon process that listened for incoming socket connections and spawned a new application process to service the connection. When the client disconnected, the associated process terminated, and its resources were reclaimed by the operating system. Server applications often spawned multiple child processes that required collaboration and communicated via an inter-process communication (IPC) facility, such as, domain sockets, pipes and shared memory. In this manner a server application would scale to support hundreds of connected clients. Unfortunately, the spawning of processes and marshaling of memory-based data structures across an IPC channel came at a significant cost to processing latency.

The multi-threading (MT) paradigm came into popularity with networking applications as a means to minimize processing latency. Operating system threads were scheduled for concurrent execution like conventional processes, however, threads within a process shared the same memory address space. A multi-threaded network server would listen for socket connections on one thread and simply pass the connection in memory to a second thread for processing. The latency associated with spawning a process, marshaling data and all inter-process communications were completely eliminated. Threads that simultaneously manipulated the same memory objects had to be carefully synchronized to ensure proper behavior. Failure to do so would result in unintended results, race conditions and even processing deadlock. While the MT paradigm yielded lower processing latency, it could only scale with the machine resources of its host server.

The Cloud-native paradigm builds on the best of both MP and MT technologies to achieve massive scale, resiliency, accelerated feature velocity and unprecedented levels of automation. Simply porting existing monolithic software systems to a virtualized and/or cloud-based infrastructure will unlikely realize the tremendous advances promised by cloud-native technologies. Legacy systems will need to be redesigned into a set of loosely coupled micro-services that execute within a highly cohesive cloud-native software platform that enables a consistent operational experience for the broad spectrum of telecommunications applications.