I stepped away from a project for a few weeks. Before leaving the organization was discussing an architectural pattern for our microservices. An instance typically serves two roles in our organization.
- It receives RESTful requests and process them accordingly
- It works as a batch processor, reading in large volumes of data and processing them.
Going forward we will probably want to separate batch processing from REST handling. The question of how best to separate these concerns was being discussed. One proposal we had was to configure our build deployment process so that an instance could either be deployed in web mode or data loading mode. I liked this approach in particular because load balancing would be facilitated with this approach as we could ramp up or ramp down the number of instances based on the amount of work out there for a context-specific task.
However, upon my return I found that a different paradigm was settled on: they want to create two additional source code repositories for a total of 3 projects:
- A common project that contains all Service and Repository level logic, in addition to domain objects.
- A web project that references common to handle REST traffic
- A dataloader project that references common to handle data-intensive tasks
I'm really not a fan of this approach. For one thing, all of our integration tests are now in the web project and are really testing logic in #1 (we can do an overhaul of our testing to favor integration/unit testing at the common level, but that will take time and sweat). The debugging/development cycle is really inconvenient as errors discovered in 2 or 3 require going back to 1 to make changes, updating the maven dependency, and returning to testing. Working with these included dependencies is really a pain in general.
It's workable, but more time-consuming. It really has me thinking about the concept of the developer experience. I don't think it gets talked about but I think it is just as important as the user experience. Especially since this is a project that has an aggressive development cycle. Development on the branch where this is implemented is truly cumbersome and... annoying!
Management's reasons for favoring this approach don't seem to fit the inconvenience either. Some arguments I have heard is that the codebase will be too large without this separation. I am also hearing that they may want to deploy one version of the common library for data and a different one for web (I simply can't imagine a valid use case for this request).
I am wondering if anyone else has exposure to this architectural style which, to me, seems like an anti-pattern. Am I prejudiced against a valid approach? I am going to meet with management soon to recommend returning to a single code base but organizing it as a multi-module project (3 build files, deployable based on context).