The Changing Face of Telecommunications

In my last post, I discussed the pitfalls of microservices, which power CNFs. In this post, I will present the other side of the story. We know that microservices dissect individual CNFs into a mesh of interdependent services that can be containerized independently of each other. I would like you to take a moment a relook at the usage of interdependence and independence carefully. A given CNF is thus a combination of multiple microservices. Our report “Containers and Telcos: Ready to Tango” chronicles and describes several CNFs. Metaswitch for example, offers its virtual IMS (vIMS) as combination of multiple microservices such as SIP routing, HSS proxy, distributed timer database, in-memory open-source database, file-based open-source database and open-source configuration distribution service. Individual microservices have independent development and deployment schedules; and are therefore often managed by dedicated teams. The methodology of microservice development also makes it clea

Of late, cloud native network functions (CNF) have been gaining steady traction. We tracked the market for CNFs in our report Containers and Telcos - Ready to Tango?. The market prospects for CNFs are very bright, with a compounded annual growth rate (CAGR) in excess of 50%! 5G and its cloud-native push is undoubtedly the most compelling driver for microservices. The edifice of CNFs, and containers, rests on the tapestry of microservices. I will discuss the benefits of microservices in a later post. The above report is replete with such examples. Make no mistake – CNFs are here to stay, and microservices will drive them deeper into the telecommunications domain. This post is about the cautioning factors surrounding microservices, especially in the network equipment design domain. Most of the challenges associated with microservices are accentuated due to the set, well-entrenched, tried and tested methodologies that dominate telecommunications equipment engineering. Microservices pose a