I was looking for a book on Microservices Architecture. There are several books, but I need one which explains all the patterns and related styles on design. The reason being is, I'm convinced about Microservices, but I need to convince my fellow teams and managers.

Microservices is mainly for large scaling or team separation.

Unless you have 40+ devs or hundreds if thousands or millions of visitors you probably do not need it.

But it can be useful to break out parts of the solution if its something that is quite separate from the rest or is reused from different applications.

Like a logging solution or transactional email if you do mot use an external partner.

Microservices is an abstraction that helps different teams to work in their own pace but it also might result in having to maintain multiple versions which for a small team can cost a lot more resources.

And it can actually slow down overall development.

Once you start having a dozen teams of 5-10 deva each, microservices can be a very good way to avoid massive synchronization problems in the project as as long the interfaces are fixed, different parts can release almost without concern for others.

Also, by this time you will probably benefit from having multiple versions as others teams might not be ready to upgrade and would stall the first adopters if they have to wait until all are ready.

@Voxera this!

@Voxera you mean to say, using Microservices is not necessary for a project which might not have million of request daily? I understand the when you say different teams will work on different services.

@sunnyDeveloper ypu can use different teams for different parts without microservice.

Ms decouples parts so its almost as separate products and for most projects such big separation will cost more time.

Its when you either need to run the different parts on different clusters for performance or have problems where deployment is delayed waiting for some teams to sync with others causing them to be idle you will get a real benefit of the separation.

Separating a few not so integrated parts is no problem but ms often goes much further than that separating on every major object scope. Users as one, customers as one, orders as one, products as one.

And if you are in a position where you need arguments for ms, you probably do not need it.