Здесь два момента. Первый - как я уже говорил, это из моего прошлого опыта. Второй - моей заслуги в этом мало, там была реально сильная команда тимлидов и проектных менеджеров и большое доверие от бизнеса. В общем, звезды сошлись так.
Применяем, но там, где они действительно нужны. Просто с какого-то времени это перестало быть опцией по умолчанию, продаваемой направо и налево. Ради этого пришлось сделать некоторые эмоциональные вбросы по тексту. Надеюсь, меня простят за это :)
Сегодня в Telegram-канале ИТ Архитекторов я получил разгоромный комментарий от одного из участников и с его разрешения делюсь им. На мой взгляд, это хорошо оформленная точка зрения, показывающая неоднозначность темы, и я должен ей поделиться. Далее по тексту:
Про плюсы монолита:
Простота разработки в IDE зависит от того, монорепа или нет. Сколько сервисов - пофиг, IDE все стерпит )
Аналогично, нет проблем рефакторить и множество сервисов.
А почему монолит проще тестировать? Скорее сложнее, связей внутренних обычно больше.
Если развертывание идет через копирование файлов - то у вас большие проблемы с процессами, увы. Выкладка монолита - тоже сложный процесс, с миграциями, плановым остановом (если не поддерживается выкладка без простоя) и так далее.
Минусы тоже не совсем про монолиты:
Что значит "сложно разрабатывать разнородную функциональность"? Как это выражается? Почему в монолите это сложнее?
Можно и монолит частично выкладывать, делов-то. Ну, если это нужно. Технологий для этого куча.
Можно и монолит сделать кластеризуемым, это не сложно. И масштабируемым.
Нарисованные картинки с архитектурой цитадели вызывают много вопросов (особенно про отдельный интерфейс форпостов, это обычно не очень хороший подход, особенно в данном случае, лучше уж многослойную архитектуру рисовать). Впрочем, термин цитадали неплохо вносить в массы, это плюс.
Из плюсов микросервисов
непрерывную доставку можно делать и на монолите, микросервисы тут не при чем.
автономность команд не очень зависит от микросервисов или монолитов, а скорее от процессов.
Среди минусов не названы самые главные:
Версионирование взаимодействия и вытекающие проблемы с выкладкой
К сожалению, название этого паттерна активно применяют только в сообществах архитекторов, так что можно считать это первой попыткой вынести его наружу в русскоязычном сообществе.
Сейчас я уже активно не участвую в этом проекте, но тем не менее информацией поделиться могу. С момента постановки задачи до раскатки на сервера львиная доля времени уходит на все, что связано с разработкой и это время зависит много от чего. Думаю, вы не об этом хотели спросить. Насчёт масштабирования всё просто - хватило двух нижних осей, т.е. количества инстансов и количества шардов по географии.
Форпост не обязан иметь микрофронт. И следуя метафоре, которая кажется мне очень удачной, форпост нужен для сдерживания потока внешних врагов - врагов определенного вида. И ходить в цитадель он будет не часто, ввиду своей самодостаточности.
Как изменился у вас объём тестирования при этом? Сколько тестов вы выкинули, сколько переписали? Как вы сейчас тестируете решение целиком? Если речь о тестировании функционала в рамках своего контекста/микросервиса, что мешало запускать тесты в параллель помодульно? Если перешли на CDC подход, что мешало применять его в модульном монолите?
Липкие сессии - это решение для горизонтального масштабирования и применимо оно как для монолитов, так и для микросервисов. В статье картинка про куб масштабирования есть, там это отдельное измерение.
Я для себя вывел эмпирические правила - 1) масштабировать сначала по измерениям, наименее ограниченным окружением или внутренностями предметной области, и 2) не вводить новые измерения без крайней необходимости.
Зря вы так превозносите архитекторов. Они в среднем бесполезны.
Вот не хотел я, чтобы мой комментарий так воспринимали. Видимо, не удалось правильно сформулировать.
Архитектор - по должности/лычкам и архитектор по складу ума/призванию - разные понятия. Я имею в виду именно вторых.
Ещё я хотел бы сделать акцент на том, что проектирование и разработка приложений с одной стороны, и программных систем с другой - это все-таки отличающиеся вещи, в которых полезны разные навыки. Кроме того, условные 20+ лет боевого многопроектного опыта против курсов переподготовки "вайти" могут сыграть свою роль.
Знаете, я где-то понимаю и даже разделяю вашу грусть. И если рынок будет диктовать своё намерение переводить свои системы на микросервисную архитектуру, у меня есть аргументы за то, чтобы хотя бы подумали об альтернативах.
Но если решение уже принято окончательно и бесповоротно - ок, этот инструмент тоже есть в моём арсенале и мой священный долг как архитектора - минимизировать возможный вред от этого решения.
Самая большая разница в направлениях и объёмах потоков данных. Функциональная декомпозиция предполагает намного большую интенсивность взаимодействий между нодами, так как доменную логику реализуют сервисы запущенные на них. Даже с учетом выделения ограниченных контекстов.
В случае горизонтального масштабирования или шардирования монолитов ноды могут вообще не взаимодействовать явно, т.е. в вырожденном случае это будет не классическая распределенная система, а многоуровневая с некоторыми нюансами в виде балансировщика, аналитического хранилища и иже с ними.
К сожалению, в нашем неидеальном для ИТ мире позиция архитектора закрывается по низшему приоритету. И это понятно - зачем бизнесу вкладываться в завтра, если непонятно, выживет ли он сегодня.
Бывают, конечно, случаи, когда разработчик внезапно проявил незаурядные таланты в проектировании - но это близкая к погрешности удача.
Да по сути основной посыл статьи как раз об этом. Микросервисы не должны быть вариантом по умолчанию только потому, что это модно. Это инструмент решения определенного класса задач, причём достаточно ограниченного.
Если на картинке стрелочки расставить так, как оно обычно бывает в микросервисах, можно было бы сложить по связям много интересных слов :) поэтому я не рискнул.
Проблемы монолитов часто идут от того, что они растут из решений, которые не предполагали увеличения нагрузок. И часто такие решения разрабатывались людьми, которые не имели на тот момент нужных знаний или опыта. А как известно, исправление ошибок проектирования намного дороже исправлений кода. Вот и откладывается это на лучшие времена, а потом ищутся серебряные микросервисные пули.
Думаю, вы все-таки спросили про проектирование, а не про разработку, поправьте, если я ошибаюсь. Тогда максимальной по объему и нагрузке была система для онлайн/оффлайн ритейлера федерального масштаба. Максимальное количество разработчиков - в районе 300, порядка 25 bounded context, говоря ubiquitous language-ом :) Этот проект ещё идет, так как пожелания ритейлеров неисчерпаемы. И модульный монолит прекрасно справляется.
Цитадель - это монолит, сумевший вовремя остановиться в процессе миграции на микросервисы :)
Сейчас изучил страничку с вашего сайта про проимущества и сравнения с другими системами. Судя по сравнениям, у вас или Идеальное Решение Всех Времён и Народов, или непонимание/непризнание собственных слабостей. А может быть это злой Маркетолог пришёл и сказал, что недостатков быть не должно и все ему подчинились?
Искренне желаю вам удачи!
Мы в свое время тоже искали, не нашли и пилим своё, стараясь не наступать на грабли, пройденные коллегами. И обещанная вами статья, надеюсь, позволит нам придумать что-то хорошее.
Да тот же 1С к примеру. Большинство систем-"убийц" построено по схожим принципам. В них обычно есть редакторы структуры, калькуляций и реакций (также, как и в 1С, отличия в названиях). И код, либо внешний, либо встроенный, интерпретируемый или компилируемый, исполняемый шаг за шагом.
Вы сейчас на какой вопрос ответили?
Хотя бы про какую систему?
Я прекрасно понимаю, для чего вводят новые уровни абстракции. Я не понимаю принципов, по которым lsFusion отстраивается от других. Мы функциональные, умеющие компилироваться в нативный SQL? У нас новый декларативный синтаксис в функциональном стиле?
А чем это лучше императивщины, со встроенными скриптами и декларациями?
Давайте инновационность оставим нашей управленческой "илите", а то им нечем будет оправдывать вливания средств в курируемые решения. Функциональный подход — отлично, но чем он помогает конечным пользователям? Думаю, квантовые вычисления и блокчейн могут добавить инновационность, только оно нужно?
Я прочитал все материалы из вашего блога, потому что сама тема для меня интересна, пощупал демо вашего решения — и кроме функционального подхода больших преимуществ для конечного пользователя не увидел.
Вы свысока говорите об ORM, но далеко ли от неё ушли в lsFusion? Намного ли дальше императивщиков?
Ну как же? Как только где-то появляется система с более-менее сносным конфигурированием, они сразу же позиционируют себя убийцами 1С. И статьи пишут в стиле "XXX vs 1С". Странно, что вы их не помните. Справедливости ради, они появляются в информационном поле, попылят год-два, а потом сдуваются. Примеры: Apprentis, Ultima.
А сколько ещё тех, кто не сильно шумит, а просто тихо-мирно внедряются и живут этим? Я, например, участвовал в разработке конфигурируемой системы KV-Expert, ответвлении от системы Avarda, участвовал в разработке внутренней ERP (тоже конфигурабельной) для мебельного производства, а сейчас развиваю конструктор для описания предметных областей и решения задач под них (тоже, кстати, высококонфигурабельное).
В качестве пожелания — если уж вы анонсировали материал на несколько статей, и, более того, вы представляете себе, что там будет, не могли бы вы сделать содержание того, чего ожидать в следующих публикациях? По тексту анонсы есть, но я для себя не смог решить, интересно/полезно ли мне это.
Здесь два момента. Первый - как я уже говорил, это из моего прошлого опыта. Второй - моей заслуги в этом мало, там была реально сильная команда тимлидов и проектных менеджеров и большое доверие от бизнеса. В общем, звезды сошлись так.
Применяем, но там, где они действительно нужны. Просто с какого-то времени это перестало быть опцией по умолчанию, продаваемой направо и налево. Ради этого пришлось сделать некоторые эмоциональные вбросы по тексту. Надеюсь, меня простят за это :)
Сегодня в Telegram-канале ИТ Архитекторов я получил разгоромный комментарий от одного из участников и с его разрешения делюсь им. На мой взгляд, это хорошо оформленная точка зрения, показывающая неоднозначность темы, и я должен ей поделиться. Далее по тексту:
Про плюсы монолита:
Простота разработки в IDE зависит от того, монорепа или нет. Сколько сервисов - пофиг, IDE все стерпит )
Аналогично, нет проблем рефакторить и множество сервисов.
А почему монолит проще тестировать? Скорее сложнее, связей внутренних обычно больше.
Если развертывание идет через копирование файлов - то у вас большие проблемы с процессами, увы. Выкладка монолита - тоже сложный процесс, с миграциями, плановым остановом (если не поддерживается выкладка без простоя) и так далее.
Минусы тоже не совсем про монолиты:
Что значит "сложно разрабатывать разнородную функциональность"? Как это выражается? Почему в монолите это сложнее?
Можно и монолит частично выкладывать, делов-то. Ну, если это нужно. Технологий для этого куча.
Можно и монолит сделать кластеризуемым, это не сложно. И масштабируемым.
Нарисованные картинки с архитектурой цитадели вызывают много вопросов (особенно про отдельный интерфейс форпостов, это обычно не очень хороший подход, особенно в данном случае, лучше уж многослойную архитектуру рисовать). Впрочем, термин цитадали неплохо вносить в массы, это плюс.
Из плюсов микросервисов
непрерывную доставку можно делать и на монолите, микросервисы тут не при чем.
автономность команд не очень зависит от микросервисов или монолитов, а скорее от процессов.
Среди минусов не названы самые главные:
Версионирование взаимодействия и вытекающие проблемы с выкладкой
Поддержка кучи разных БД
Гарантии для бизнес-транзакций между разными БД
Если в среднем, то полторы-две недели.
Корни цитадели идут отсюда https://blog.appsignal.com/2020/04/08/the-citadel-architecture-at-appsignal.html
К сожалению, название этого паттерна активно применяют только в сообществах архитекторов, так что можно считать это первой попыткой вынести его наружу в русскоязычном сообществе.
Сейчас я уже активно не участвую в этом проекте, но тем не менее информацией поделиться могу. С момента постановки задачи до раскатки на сервера львиная доля времени уходит на все, что связано с разработкой и это время зависит много от чего. Думаю, вы не об этом хотели спросить. Насчёт масштабирования всё просто - хватило двух нижних осей, т.е. количества инстансов и количества шардов по географии.
Форпост не обязан иметь микрофронт. И следуя метафоре, которая кажется мне очень удачной, форпост нужен для сдерживания потока внешних врагов - врагов определенного вида. И ходить в цитадель он будет не часто, ввиду своей самодостаточности.
Поделитесь своим опытом:
Как изменился у вас объём тестирования при этом? Сколько тестов вы выкинули, сколько переписали? Как вы сейчас тестируете решение целиком? Если речь о тестировании функционала в рамках своего контекста/микросервиса, что мешало запускать тесты в параллель помодульно? Если перешли на CDC подход, что мешало применять его в модульном монолите?
Липкие сессии - это решение для горизонтального масштабирования и применимо оно как для монолитов, так и для микросервисов. В статье картинка про куб масштабирования есть, там это отдельное измерение.
Я для себя вывел эмпирические правила - 1) масштабировать сначала по измерениям, наименее ограниченным окружением или внутренностями предметной области, и 2) не вводить новые измерения без крайней необходимости.
Вот не хотел я, чтобы мой комментарий так воспринимали. Видимо, не удалось правильно сформулировать.
Архитектор - по должности/лычкам и архитектор по складу ума/призванию - разные понятия. Я имею в виду именно вторых.
Ещё я хотел бы сделать акцент на том, что проектирование и разработка приложений с одной стороны, и программных систем с другой - это все-таки отличающиеся вещи, в которых полезны разные навыки. Кроме того, условные 20+ лет боевого многопроектного опыта против курсов переподготовки "вайти" могут сыграть свою роль.
Знаете, я где-то понимаю и даже разделяю вашу грусть. И если рынок будет диктовать своё намерение переводить свои системы на микросервисную архитектуру, у меня есть аргументы за то, чтобы хотя бы подумали об альтернативах.
Но если решение уже принято окончательно и бесповоротно - ок, этот инструмент тоже есть в моём арсенале и мой священный долг как архитектора - минимизировать возможный вред от этого решения.
Самая большая разница в направлениях и объёмах потоков данных. Функциональная декомпозиция предполагает намного большую интенсивность взаимодействий между нодами, так как доменную логику реализуют сервисы запущенные на них. Даже с учетом выделения ограниченных контекстов.
В случае горизонтального масштабирования или шардирования монолитов ноды могут вообще не взаимодействовать явно, т.е. в вырожденном случае это будет не классическая распределенная система, а многоуровневая с некоторыми нюансами в виде балансировщика, аналитического хранилища и иже с ними.
К сожалению, в нашем неидеальном для ИТ мире позиция архитектора закрывается по низшему приоритету. И это понятно - зачем бизнесу вкладываться в завтра, если непонятно, выживет ли он сегодня.
Бывают, конечно, случаи, когда разработчик внезапно проявил незаурядные таланты в проектировании - но это близкая к погрешности удача.
Да по сути основной посыл статьи как раз об этом. Микросервисы не должны быть вариантом по умолчанию только потому, что это модно. Это инструмент решения определенного класса задач, причём достаточно ограниченного.
Если на картинке стрелочки расставить так, как оно обычно бывает в микросервисах, можно было бы сложить по связям много интересных слов :) поэтому я не рискнул.
Проблемы монолитов часто идут от того, что они растут из решений, которые не предполагали увеличения нагрузок. И часто такие решения разрабатывались людьми, которые не имели на тот момент нужных знаний или опыта. А как известно, исправление ошибок проектирования намного дороже исправлений кода. Вот и откладывается это на лучшие времена, а потом ищутся серебряные микросервисные пули.
Думаю, вы все-таки спросили про проектирование, а не про разработку, поправьте, если я ошибаюсь. Тогда максимальной по объему и нагрузке была система для онлайн/оффлайн ритейлера федерального масштаба. Максимальное количество разработчиков - в районе 300, порядка 25 bounded context, говоря ubiquitous language-ом :) Этот проект ещё идет, так как пожелания ритейлеров неисчерпаемы. И модульный монолит прекрасно справляется.
Цитадель - это монолит, сумевший вовремя остановиться в процессе миграции на микросервисы :)
Сейчас изучил страничку с вашего сайта про проимущества и сравнения с другими системами. Судя по сравнениям, у вас или Идеальное Решение Всех Времён и Народов, или непонимание/непризнание собственных слабостей. А может быть это злой Маркетолог пришёл и сказал, что недостатков быть не должно и все ему подчинились?
Искренне желаю вам удачи!
Мы в свое время тоже искали, не нашли и пилим своё, стараясь не наступать на грабли, пройденные коллегами. И обещанная вами статья, надеюсь, позволит нам придумать что-то хорошее.
Да тот же 1С к примеру. Большинство систем-"убийц" построено по схожим принципам. В них обычно есть редакторы структуры, калькуляций и реакций (также, как и в 1С, отличия в названиях). И код, либо внешний, либо встроенный, интерпретируемый или компилируемый, исполняемый шаг за шагом.
Вы сейчас на какой вопрос ответили?
Хотя бы про какую систему?
Я прекрасно понимаю, для чего вводят новые уровни абстракции. Я не понимаю принципов, по которым lsFusion отстраивается от других. Мы функциональные, умеющие компилироваться в нативный SQL? У нас новый декларативный синтаксис в функциональном стиле?
А чем это лучше императивщины, со встроенными скриптами и декларациями?
Давайте инновационность оставим нашей управленческой "илите", а то им нечем будет оправдывать вливания средств в курируемые решения. Функциональный подход — отлично, но чем он помогает конечным пользователям? Думаю, квантовые вычисления и блокчейн могут добавить инновационность, только оно нужно?
Я прочитал все материалы из вашего блога, потому что сама тема для меня интересна, пощупал демо вашего решения — и кроме функционального подхода больших преимуществ для конечного пользователя не увидел.
Вы свысока говорите об ORM, но далеко ли от неё ушли в lsFusion? Намного ли дальше императивщиков?
Ну как же? Как только где-то появляется система с более-менее сносным конфигурированием, они сразу же позиционируют себя убийцами 1С. И статьи пишут в стиле "XXX vs 1С". Странно, что вы их не помните. Справедливости ради, они появляются в информационном поле, попылят год-два, а потом сдуваются. Примеры: Apprentis, Ultima.
А сколько ещё тех, кто не сильно шумит, а просто тихо-мирно внедряются и живут этим? Я, например, участвовал в разработке конфигурируемой системы KV-Expert, ответвлении от системы Avarda, участвовал в разработке внутренней ERP (тоже конфигурабельной) для мебельного производства, а сейчас развиваю конструктор для описания предметных областей и решения задач под них (тоже, кстати, высококонфигурабельное).
Зачем видео? Давайте статью на хабре! Был бы очень благодарен