Microservices - The wind beneath the CNF wings
September 20, 2019
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 clear as to why containers are able to leverage CI/CD constructs effectively. The 5G-PPP terms microservices as loosely coupled, but highly cohesive. The cohesiveness helps in quickly establishing connections with other microservices, while the loose coupling allows for independence and autonomy in the development cycles of individual microservices.
Microservices have been instrumental in initiating cloud nativity into telecom device engineering.
Microservices have positive implications for design, troubleshooting and scaling.
- On the design front, microservice-based CNFs offer greater granularity into the CNF architecture. Designers are now able to fine-tune parameters at the level of individual processes rather than dealing with entire applications.
- Microservices make it possible to design, test, operationalize and manage individual functional strands in a CNF.
- Microservices facilitate the pinpoint scaling up of certain segments of the CNF to the required extent, helping in efficiently managing available resources.
- Conversely, faulty or problematic microservices can be curtailed or brought down and repaired without obstructing the function of other well-functioning microservices in a CNF.
What is required for telcos and vendors is to keep their eyes open to the performance penalties exerted by microservices and deftly compensate them with the benefits that microservices bring to the table. This exercise requires a clear-headed approach to RoI calculations. The RoI assessment is particularly important for tier 2 and tier 3 telcos as so that they don’t end up wielding the short end of the stick.
All in all, CNFs are not really optional. The next generation of telco operations are bound to demand highly customized products. Telcos will continue to push for greater depth in adaptability and greater control in tunability of their devices. At present, there is nothing really that comes anywhere close to microservices in achieving these objectives.
Be careful with microservices!
September 16, 2019
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 veritable problem of plenty. Agreed, that they reduce the size of individual service strands and the all the development and similar overheads associated with it. Microservices tend to multiply in volume however, in their quest for modularity. Administrators find it extremely challenging to keep track of them. Larger telcos may be able to absorb the design and developmental overheads, a large majority of small and mid-sized telcos cannot.
On the design side, many tend to forget that microservices contribute to latency. Summoning individual microservices requires the architecture to initiate network calls.
Robust product engineering methodologies and guidelines are a must. If you leave the designers alone in the driver’s seat, the lure of multiple microservices may sometimes entice them into building multiple routes or pathways. This is terrific from a redundancy perspective. One should question however, if the telcos have the wherewithal to manage the ensuing tracking and monitoring demands. The enthusiasm of the system designer has to be tempered by the pragmatism of the telco network administrator.
The telco challenge on managing this evergrowing hydra-headed microservice-based design behemoth is real. In fact, we encountered vendors that handhold telcos into selecting the right partners for CNF development. Some vendors have also developed marketplaces for telcos to pick and choose design elements.
Let us be clear - at full capacity, microservice-driven architecture often consumes more resources as compared to a monolithic application custom-designed for similar purposes.
If such is the case, why push for CNFs?
I will discuss probable reasons in my next post.
SDN, NFV and Indian Telcos
October 21, 2018
I returned with useful insights from the SDN-NFV India earlier this month. There were two discernible trends – optimistic solution vendors and cautious telcos.
Indian telcos are worried about the following:
- Indian telcos, including the largest ones, are genuinely concerned about the solidity and stability of SDN and NFV products. Telcos think that vendors do not completely appreciate the difference between a service outage suffered by Facebook and an outage suffered by a licensed cellular operator. The former can be irritating, the latter can be catastrophic.
- Indian telcos are also looking towards concrete ways of making money from SDN and NFV. What works with telcos in the US may not work with Indian telcos.
The above points were recurring themes. You could say that Indian telcos were never among the early adopters of technologies. You could also say that Indian telcos are bleeding far too heavily in the present to think rationally about overhauling their networks.
Plenty has been spoken and written about how SDN and NFV products and solutions continue to mature and grow in stature. In light of the above apprehensions, I think that the vendors have their task cut out on educating their customers in India.