Отсекая лишнее: плюсы и минусы использования микросервисов в веб-архитектуре
Микросервисы стали главным направлением в архитектуре веб-приложений и завоевали сердца многих известных экспертов и сторонников. Ведущие компании, такие как Facebook (проект Meta Platforms Inc., деятельность которой в России запрещена), Uber, OZON, VK, Amazon, Netflix, eBay и “Детский мир” с успехом применяют архитектуру микросервисов.
Как раз с развертыванием у микросервисов проблем нет, так как это контейнеры. Главное сегодня (для любого размера бизнеса) - это масштабирование. Вот эту проблему микросервисы и решают, а чтобы ее решить как раз надо быстро развертывать, да еще с перманентной отказоустойчивостью, поэтому не может быть проблем с развертыванием там, где решения по автоматизации всего этого лежат в основе.
А если еще надо дешевого и сердито, то облачные вычисления рассчитаны как раз на микросервисы, так как позволяют адаптировать затраты под текущую нагрузку.
Ну а насколько это все эффективно и гармонично, прямиком зависит от кривизны рук архитектора всего этого оркестра (достаточно согласованности API, а там хоть десятки тысяч разработчиков будут пилить эти микросервисы).
И да, даже дорогой архитектор дешевле, чем потом все переделывать для масштабирования под нагрузку, и платить провайдеру за ошибки архитектуры.
P.S.
Основная проблема микросервисов, да и других архитектурных решений, излишняя строгость следования основным принципам архитектуры. Вот реально был пример, когда разработчик сервера не мог добавить время сервера в каждый ответ, так как SOLID у него :) Гибче надо быть, и вникать в суть решения, а не в формальности реализации.
"А если еще надо дешевого и сердито, то облачные вычисления рассчитаны как раз на микросервисы, так как позволяют адаптировать затраты под текущую нагрузку."
и будет дорого и плохо при любой нагрузке