Be careful with microservices!
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.
|
RELATED BLOGS
“En-caching” the RAN – the AI way
The AI-RAN Alliance: The idea whose time has come
