Nerd alert! For a while I’ve postponed my chance to geek out about one of the latest buzz words in the telecom industry. Over the last few years, the telecom industry has been rampant with technical terms such as virtualization, network functions virtualization (NFV), orchestration, and lately containerization. Salespeople throw terms around like there is no tomorrow in hopes of getting prospects engaged and excited about their products. One term that is trending now is microservices architecture (MSA). Now, I did say I was going to geek out, but I promise not to get too technical, so hopefully, you will make it to the end of this blog.
In general terms, MSA involves separating each platform/software functionality into a container that runs on its own. What is the point on that, you ask? Well, let me give you a typical example. A Unified Communications platform (UC) supports multiple features such as calling, conferencing, collaboration, and instant messaging. Imagine that you have a surge in video conferences; the typical UC platform uses a monolithic architecture such as a Telephony Application Server (TAS), which runs all the services. So, the peak in video conferencing will basically cause the entire platform to run out of hardware resources affecting everything else. The only way to address this issue is to increase the hardware resources of the platform as a whole, even if the other services do not require additional resources. MSA allows you to separate all these functionalities into separate containers and scale them independently, allowing much better use of your hardware resources. This is a basic example, which actually does little justice to all the benefits of MSA, but it’s a practical one.
Looking at it from a different perspective (a less geeky one), MSA also offers an exciting business opportunity. If all services on your platform are interfacing using standard APIs, then you could slice parts of it and provide those as individual services. Again, using a UC platform as an example, you can take the conferencing microservice and allow your customers to build their own conferencing client and interface only with this specific container. The same applies to calls or instant messaging. Thus, MSA can enable offering both a turnkey application, such as UC, or simply selling the “sliced” services. Another MSA advantage is that each service is agnostic and performs a limited number of tasks without interfering or being affected by the others. This isolation enhances the capability to monitor, troubleshoot, and manage individual containers.
To get more specific, and still looking at MSA from a business perspective, the Dialogic® BUZZ™ UC platform is a great example of MSA in action. A customer may initially purchase Dialogic BUZZ to be used as a UC platform, and can also offer UC as a Service (UCaaS) to their customers if desired. Simultaneously, they could reuse the same platform and turn it into a Communication Platform as a Service (CPaaS). This flexibility will allow our customers to diversify their offer and above all, give them the ability to innovate on their own. The microservices distributed architecture is a crucial enabler for this business model and the reason why Dialogic chose to take this path. From a technology vendor perspective, MSA will also allow Dialogic to continue innovating and adding functionalities without disrupting the existing deployment. New features become new microservices, which are seamlessly added. It’s a DevOps dream! (There I go again, getting carried away.)
These are exciting times. Dialogic recently released Dialogic BUZZ 4.0, which leverages a partial microservices architecture. Over the last few months, we have been turning BUZZ into a full MSA-based platform. This migration process continues, and our customers will continue to reap the benefits. Dialogic BUZZ has become simpler to install, manage, and scale – and soon will also allow customers to monetize it in different ways. While we are in this process, we are already planning the next step – enhancing the microservices to a full "Service Mesh" topology. But that's a story for another day…