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
Motivation
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.
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.
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.
You can view the MSMQ-KubeMQ interoperability demo and the code in GitHub.