0

We are doing an architectural refactoring to convert a monolithic J2EE EJB application to Spring services. In order to do that I'm creating services by breaking the application against the joints of its domain. Currently, I have three of them and each calls another service via Rest.

Our domain contains User, Customer, Alarm, Notification, Market and other modules. So, for example a user send a request from a GUI to a service which does its logic and then calls another service:

UserService ---REST--> CustomerService ---REST--> AlarmService

Does our approach that creating services that calls each other with REST make sense in context of transitioning from EJB to microservices as a step?


Our current infrastructure which consists of some Wildfly EJB containers running on multiple VM's doesn't handle more concurrent connections. We wanted that if we could separate them as services, for example in the busy times with a help of some kind of orchestration maybe we can increase the number of VMs and deploy different services to different VMs and ultimately maybe later, since we have separated them, we can transform to microservices easier than before. In this way we thought that maybe we can trade network latency for more concurrent users gain.

In this project our ultimate purpose is transforming the application to microservices, but since cloud infrastructure isn't clear and probably won't be possible, we decided to make it this way and thought that since services will be using Rest, it will be easy to make the transform to microservices when the infrastructure supplied in future.

I'm asking this, because in this current form I have some problems like passing common request parameters across REST calls but a few people on the web talk about this. So I thought that maybe we are on the wrong path since it's not popular among people that services calling each other with REST calls. Also, for example every service need to use a few common CustomerService methods. So I thought that maybe we can put CustomerServiceImpl bean in a common module also so that services can Autowire it for these common methods but at the same time can send Rest requests for other methods. My collegue says that it's not suitable for microservices architecture.

  • Are those services on separate machines/VPSs? Do they share one database or does each one have its respective database? – Milan Velebit Mar 21 at 12:29
  • @Milan Velebit, I have heard that in a microservices architecture people suggest that each microservice should use its own database, but currently we have one database and services share it. In this context we are researching how we can create multiple databases but not sure how to do that since tables have relations to other tables. Also services aren't live so i can test them on localhost by giving each of them different ports or putting to other machines and starting as services on different machines we have. So they can reside on both. – Taha Yavuz Bodur Mar 21 at 12:39
  • What kind of problems do you have? – Laiv Mar 21 at 12:45
  • @Laiv, Thanks, I have edited my question to add problems which lead me confusion. – Taha Yavuz Bodur Mar 21 at 12:53
  • @TahaYavuzBodur would you main to edit the question in such a way it doesn't look like a changelog? :-). Rearrange the question in sections like context, actual situation, desirable situation, problems, doubts . Right now is a little bit hard to read and get what you want to get from us. – Laiv Mar 21 at 14:30
2

Why are you doing this? There is no objective way to determine whether what you're doing makes sense, it always has to be measured by what business value it delivers.

For example if you have no clear goals, then no, it doesn't make sense, regardless what you do.

Often the reason to do this transition is because the monolith becomes "unmaintainable". It has too many internal dependencies, circular dependencies, and it just takes too much work for even little changes.

In this case, your approach doesn't seem to help. By keeping essentially the same structure as before, and additionally introducing a network between existing modules seem to make things even more difficult.

If your goal is maintainability, it is best to try to separate into functionally closed services. These are services that don't need communication with others to fulfill their logic. Here are some more information on how that would work: https://scs-architecture.org/. This would however require much more work, and would probably not align with existing "modules".

  • Our infrastructure which consists of some Wildfly EJB containers running on multiple VM's doesn't handle more concurrent connections. So we thought that we need a transition to microservices, but because of some costs, it's not possible to setup a cloud environment currently. We wanted that if we could separate them as services, for example in the busy times with a help of some kind of orchestration maybe we can increase the number of VMs and deploy different services to different VMs and ultimately maybe later, since we have seperated them we can transform to microservices easier than before. – Taha Yavuz Bodur Mar 21 at 13:11
0

You've already strayed away from an ideal microservice architecture, breaking some of the initial rules like having a separate database per service, having too-tightly coupled code..

Also, REST is not a good way to achieve communication between different services, mainly because you'd have to figure out a way to achieve solid locational transparency.

TLDR; You're gonna have a hard time breaking up your database and fully automizing services. Read more about microservices approaches before opting out for restructuring your whole application. Having REST as a communication layer between services will just worsen your call latency, and in this case, I don't see how it aids your foundation for microservices.

  • what way of communication other than REST would you recommend for service interaction? – Frank Hopkins Mar 22 at 10:15
  • If you're doing 'direct' communication rather than having a push/pull proxy mechanism between services, I'd surely opt for gRPC rather than REST. – Milan Velebit Mar 22 at 10:25
  • I'd add that into the answer. And I'd agree that yes it would be a bit faster, but if OP already has REST based stuff in place, it might still be a reasonable approach to stick with it for now and change the internal component should latency become an issue, i.e. I wouldn't consider it a deal-breaker in trying to shift stuff over - depending on what the actual load and requirements are. What I don't see is how grpc solves the problem of solid locational transparency better. – Frank Hopkins Mar 22 at 10:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.