Comments 9
Классная статья, читается достаточно легко, перенося читателя от одной архитектуры к другой без оголтелого доказательства преимущество конкретной архитектуры.
От себя добавлю, что для меня переход на микросервис из монолита может быть обусловлен не столько удобством разработчиков или прозрачностью архитектуры, а если обобщать то это по техническими параметрами, а выгодой для бизнеса которую принесет переход.
Например: 1) при переходе на микросервис будет возможность высвободить 50% дорогого железа, это конечно если аренда железа в месяц стоит 2-х зарплат ведущего разработчика и более, правда такое сложно представить, но можно, уровень OZON наверное. 2) при переходе на микросервис будет разделена логика и ресурсы таким образом что поддержка микросервисов толпой midl-ов станет дешевле чем поддержка монолита командой senior-ов, тоже кейс OZON. 3) в условиях что монолит стал настолько большой что модификации начали приводить к неожиданным регрессам функций в неожиданных местах из-за объема и запутанности кодовой базы и бизнес из-за этих регрессов несет ощутимую бизнес потерю, например прибыль падает.
Если вы не крупная компания типа Яндекс, мета и ТД вам не нужны микросеовисы. Достаточно вспомнить что Stack Oveflow это монолит.
Наверное должны быть высокие требования к программистам. Строгое разделение по доменам.
А если проект старый, то к гадалке не ходи, там все будет вперемешку
Все это будет на порядок в худшей степени когда микросервисы превращаются со временем в распределённый монолит, что я видел в 99% проектов. И потом мыши кололись но жрали кактус. Вместо того, чтобы склеить пяток микросервисы в один монолит и выдохнуть на секунду)))
Если не сложно, раскройте, пожалуйста, чем распределенный монолит отличается от хороших микро сервисов. Набор признаков и/или фундаментальное отличие. Спасибо!
Так это самое худшее из зол, на каждой конференции рассказывают как нельзя делать микросервисы, но потом все опять лезут в одну и ту же базу, горизонтальные спагетти вызовы, зависимости в вызовах друг от друга, никто не париться если один модуль отвалится , обычно падает всё по цепочке и тд. Все это решается модульным монолитом: нет накладных расходов на сетевые задержки и трансформации, ресурсов жрет в разы меньше и поддержка легче и дешевле.
Если у вас меньше 200 модулей то вам не нужны микросервисы. Хотя бы посчитать что на один микросервис нужно 3 пода для стабильности, вот и посчитайте сколько инстансов монолита вы можете запустить и насколько это будет проще поддерживать, мониторить и ТД.
Обеспечивает оркестрацию контейнеров
Это наверно как если бы скрипачей, виолончелистов, всех из оркестра расфасовали по контейнерам, чтобы они лучше оркестрировали. Мне одному кажется что это словосочетание как-то странно звучит?
Ты стартап? — Тебе не нужны микросервисы.У тебя нет денег? — Тебе не нужны микросервисы.
Для этого есть довольно бюджетный вариант микросервисов на serverless архитектуре. С которого довольно легко будет перейти на обычные микросервисы.
Микросервисы. Исследование кухни