Microservice Architecture: Localizing core logic in a separate code base

Question

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.

1. It receives RESTful requests and process them accordingly
2. 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:

1. A common project that contains all Service and Repository level logic, in addition to domain objects.
2. A web project that references common to handle REST traffic
3. 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).

Answer 1

I can't presume to know enough about what you are dealing with, specifically. However, in software development there are trade-offs, and those trade-offs have to be considered with the benefits and risks associated with the choice. So I would recommend going to your meeting with an open mind, so you can understand what the end goal is. I have a feeling that the change is still in process.

Can there be a benefit to splitting data processing and web processing?

Sure. This really wasn't your question, since you weren't opposed to the split, but the way it was done.

Where should the boundary lines be drawn?

This question, and the fact it used to be one application a few days ago (per your comment), leads me to believe that this hasn't really been answered yet. In other words you have a work in progress.

In general:

• Unit and Integration Tests should be executed as closely to the code under test as possible. It's better to catch it before you push your changes than to watch multiple projects go red because of an avoidable mistake.
• Keep things as simple as possible.
• Simplify after that.

Since this is a work in progress, there will be pieces that are in the Common library now that should be moved elsewhere. It doesn't mean that this is necessarily the wrong approach, but that there is still more work to be done.

Why the separate repositories?

There can be legitimate reasons, and those reasons are mostly business related. Deciding when to create a separate repository vs. a single repository with 3 projects is never as cut and dry as you (or I) want. Correct me if I'm wrong, but this seems to be the core of your heartburn.

What you lose

By going to separate repositories you lose:

• Cohesive versioning of the three projects (maven modules)
• Having all the source code needed for a product in one place
• Having all the tests needed for the product in one place
• Understanding the core dependencies

What you gain

By going to separate repositories you gain:

• Looser versioning so that one product only depends on one version of common.
• Ability to release updates to batch processing without affecting the perfectly functioning web API (and vice-versa)
• Discovering integration headaches if common is intended to be shared beyond just the two services.

I think maven/gradle do a better job of dependency resolution after you split projects into repositories than Nuget (C#). That's a technology related reason though (Direct project references help develop new features cohesively, but the generated nuget package might not have the right dependencies declared).

There will be headaches

While I personally would have started with one repository and 3 projects (i.e. the maven modules) like you suggested, that would be for the initial work.

Separating logic that was once in one project is always a tricky thing no matter how carefully you crafted it. In well crafted systems, 90% of the work is easy, but the remainder has to do with finding all the little ways your app broke because the code no longer complies with the assumptions under which it was developed.

There's two philosophies with making changes like this:

• Rip the band-aid off and deal with the mess.
• Slowly peel back the band-aid a little at a time.

Sounds like your team opted for the first approach.

Answer 2

I'm wary of your objections. Usually because I'm the one adding projects, separating stuff out into components adding build servers and octopus deployment etc and getting moaned at for 'making things hard to debug!'

Lets take your objections at face value though and assume that, yes its a very weird setup that adds a whole bunch of annoying admin tasks to the developers daily routine for no benefit.

I'm pretty sure we have all been there to one extent or another. for example I have to raise annoying tickets atm for other teams to change firewalls or install updates etc which is a pain for a pretty minor organisational benefit.

Sometimes you are even forced to write unit tests!! RIDICULOUS!!! MY CODE IS PERFECT!!

Developer Experience is a thing. If things are easy then development goes fast, if you have to wade through annoying procedure things slow down. It gets boring.

But the cool thing about being able to code is you can automate stuff. (Or download automations other people have written and install them). So I would roll with it, make templates for your tickets, automate your annoying build processes, hire testers to write the stupid tests and answer stack overflow questions when you are compiling.