Hi team,
We have a plan to build microservice solution.
We want to implement Jmix application as microservice.
Please let us to know: following our idea is possible to implement?
Hi,
If you seek for advice, then I would suggest that against implementing your own “Authentication and Authorization service” on Jmix. It isn’t the best idea.
There are full-featured and free authorization services on the market. For example, RedHat KeyCloak SSO https://www.keycloak.org/ . It would be a waste of time to implement your own solution with similar functions using Jmix.
From the other side, Jmix application can be easily integrated to use KeyCloak through OIDC protocol as an authentication service, source of users and assigned roles. We have a sample project for KeyCloak integration: https://github.com/jmix-projects/sample-sales-jmix/tree/security-advanced-keycloak-complete
4 Likes
Thank you very much for excellent helpful.
We will try as your advice!
Hi @ntha79 ,
generally speaking, Jmix as the framework is more or less suitable to build a microservice, similar to a lot of other technologies.
In order to tell you if it is a good idea or not, it highly depends on your particular context.
Let me ask you a couple of questions to get a better picture of what you are actually trying to achieve:
- Why do you need a couple of microservices at all?
- What problems do you currently in your organization have where microservices provide a solution for?
- What is the reason to roll out a single technology (even a framework) across multiple teams? Normally team autonomy is one central reason to adopt microservices. Having a central decision on technology across the teams is directly contradicting that idea.
Then there are a couple of technical questions that I have based from your drawings:
- From your drawings, I see you do not want to use Vaadin as the UI layer, so this means you would want to use Jmix just as a headless Spring boot service, right?
- With gRPC you want to communicate in a synchronous manner between the services. Why do you need synchronous communication between services?
- Should multiple microservices have access to a central DB? The image indicates this.
Perhaps you can answer a couple of those, then it might be easier to go into more specifics.
Cheers
Mario
1 Like
Hi David,
Main reason why we want implement microservices: its long history.
We have an e-commercial solution for our client, currently we have build in Cuba Framework a monolithic application.
In this application, we have many modules to resold separate issues:
- Product Management
- Sale Management
- Promotion Management
- Purchase Management
- Payment Management
- Stock Management
- CRM
- Shipment Management
- Financial Management
- Report Management
- Integrate 3-party Management
Client business is change every day, and we must update our source code many time. One module update we need update all application.
And day by day, our source code become as spaghetti , very difficult to manage.
We have plan to implement microservices to rebuild our application.
We want to separate each module can run independency from each other. Each module communicate to other if need.
Now, let me answer your question
Why do you need a couple of microservices at all?
as i explain above
What problems do you currently in your organization have where microservices provide a solution for?
as i explain above
What is the reason to roll out a single technology (even a framework) across multiple teams? Normally team autonomy is one central reason to adopt microservices. Having a central decision on technology across the teams is directly contradicting that idea.
Technology in microservice is not our main problem.
Advantage from microservices for us :
+Separate modules can run independency from each other.
+Each module communicate to other if need.
+Maintain what we need
We want implement spring boot as the main technology in our solution, because our member team all most from Java base.
Of cause other technology like NodeJS, #Net to build some microservice to welcome.
From your drawings, I see you do not want to use Vaadin as the UI layer,so this means you would want to use Jmix just as a headless Spring boot service, right?
Yes, we are not use Vaadin as the UI layer. We have build separate front end application for Web and Mobile(Reactjs and React Native). Jmix microservice here is playing as Rest API only. Why we want implement Jmix as Microservice:
+We have working with Hibernate and Spring JPA, but we fall in love with Jmix Entity manage, such as flexible fetch plan(View),entity event listener… Trust and stable manage entity with tables in database.
+Security ABAC base policy is flexible. Its not simple if we build from scratch by our self.
+Rest API stable and simple with all advantage Entity Manage and Security ABAC. We can partial update without any issues. In almost case, we don’t need create DTO for Rest API.
+…
With gRPC you want to communicate in a synchronous manner between the services. Why do you need synchronous communication between services?
In our drawings, i have cut some things for simple explain what we require from Jmix, but real we have two communication method between microservice
+first method: Event base - we use Saga pattern with Kafka.
we use this method for helping us implement complex flow.
For example: Client Order flow: Client create order => start Stock flow => start Payment flow=> start Shipment Flow =>…
+second method: synchronous - we use gRPC
This method help us some simple request and get immediately result before decision what next step.
For example: get Balance product in stock, check payment status from other modules.
Should multiple microservices have access to a central DB? The image indicates this.
In our solution, each main microservice have owner DB. Some microservice no need DB.
with best regard!
2 Likes
So you mean that you have to re-deploy the whole application? Does this mean that you have High availability requirements, which makes that a problem? I think downtime can be avoided via various mechanisms either with microservices but also with monolithic applications.
I think this is a common misconception on why to do microservices. As you mentioned, from your perception the source code of the existing software is “spaghetti”.
If this is the case in your current application, how do you think your solution will look like when doing microservices? Microservices do have a forcing function in this respect since it is a little more effort when implementing it to make a call to another microservice - so this might help. But once you find out how to efficiently create a remote connection (from a dev effort perspective), you will start making calls all over the place.
This then leads to a distributed monolith that is orders of magnitude harder to maintain. The key here is to achieve what is called in domain-driven design terms a good & stable context map of bounded contexts.
But this you can also achieve in your monolithic application. You can leverage the isolation capabilities of your programming language like Gradle modules, Java Interfaces, or package visibility. In Jmix you can use multiple add-ons/modules that encapsulate your described areas of functionality like promotion management, CRM, etc.
The reason why it is way easier to come to stable isolation between modules is that in a monolithic application it is way easier to refactor towards that. If on the other side you find yourself in a distributed monolith it is very expensive to refactor the cut of the business functionality in different microservices.
Proposal:
Imagining from what you described I would suggest separating the problem that you are trying to solve into two:
- decompose the monolith
- leverage benefits of deployment autonomy
In step one, you try to architect your existing solution into different building blocks only by using modules (in the case of Jmix it will be different addons for different functionalities). This will give you a well-defined component dependency graph. At this point, you can still decide to put them into one wrapper Jmix application. I once wrote an article about that first step for CUBA, but it is similarly applicable for Jmix: Decompose the monolith with CUBA application components – Road to CUBA and beyond....
In the second step, you switch from one Jmix wrapper application to multiple. By doing so you explicitly introduce distributed computing with all its inherit complexity like eventual consistency, latency, distributed transactions (
), fault-tolerance, contract testing, cross-referencing CI/CD pipelines, etc.
It does require writing a communication layer when introducing this second step, but at least you have a chance to not accidentally introduce microservices without having an actual need for it.
Martin Fowler told once when speaking about MS early on back in 2014: You have to be this tall to do microservices (speaking about your CI/CD & automation capabilities). I cannot judge if you / your team is “this” tall, but I just want to emphasize that introducing Microservices should be done for very good reasons since it comes with very high mid- / long term costs.
In particular, if you are planning to run this complex set of technologies not directly in your own organization with the personnel that has potentially dedicated understanding of the bits & pieces, but instead even run this within a client organization. Then it might get even more complicated, but I’m just guessing here…
The long-term benefits of microservices can outweigh those costs if you need to go fast in the long run in large organizations with tens of teams and a lot of communication overhead that is there otherwise.
I hope I did not discourage you from your plans. And you also have to remember that I almost have no context about your situation, so the guidance that I provided here can only be very speculative and shallow.
Cheers
Mario
6 Likes