Почему 90% проектов на микросервисах обречены на провал (и что с этим делать)
Почему 90% проектов на микросервисах обречены на провал (и что с этим делать)
1313

Микросервисная архитектура - это в первую очередь история про распределенные транзакции, идемпотентность. Если вы решили изолировать часть логики в отдельном приложении и обращаетесь к нему через апи - это не микросервис, а просто источнмк данных, такой же как субд, например. Почему то субд, эластик, редис не называют микросервисами.

Да и общение между микросервисами должно происходить через брокер сообщений. А если вы лезете в микросервис через апи - это херня собачья, а не микросервис.

А теперь подумайте, зачем вам весь этот головняк с настройкой коммуникации, брокерами, сагами, рассинхроном апи, когда в вашей системе работает 3 калеки, в лучшем случае.

Вообще лучше сделать монолит, в котором из коробки будет подарок в виде транзакции субд, а на сэкономленные деньги лучше заказать сервер помощнее.

3

А как же gRPC?

1

Расскажите, пожалуйста, поподробнее. Мне стало интересно. Звучит логично. Ведь чаще всего люди действительно считают что инкапсулируем щас по смыслу одну логику от другой и будем по апи ходить - это типо микросервис. Было бы интересно услышать более детально вашу точку зрения. Я фронт в большей части но попробую понять ваше представление.