Building a manageable microservices architecture with Cellery
This is not an architecture only post!. I’m going to convert a microservices project which is already implemented in the ballerina programming language to a cell-based architecture with Cellery. If you don’t know about “ballerina” and/or “Cellery”, you can refer the below websites that have enough information on those technologies.
Ballerina — https://ballerina.io/
Cellery — https://wso2-cellery.github.io/
Even though I have used above mentioned technologies for my implementation, you can use Cellery with most of the technologies. I have used the service composition ballerina guide and converted that to cell based architecture using Cellery. The original content of the service composition guide can be found here.
Ballerina Service Composition Guide — https://ballerina.io/learn/by-guide/service-composition/
You can read more about the advantages of Cell-Based-Architecture in a microservices world by reading the CBA specification here.
Service Composition In a Cell
Let’s take a look at the existing implementation of the service composition project.
As depicted in the above figure, there are 4 microservices altogether. Out of that, “Travel Agency Service” is accepting the requests from the client and calling 3 other microservices to produce the response. This is a typical service composition scenario.
As the first step of converting this sample into a CBA, I have built a single Cell that contains all the microservices within that cell and exposed the main service (travel service) to external users through the global gateway. In the Cellery world, it looks like below.
The implementation and the instructions to run the above cell can be found in the below GitHub repository. You can follow the README file to build the project and run it.
Service Composition Distributed Mode
The above mentioned approach makes sense if all the microservices are related. But in a real project, there can be many unrelated microservices running and they need to be converted into separate cells for better management. That is where the real power of the CBA comes into the picture with Cellery. Let’s see how we can split each microservice into separate cells and expose only “travel service” to the external clients while keeping other cells within the boundary.
As depicted in the above figure, each microservice has been moved into its own cell while exposing only the “travel” service through the global API gateway. The implementation and the instructions on how to build the above architecture can be found in the below GitHub repository.
That’s all for the moment. I’m hoping to build more and more Cellery projects and you can find those projects in the GitHub repository mentioned above. Give your feedback on possible projects if you have any.
