Readers question about cutting services

Last Update: 05.07.2018. By Jens in Developers Life | Learning | Newsletter

Reader Onno wrote in with some questions I’d like to discuss on the list (with permission of course).

Onno askes:

In my team we want to apply microservices. We have some services which connect external and internal systems via a Kafka message broker. We have services with different functionalities (e.g. consume form kafka and export data to AWS S3 and receive info over rest endpoints and publish to kafka), and these are deployed as 1 application.

Now I am investigating moving to cloud stream, in where it makes sense to break down a service in smaller components. So in the end you will get a jar for the receiving part and 1 for the sending part. Could I consider these as separate applications, and should these have separate repositories + CI/CD pipelines. Or would it make sense to create a multi modular maven app which produces multiple jars?

Good questions. With some compromises ahead.

So, if I understand it correctly, the functionality is split into several services, each of them doing something tech related and all is shipped as a single application. Now he wants to split sending and receiving code into modules and was thinking of deploying the standalone.

Let’s start with the single application deployment. This can work if you mitigate the risk of a single point of failure like with running multiple instances. Splitting those up into multiple applications can be beneficial, but comes with all the cost of operating multiple applications.

I’d check how the services are actually cut. Do we have one with the tech purpose of exporting data to S3, no matter the domain of the data involved? Or is it split by domain? Also, what would happen if this service fails, from a business perspective? Does the whole system stops working because the message services are down? Besides domains, can some functionality just fail without affecting much like does it have any immediate effect when an S3 export fails? Can we even group the functionality by domain and effect of failures?

So, yes, I’d split the single deployable app into multiple. How depends on the answers found to the questions above. But I’d not try to deploy the sending and receiving part of a service as standalone apps. Yes, they are modules, but not apps. The apps are cut by your answers and they will use the individuals sending and receiving modules. Because in most cases, a function will consist of receiving and sending anyways.

Now to the everlasting single repo vs multiple repo discussion. Both have their advantages and disadvantages. If the services are really standalone and do not share modules aka his senders and receivers, a repo per service is fine and easier to digest. However, if they share parts, I’d go with a multi maven project in a single repo, just makes life easier in this case.

As a side note, it depends on the dev’s brains and experience too. If the average dev on the team gets overwhelmed with doing work spanning over 3 repos, it will hurt teams output and more.

Want content like this in your inbox each workday irregularly? No BS, spam or tricks... just useful content:

I understand and agree to the privacy policy