Skip to content

On Containerisation & Microservices

Featured image of ' On Containerisation & Microservices" blog

Telecom as an industry has focused a lot on functional as well as non-functional with equal weightage, unlike other pure IT applications from historical background. When we talk about deploying a switch or a telecom network equipment gear, it actually comes with a high availability. It has to be available even on a disaster situation, backwards compatibility. There are quite a few non-functional attributes for which we have to spend a lot of engineering efforts in the beginning to realize those systems, but now with the adoption of new concepts which are borrowed from IT for example virtualization, cloud platforms. We are getting added benefits microservices and containers, all this technology are helping us actually to realize the products fairly faster with a shorter life cycle because you can actually focus on small modules and get them modelled as a micro services and N number of micro services will be fitting into a chain of gears which are operating correctly and they must fit correctly and operate. Because of the underlying platform and infrastructure capabilities, we don’t have to do a lot of investment on availability or disaster recovery. They are given but we need to make sure that they are actually validated when it is deployed and working actually.

Containerization is a specific functionality that I intend to build, for example authorizing a service based on a credit like a prepaid. I am supposed to respond back very fast, but in an erstwhile monolithic application, I need to have this functionality in addition to that I need to be ready to fail over to a high availability or server. I need to be able to do logging and tracing, quite a lot of functions we have packed, the more and more functions I pack into a monolithic application, it was having an impact on the latency. I had to continuously engineer these things. So now with the approach of microservices and containerization, we have a little bit of isolation, a parallel development that can be done actually along this line and then we can fit them together. We can still respond to the network at a very fast latency, but also comply with the other functionality required like logging, tracing debugging, creating a CDR for billing all those things can actually go in parallell without impacting or getting into each other’s steps and footprints. That is the benefit I get and I don’t have to spend a lot of investment on ensuring that these things come without impacting my latency.

click to video

Signup for fresh content on SmartQA delivered to you every week.

No comment yet, add your voice below!

Add a Comment

Your email address will not be published.