I've a cenario with multiples applications, each of them taking care of their own data. But as the business is coupled, we need to access each others application's data.

We basically have a database dependency strategy, sharing entities with some applications or mapping views in others. It's created a dependency hell!

  1. How can microservices help us in such cenario?

  2. How is accessing multiples url's a better strategy than using database JOINs? (ex EntityA has a mapping dependency with EntityB. If I use a microservice strategy, I would have to call /apirest/resourceA and /apirest/restourceA/resourceB, right? How would this be better/faster than having a select * from entityA inner join entityB?)

  3. How can I decouple the data betweeen all the applications (it's like, 10 applications that, at some point, access the same data)?

  4. Any material/articles/tecnologies indication?

1 Answers

cmoetzing On
  1. Microservices define a clear boundary. They will not miraculously make everything faster.
  2. Database joins are viable solutions too. If you have very strong coupling between your data microservices might not be the right option. Microservices allow your different services to use technology indepent from the rest. Say you have services A and B. You could use a relational database in service A for data that is strongly coupled and needs transactional security and a graph database in service B to manage relational data. Services A and B do not care what the other side is using since it is hidden behind the service boundary.
  3. If you can divide your data into domains with minimal interaction these domain boundaries are a good starting point for your services. Services will eventually have to reference entities of another service. Two possible options are either always calling the other service or keeping a minimal local copy of the remote data (only the primary key of the remote entity for example). The local copy needs to be kept up to data of course ( with events?). At the moment we are struggeling with exactly this point...
  4. If you google microservices you will drown in information. I like https://martinfowler.com/articles/microservices.html as a starting point.

I am sure I did not touch all aspects of microservices here, this is just meant to be a short hint in a direction to start your journey...