Be careful with microservices!

-


null

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.

Comments

Post a Comment

Popular posts from this blog

SDN, NFV and Indian Telcos

-
  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 s
Read more

Are CNFs, VNFs?

-
Image
The answer is yes. Our recent report “ The VNFO – Ripe for Change ” says this loudly and clearly. Pardon the atrocious image. But I hope it encapsulates the dilemma appropriately. It is important to reiterate the reasons for including containers under VNF and in essence, Kubernetes under VNFO. Both VMs and containers are virtualization methodologies. Thus, network functions synthesized using VMs and containers qualify as VNFs. In VNFs orchestrated by containers are sometimes referred to as cloud-native NFs (CNFs). Insight Research has also employed this term as early as 2020. Over time however, we have observed that the usage of CNFs is neither consistent nor uniform. Most ‘traditional’ MANOs such as ONAP, OSM and all proprietary offerings now support containers and Kubernetes. Containers are thus one more means towards achieving the end-objective of VNFs. In such situations, Insight Research finds it more appropriate to use VNF as an umbrella term and under this term, refer to VM or c
Read more

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 an appearance - the auction process, the operator finances and the choice of vendors. Each of these challenges is a topic for separate discussion. The uncertainty surrounding 5G in India is unfortunate. 5G does promise higher data rates than its predecessor, but that is not its only advantage. 5G institutionalizes network segmentation or 'slicing' according to the traffic profile. It is thus possible for low throughput IoT sensor traffic to co-exist with data-intensive video without the network designer breaking into a sweat. For India, which has ambitions of developing world-class manufacturing, logistics, transportation, healthcare, finance and governance frameworks; it is importa
Read more