544525 (3) [Avatar] Offline
#1
I am currently in the process of digesting the book "Microservices patterns". It introduces me in how to handle this distributed transactionality using the logical concept of sagas as a set of events that occur in the different managed machines as if they were a distributed state machine so that only the next state is advanced when the ACID transaction is resolved locally. and the next event has been inserted in the message broker, only then, the central orchestrator decides the next state or the choreographer. Personally I understand better the figure of the orchestrator than the choreographer, but I think I still have to finish the book, then reread it and then play programming the different components that can appear in a distributed architecture oriented to microservices. It is much more complicated than simply designing different REST components with spring boot, dokerize them and put them behind kubernetes or Marathon / DCOS to climb naturally. An example that has me worried, imagine that you have 3 containers of the same service, with the same logic and each one with an identical local database, the proxy assigns you one of the 3 containers to work, you make the local transaction and the Orchestrator decides the next step, choose another container that contains the following business logic and update the local acid transaction and so on until you arrive at a transaction in a Cn container that fails. What happens here, that you have to rollback in all the previous transactions that have occurred in the different containers, something that is already complex, but imagine that all the transactions have gone well and you have all those containers with those bd coherent with each other, but you have the other instances of the same identical services scaled inconsistent in data with respect to the previous example. What are we doing here? I imagine that it would be necessary for the orchestrator to send the same sequence of commands to the different scaled services so that when the proxy chooses one of these to act, it has the same options of acting correctly because it would have the same data replicated without inconsistencies. I wonder if all distributed transactionality problems are contemplated using Tram and if I should stop worrying about this. Thanks Chris.
ceracm (105) [Avatar] Offline
#2
It is important to distinguish between services (logical, design time) and service instances (runtime processes/containers).

Each service has its own database.

All instance of a service share the same database.
544525 (3) [Avatar] Offline
#3
Okay, that's understandable, so you are proposing to use the paradigm of multiple docker images that attack the same relational or non-relational database. Would not that be a problem if the sql or nosql database manager goes down? That is, I see that we can scale multiple containers that contain the logic of each microservice and that you propose that each container have its own username / password to attack said database, but would it not be better if each container that contains each microservice? would you use your own bd and that there would be a mechanism that would allow you to be synchronized with each other so that when the proxy selects a microservice to act, it would be coherent with respect to the rest?

To see if I clarify, we can have 5 containers for example with the same microservice, each container is connected to the same scheme sql or nosql that uses that microservice with its username / password, which implies that I would need another microservice that would provide me with a file with properties with this information and then we should have other containers that contain the logic of another microservice with their common tables among these scaled microservices, all of them coexisting under the same database manager, is it correct?

Another question, in case you decide to implement the strategy of a choreographed saga with a central class that manages the state machine with the steps to follow between the different containers that contain the logic of the different microservices, it is a good idea to have these classes Climbing saga, is it a good idea to have multiple instances? Thank you for assisting me.