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.

 
Published on: September 16, 2019

 
Kaustubha Parkhi
Principal Analyst, Insight Research
 

 

RELATED BLOGS

India – Don’t forget 5G!

    I recently conducted a poll on the prospects of 5G roll-out in India. I basically tried to gauge the perception about the availability of 5G in India – on or before 2021; or after that. Expectedly, the overwhelming response was the latter. India has too many challenges to surmount before 5G can make … Continue reading India – Don’t forget 5G!

The NFVO Product and its Profiles

      Insight Research, in its recent report “The VNFO…Ripe for change” has broken down the market by product profile. We consider two profile categories – Direct Open Source and Proprietary. Let us look closely at the categories. Insight Research has a very categorical definition for direct open source NFVOs – those that traverse … Continue reading The NFVO Product and its Profiles

What ails 5G-SA?

    Our recent report “Virtual Core – Gateway to the “Real 5G”; brought out one thing very clearly – 5G SA is clearly taking longer than anticipated.  The reasons are many – telco ennui with the constant architectural flux without commensurate returns being the main one. Telcos have had their fingers burnt with the seemingly never-ending development … Continue reading What ails 5G-SA?

Select your currency
INR Indian rupee