Claudio Guidi

Thank you for this article. In general, I think that the big challenges in breaking a monolith are not only technical but mainly organizational. What do you think?

Hi Danny, thank you for this reply. I think that the topic is very important to be addressed because, as you said, it allows for reducing the complexity of a microservice architecture. I just have a look to your platform and it seems very nice. With Jolie we decided to follow another approach that is the linguistic one, that allows for programming following a new paradigm. Thanks to this, in Jolie embedding is trivial. On the other hand a new progtramming language is more difficult to be adopted, in particular when it changes the usual practices. Nevrethless, I think that we need a new generation of programming languages just because the traditional programming paradigms are no more sufficient to grasp the complexity of distributed applications.

I think that data services have been introduced in order to decouple business services to the raw data of the persistence level. It is true that data services provide CRUD operations that could appear not useful because, as you said, you could just use the data from the persistence level, but at the same time they provide a first abstraction of the raw data just offering to consumers only the relevant information and not everything. Moreover the consumers are not bound to any specific technology of the persistence layer, but they are just coupled with a service based technology (e.g. REST) In this way, you are more independent from the technology used in the persistence layer.

I think that the weak point of data services, is that it is very difficult to design operations that work well with all the possible consumers, so you need to manage them frequently.

Data gateways seem to offer a solution to this point but my doubt is that it just move the problem from a technology stack to another (so in this case I get your point when you said "Your suggestion is to double down on an already bad idea and
gather/aggregate data through additional infrastructure").

Anyway, interesting article for me.
Many thanks to Jeffrey.

Hi D L, and thank you for your feedback. In the following my answers:

a) Generally speaking there could be scenarios where there are more microservices on the same dataset. As an example you could need to separate API into different microservices for business reasons. In the article I provided the example of huge product catalogue which contains a lot of different products. Let us suppose to be in a B2B scenario where we have a customer that asks to have a special set of refined APIs just for a subset of this catalogue, and you want to manage them separately. In that case you could have another microservice that uses the same dataset. Another example could be the case where you want to differentiate writing APIs from reading APIs.

b) The microservice data layer offers an abstraction of the underlying data layer, in order to abstract away from the technicalities of the specific technology. It is not mandatory, in the sense that it is not the "right way" and, dually, it is not the "bad way". It is just a normalized reference for dealing with different scenarios, then it is up to the architect/developer to choose the solution that best fits its needs. In any case, there is not any relationship between the team that manages the microservice data layer and the teams that manage the microservices at the functional layer. They are separate microservices. The microservice at the microservice data layer is just a dependency of those at the functional layer. This is a general approach that enables the reuse of the microservice data layer. If reuse is not necessary, the microservice data layer is not necessary but both functional and data layers can be compressed into one single microservice.