I would be very careful about taking the microservices approach; I had a bad experience with these years ago due to the over-use of them.
A client hired a system architect consultant in addition to our company to develop a new system for them, even though we had delivered some very successful and stable systems to them before with similar requirements which could be classified as monolithic MVC apps.
Rather than take the same approach to the architecture the consultant had his mind fixated on microservices and that they were the solution to everything - that every part of the system had to be a microservice, even though only one thing in this new system needed to be shared with others.
As such this meant that in order to do anything, in order to CRUD on any screen, the app had to talk with multiple web APIs for all these microservices.
Of course the round-trip process of creating, sending a web request, then receiving and decoding a request in the service, doing a DB lookup, creating XML response and then sending it back to the app for it to decode and use meant the whole system was very slow and clunky.
Also reporting became almost impossible because a number of tables which needed to be joined in SQL queries ended up in different microservices and there is no way we were allowed to directly query the DB of another microservice - all were strict silos/self contained things. I left that company and the project years before it was finished so would love to know how they solved that one.
One of the dumbest things was that all these microservices actually ran on the same server so there was no benefit at all over a single MVC web app especially given the number of users was not likely to rise so scaling was not going to become a problem.
Finally the project took years longer than needed - I heard from one of the devs I worked with at that time when exactly it did go live and was quite astounded, I am sure we could have completed it during my time there if it had not been broken in to all these little pieces and completely over engineered.
I would very carefully consider if microservices are needed and if so use them sparingly. Perhaps a monolithic with an API attached to the side is all that is needed instead.
When I hear "Microservices" I can't help but think "Warning warning - Will Robinson"
I would be very careful about taking the microservices approach; I had a bad experience with these years ago due to the over-use of them.
A client hired a system architect consultant in addition to our company to develop a new system for them, even though we had delivered some very successful and stable systems to them before with similar requirements which could be classified as monolithic MVC apps.
Rather than take the same approach to the architecture the consultant had his mind fixated on microservices and that they were the solution to everything - that every part of the system had to be a microservice, even though only one thing in this new system needed to be shared with others.
As such this meant that in order to do anything, in order to CRUD on any screen, the app had to talk with multiple web APIs for all these microservices.
Of course the round-trip process of creating, sending a web request, then receiving and decoding a request in the service, doing a DB lookup, creating XML response and then sending it back to the app for it to decode and use meant the whole system was very slow and clunky.
Also reporting became almost impossible because a number of tables which needed to be joined in SQL queries ended up in different microservices and there is no way we were allowed to directly query the DB of another microservice - all were strict silos/self contained things. I left that company and the project years before it was finished so would love to know how they solved that one.
One of the dumbest things was that all these microservices actually ran on the same server so there was no benefit at all over a single MVC web app especially given the number of users was not likely to rise so scaling was not going to become a problem.
Finally the project took years longer than needed - I heard from one of the devs I worked with at that time when exactly it did go live and was quite astounded, I am sure we could have completed it during my time there if it had not been broken in to all these little pieces and completely over engineered.
I would very carefully consider if microservices are needed and if so use them sparingly. Perhaps a monolithic with an API attached to the side is all that is needed instead.
When I hear "Microservices" I can't help but think "Warning warning - Will Robinson"
Well thought answer
Now I really understand when to use microservices