Microservices architecture (MSA) is more than a buzzword. It is real and it is here to stay for a long time. As long as you talk about MSA, you talk about the “monolith” as well. But where is “Service Oriented Architecture (SOA)”?

                                                                               Path to MSA.

If you observe the about graphics, you can see that people talk about the approach of moving from monolith to MSA while the ground reality is something else which is moving from SOA to MSA. You can find enough resources which talk about how to move from monolithic architecture to MSA. This link is a resource available on DZone, DZone's Microservices Guide.

Even though it is a good approach to highlight the advantages of MSA at a conceptual level, in a practical sense it is not the most common approach. If you are an organization which had lived up with the IT evolution, you should have moved away from monolith to SOA at some level.

If you are coming from such an SOA background, you may be wondering whether you really need to move into MSA. What happens to all the effort you have put into designing the complex SOA model which has worked flawlessly in the past. OTOH, you know that MSA is the future and it is well aligned with the modern system requirements like

• High availability
• Scalability
• Cloud native
• Efficient resource usage

Now you may be in a kind no-mans land thinking about what to do. Let’s step back a bit and look at what brought us here. In SOA, you have services defined with precise interfaces so that anyone can find and use your service. WS-Security was there to secure your services in all sorts of different mechanisms. It can be a single functionality or a set of functionality. Most of the people start explaining the advantages of MSA by mentioning doing one thing right. But this concept is not something new. It was there in the SOA world as well. If the counter-argument against SOA is that these services cover a wider scope than a microservice, try to implement a real-world MS and see where you end up.

According to my understanding, it is not the scope of a single service the limitation of SOA, rather the way we have deployed it. If we look at the approaches we took to deploy these services, we can identify there are 2 types of web containers heavily used (especially in the Java world).

• Tomcat for back-end core services
• ESB for middleware services

If you have built any complex SOA system in the past, you should have used either one or both of the technologies mentioned above. If you haven’t deployed an ESB you should have at least written the functionality with some in-house implementation.

Let’s talk about how you can move from SOA to MSA with

• Minimum effort
• Minimum risk

Those two characteristics are quite important when going through a transformation. For the backend service implementation which is hosted in Tomcat, you can easily move to an existing Java microsevices framework which supports JAX-RS type implementation (e.g. Spring Boot, WSO2 MSF4J, DropWizard). By doing that, you can reuse most of your Java code and move into an MSA world without much effort and risk. This is the place where most people start their MSA journey and the world has seen enough examples of successfully going down that path.

But, what will happen to your existing ESB implementations? Are you going to rewrite everything or dropping the ESB assuming that MSA will solve every problem? We have seen many examples that, neither of those approaches are going to work (at least for the moment) in the real world. In a previous section, we discussed the real limitation of SOA as the deployment approach. How can we move to an MSA type of implementation with minimum effort and minimum risk?

WSO2 has come up with a more modern, microservices friendly ESB runtime called a WSO2 Micro Integrator (WSO2 MI) which will serve this purpose in a more pragmatic approach. With this new runtime, you can reuse 95% of your existing ESB (or EI) implementations as it is while deploying them in a microservices friendly manner. WSO2 MI is a lightweight runtime built using the same technology which was used for high performing WSO2 ESB (EI). Here are the key MSA friendly features of the WSO2 MI

• Quick startup (<5s)
• Stateless
• Immutable
• Low memory footprint

With this new runtime, your existing SOA model which was using the WSO2 ESB (EI) can be migrated into a MSA with less effort and less risk. When you are moving from SOA to MSA with WSO2 MI, you can follow the strangler pattern where you start moving the implementations in a phased out manner similar to the picture shown below.

When migrating from the existing WSO2 ESB(EI) to the newer WSO2 MI, there are some measurements users need to take. Here are some of the features which are missing in the WSO2 MI which was there in the WSO2 ESB (EI)

• Hazlecast based clustering
• Co-ordination
• Database based registry
• Deployment synchronization

Most of the aforementioned features used rarely and if you have used one or all of them, you can find alternative approaches. Some examples are

• Clustering can be replaced with container orchestration framework like Kubernetes
• Database based registry is replaced with a file system based registry in WSO2 MI
• Deployment synchronization is not required since WSO2 MI instances are meant to be deployed in an immutable manner
• Co-ordination — not replaceable. The implementation needs to be changed.

The final architecture diagram of your SOA to MSA shift looks like below.

You can find more information about the WSO2 Micro Integrator by visiting the documentation page.

The next important step in moving to MSA is the automated deployment with CI/CD process in place. The below picture explains the process of implementing a CI/CD process for WSO2 MI development.