Comments 14
Возникает риск скатиться в "распределенный монолит" - мне показалось автор не имел дело с понастоящему распределенным монолитом? Хорошо спроектированный покрывает 80% задач, а сказки про большые обновления, разбиваются о сборки с дельтами...
Чем больше погружаюсь с микросервисы, все больше понимаю что это оверинжиниринг, потому что его строить начинают по хайпу, а надо сначала изучить что такое конвеер и оркестрация...
"Распределенный монолит" не может быть хорошо спроектированным, потому что по определению является результатом неудачного проектирования. Так обычно называют класс систем, которые состоят из множества сильно связанных микросервисов, имеют все недостатки микросервисной архитектуры (много сетевых взаимодействий, eventual consistency, etc.), но никаких ее преимуществ - отсутствие независимых развертываний, независимого масштабирования и т.д.
Мягко говоря спорное утверждение. Распределённый монолит вполне может быть оптимальным решением. Например, если вам подходит монолит, но вы хотите легко и дёшево получить плюшки масштабирования или параллельной разработки несколькими командами. При качественной организации работы это одна из самых экономически выгодных архитектур с точки зрения стоимости разработки.
В статьях про микросервисы и переход к микросервисной архитектуре под понятием "распределенный монолит" обычно подразумевается ситуация, когда, при распиле большого приложения на много маленьких, в ходе проектирования были совершены ошибки, и теперь все эти много маленьких приложений нужно масштабировать, дорабатывать и развертывать одновременно, сама система не переживает падения ни одного из ее узлов и т.д. То есть получается, что с точки зрения инфраструктуры система распределенная, а с точки зрения ее поведения - тот самый "плохой" монолит. Отсюда и название.
То, о чем говорите вы, больше похоже на классическую ситуацию, когда в компании есть 2-3-4 больших приложения, выполняющих разные функции и разрабатываемые несколькими командами параллельно.
когда в компании есть 2-3-4 больших приложения,
Это ошибка, модульный монолит это одно большое приложение, которое покрывает несколько доменов бизнеса, и выполняет основную задачу. А связь там может быть разная, и количество команд тоже. И хорошо спроектированный монолит покрывает 80% задач бизнеса. И устойчивость с точки зрения стабильности выше, так как нет лишних элементов в виде сети, и мониторинг проще...
В статье и моих комментариях говорится про «распределенный монолит», не про «модульный монолит»
А самое главное стоимость его разработки и поддержания кратно ниже - меньше трудозатраты и меньше команд нужно. Но зато сильно выше требования к организации работы.
Одна из проблем нынешнего IT в том, что программисты и архитекторы исходят из наличия бесконечного количества ресурсов на разработку и поддержание. И все время пытался выбирать "идеальные " решения, без оглядки на конечную стоимость. А на практике ресурсы всегда ограничены и оптимальным оказывается совсем другое решение. В результате какая-то совершенно космическая стоимость получается и ужасно низкая экономическая эффективность.
Совершенно верно. Я много лет работал с модульным монолитом. И его архитектура была просчитана. Не идеальна, но просчитана. И главное можно было быстро поставить из коробки в том размере, который нужен был, начиная от девов и заканчивая монстрами для прода на несколько стоек в серверной.
Не просто так, многие стали уходить от микросервисов, дорого и не всегда нужно.
Модульный монолит запросто можно не имеет возможности работать на нескольких серверах и не имеет возможности масштабирования своих составляющий. У него основное качество - модульность, которая позволят распараллелить разработку. О распределении по серверам это ничего не говорит. А распределённый монолит однозначно умеет запускать свои модули на нескольких серверах. А то, что кто-то значений слов не знает и бездумно ярлыки вешает, так это сейчас модно.
У вас все в куче. Может для начала надо понять что такое модульный, монолит, потом почитать что такое снежинка при проектировании субд, потом посмотреть какие джава сервера есть для интерпрайза, и понять какие там есть инструменты, а потом писать? Я все больше убеждаюсь что микррсервисы делают потому что стильно модно молодежно, а не потому что изучают основы архитектуры приложений
И да, распределенная структура, это когда у вас база на одной железке или двух, джава сервер раскидывает свои мощности на несколько клястеров и так далее, вообщем изучите основы и базу, пока выглядит слабо.
Развертывание микросервисов: проблемы, решения, стратегии, антипаттерны, практические рекомендации