Migrate .NET MSMQ to Kubernetes using KubeMQ


Challenges when moving From Monolith to Microservices

Many organizations are considering migrating from their current monolith architecture to a microservices architecture by breaking the service to microservices, containerize them (usually by Docker) and deploying them to Kubernetes. Naturally, a big segment is companies which the core technology is Windows-based and using .Net framework as the main development technology together with MSMQ for messaging and queueing services. These companies usually have their revenues generated from the current monolith technology, making the migration process a risky change for their business and revenues. Hence, these companies would look for failure points to avoid and ways to mitigate the risk for downtime during the migration process. Moreover, these companies are looking to continue to develop their apps by adding new features in the Kubernetes while keeping the old monolith available until migration completion.


MSMQ is a major hurdle for the migration process

MSMQ is a very popular message queue system in use among .NET framework services’ companies. When starting the migration journey to Kubernetes, the services are commonly being containerized by moving from old .NET framework to .NET core framework as .Net core is supported by Linux based containers. However, since MSMQ is a proprietary Windows server-based messaging solution that is not supported by Linux based containers, a big showstopper created to the company containerization process and migration into Kubernetes.


Safe and graduate migration from MSMQ based architecture to Kubernetes

KubeMQ is an enterprise-grade Kubernetes Message Queue and message broker that solves the MSMQ migration issue. It is designed to enable enterprise companies to gradually break their monolith system into small containerize microservices and migrate on the fly to Kubernetes, seamlessly and without service disruption. KubeMQ provides a .Net services bridge from Windows Servers running legacy MSMQ based services to KubeMQ (deployed in Kubernetes), allowing seamless bi-directional transposing messages between the services in the legacy monolith environment and the microservices-based deployment in Kubernetes environment. The bridge installed in the legacy environment is “listening” to the MSMQ on behalf of the relevant services in the Kubernetes environment, ensuring the designated messages are transferred from the monolith to Kubernetes and vice versa.


Demo for migrating MSMQ based app to Kubernetes



The following demo demonstrates how an enterprise company running a monolith financial software can gradually migrate their On-Premise windows and MSMQ service-based architecture into microservices containers running in Kubernetes on Azure cloud. In the demo, we break parts from the monolith and migrate them to AKS while both remain synced by using the KubeMQ bridge to MSMQ and the KubeMQ message queue. The demo is a financial application with the flow of real-time quotes (live currency exchange rates) reflected to end-users in a frontend web client.

Gradual migration of services from On-Prem to AKS


Adding KubeMQ and migrating services

Setup AKS, deploy KubeMQ and install KubeMQ bridge to MSMQ.

In Windows Azure, we have created a Kubernetes cluster using the AKS program. Afterward, we continued by deploying a KubeMQ cluster into the Kubernetes in one command line using the KubeMQ CLI tool (kubemqctl – link: https://github.com/kubemq.io/kubemqctl). In the On-Premise Windows environment, we have installed the KubeMQ bridge and connected it between  MSMQ  and KubeMQ. Both environments are now connected as described in the scheme below, messages can go from one env to the other, creating a perfect synchronization between them. We are now ready to migrate apps from the On-Premise environment to AKS.

KubeMQ bridge connects On-Prem and Kubernetes enviorments


Migrating services on the fly

In the next step we have containerized the API service in a Linux docker container using .NET core framework, the frontend was containerized as well, and both deployed to AKS and connected to KubeMQ. The services can communicate with each other in AKS as well as with the On-Prem windows services via the KubeMQ bridge to MSMQ. In this mode, both environments are working together as one environment and more and more services can be gradually migrated from the monolith to Kubernetes until migration completion.


A hybrid state of both environments connected by KubeMQ


The setup


You can view the MSMQ-KubeMQ interoperability demo and the code in GitHub.



  • Share:
Send a Message