Comments 101
Достаточно неплохая обзорная техническая статья. Но тут главное архитекторское описано очень вскользь: требования диктуют архитектуру. И работа с требованиеми - важнейший кусок архитектурной работы. А это уже не только технические решения.
Спасибо за комментарий.
Здесь рассматриваются исключительно вопросы масштабируемости. Рассмотреть в требованиях насколько критична для бизнеса некосистентность тех или иных данных и соответственно можем ли мы применить в этом месте инструменты повышения производительности, которые плохо скажутся на консистентности? Конечно, это необходимо.
Прочитал вашу статью о том что микросервисы необходимы для fast deploy. Не соглашусь что в монолите изменение одного модуля приведёт к полному регресс тестированию всего приложения. Статические анализаторы позволяют доказать независимость модулей и что зависимости не протекли в другие модули. Это вопрос к квалификации QA и если он это не умеет в монолите, то команда на ровном месте огребет проблемы микросервисов.
Статические анализаторы позволяют доказать независимость модулей и что зависимости не протекли в другие модули.
Это прекрасно, но получить консистентную систему над которой работают 10 команд одновременно можно, но сложно. Обычно это требует многих междукомандных согласований, что отдельная дисциплина спецолимпиады. Практика это подтверждает, в большинстве случаев релизы монолитов случаются редко, раз в несколько месяцев. А раз так - то статистический анализ вам покажет, что все во всех модулях поменялось. И привет регрессия.
Я не отрицаю, что можно и монолиты релизить раз в неделю, но на масштабе это работает очень плохо, откуда собственно говоря вся эта мода на микросервисами с их огромными недостатками.
можно и монолиты релизить раз в неделю
А в чем проблема? Одна команда делает одну DLL, другая другую. Поверхность соприкосновения минимальная и контролируемая. Если меняется контракт то в микросервисах некоторое время поддерживают обе версии. При минимальных усилиях в монолите тоже можно поддерживать две версии функционала через конфигурации. Запрос пойдет по той ветке которая нужна. Старая версия закончит обработку по тайм-ауту и будет удалена.
Зато у нас в монолите быстрые и надёжные вызовы кода без ретраев и тайм-аутов, быстрые join и так далее.
Просто я немного задолбался поддерживать аналитическую систему в географически распределенной системе источников данных. Была сложная самописная логика повторов, тайм-аутов, выравнивания нагрузки и circuit breakers (предохранителей) с высокими требованиями к надёжности и отсутствию искажений данных из-за некосистентности данных. Не помогли никакие логеры и быстрый деплой тоже не помог. Помогло переписывание ядра с понятной, сконцентрированной бизнес логикой, state machine, отсутствием скрытых состояний и с нулевым доверием ко всему io
Обычно это требует многих междукомандных согласований, что отдельная дисциплина спецолимпиады
Обычно это решается человеком который там живёт и которого не перекидывают с одного продукта на другой по любому чиху
А в чем проблема? Одна команда делает одну DLL, другая другую. Поверхность соприкосновения минимальная и контролируемая.
В теории я с вами согласен. На практике такое возможно и бывает, но почему то очень редко встречается в литературе, да и в моем опыте. Имея большую команду в сотню человек и огромную кодовую базу и возхможность внести незаметно неявные зависимости для быстрого решения срочных проблем не сомневайтесь, это будет сделано как только так сразу. И опять таки, повторюсь, весь этот микросервисный хайп - не от статистически хорошей истории жизни с монолитами.
Просто я немного задолбался поддерживать аналитическую систему в географически распределенной системе источников данных.
Знаете анекдот про дурака в церкви и стеклянный буй? Если у вас был один(или 5) негативных кейсов, это не говорит ровным счетом ничего. Если конечно это не кейсы масштаба амазон или нетфликс.
внести незаметно неявные зависимости
Статический анализатор кода должен помочь. Хотя, у микросервисов гарантии сильнее, согласен. Примерно как топором по проводке.
Если у вас был один(или 5) негативных кейсов, это не говорит ровным счетом ничего
Ну, кейсы нефликс на себя натягивать тоже глупо.
микросервисный хайп - не от статистически хорошей истории жизни с монолитами
Слишком часто встречал раздувание штата чтобы запудрить глаза инвесторам или чтобы поднять свою значимость и незаменимость. Да и многие отказываются от микросервисов потихоньку, соединяют обратно в монолит(ы)
неявное использование кеша для прокидывание контрактов и даже sick(!) stack trace, походы в чужие схемы данных из хранимок в сотни строк, изменение чужих данных из этих же хранимок с неявным ослабление секурити, вызов кода минуя необходимые слоя и какой хери я только не видел. В микросервисах как минимум контракты можно жестко контролировать, внутри тоже зачастую ад и израиль творится, но оно локализировано и (почти)гарантированно не расползается. Что позволяет масштабироваться до сотен человек индусов за чашку риса в месяц и при этом быть корммерчески успешными.
Ну, не буду спорить.
Но посыл моей статьи что микросервисы не нужны только для масштабирования (Scalability, может вы имеете в виду Extensibility? Или вообще, расширяемость команд?) и вообще для производительности. Если нет проблемы развития большой и сложной кодовой базы или проблемы быстрого деплоя так и не нужны совсем. Для остального есть Mastercard
о посыл моей статьи что микросервисы не нужны только для масштабирования
Если мы говорим о Scalability, то микросервисы имеют минорные бенефиты - скейлиннг разных частей системы по разному. Но это реально мелочи и монолитом можно достичь того же чуть бОльшими приседаниями и значительно бОльшим размером контейнеров.
Поэтому как я в статье написал - микросервисы нужны для решения организационных проблем крупных команд - начиная от человек 50-70 на проекте.
может вы имеете в виду Extensibility? Или вообще, расширяемость команд
Наверное самой правильной метрикой будет TTM, Time to Market - опять таки на масштабе ОТ 50-70 человек в команде.
Для остального есть
Mastercard
Дык я ж не спорю. Более того, я всегда за то чтобы стартовать "проект с нуля" с монолита - быстрей, проще, рефакторинг в разы дешевле. Обычно стартуют одной командой, и если выстрелило - то в короткие сроки может образоваться 3-5-10 команд. И тут "хорошо структурированный монолит легко бьется на микросервисы"(ц) и мы получаем и быстрый старт монолитом и относительно безболезненно переживаем рост.
Насчёт time to market продукта в целом и его фич не могу с уверенностью сказать необходимы микросервисы или можно обойтись. Просто не работал в больших командах
Но я могу попробовать смоделировать. 100 человек - такой продукт ещё эффективно помещается в голове одного архитектора.
Если мы говорим о Scalability, то микросервисы имеют минорные бенефиты
Вот здесь я совершенно согласен. Хотя, я часто слышал противоположное мнение и борюсь с этим. Про это и статья.
100 человек - такой продукт ещё эффективно помещается в голове одного архитектора.
Очень сильно зависит от менеджмента и построенных ими процессов. "В среднем по палате" в моей практике, один архитектор эффективен для 2-4 команд, тоесть до 40 человек. И хорошо, если есть время регулярно смотреть код, писать - большая удача. А так - сплошная синхронизация интеграции, 6 часов митингов в день и оставшееся время - квадратики и стрелочки :)
В МСА как раз ttm резко взлетает, по сравнению с модульным монолитом.
Вот от 200 человек - да, монолитом сложно управлять. Но это проблема не в монолите, а в попытке в одно приложение упаковать несколько разных продуктов.
как разложить приложение на несколько разных продуктов?
Сделать несколько разных приложений.
Собственно, DDD (в нормальном использовании) как раз про это - и не связано особенно с МСА.
А вот где проводить границу "разные продукты/домены или один" - зависит как раз от размера, опытности команд и прочих внешних факторов.
Несколько приложений с общими данными это распределенная архитектура. Без общих данных может быть если процессы не имеют точек соприкосновения, но обычно в пределах одной компании такого не бывает.
Даже если один процесс начинается через месяцы и годы после второго (как на госуслугах) всё равно пользователь не хочет повторно вбивать данные, не хочет что-то вспоминать, копировать и не дай бог подавать что-то в бумаге, полученной в другом ведомстве. Он хочет чтобы государство не переспрашивало и чтобы все данные проходили бесшовно. Для этого есть СМЭВ
Правда, СМЭВ больше похожа на ESB чем на оркестратор микросервисов.
А почему с "общими данными"? У разных продуктов как раз очень мало общих данных, при нормальном проектировании - вообще никаких кроме некоторых идентификаторов.
И да, всякие MDM - это как раз отдельный продукт.
СМЭВ - это продукт поверх других продуктов, так-то там каждое министерство со своей информационной системой, а СМЭВ - это шина обмена, не более.
DDD (в нормальном использовании) как раз про это - и не связано особенно с МСА
MSA о том, что данные тоже надо изолировать, разрезать по доменам
У МСА вообще нет нормального определения. По большинству МСА - это про автономность (которой не бывает), независимость деплоя (которой тоже не бывает) и современные методы коммуникаций.
Ну и DDD - не про разделение по доменам, это про выделение доменов и контекстов, а уж как это мапится на приложения - не важно.
Сделать несколько разных приложений.
Но между этими продуктамим надо будет гонять данные, обеспечивать какие то гарантии целостности этих самых данных, имплементррвоать сагу, компенсирующие транзакции, ретраи и так далее по списку.... приветмикросервисы, которые вы назвали почему то "продуктами"
Хм, разные продукты - это как раз про отсутствие необходимости в активном обмене данными, в бизнес-транзакциях и так далее.
Да, выделение продуктов (доменов) - не тривиальная задача, но в этом и есть работа архитектора.
Если нет необходимости обмена данными то
а) вы эти данные гоняете через пользователя, а он этого не любит
б) процессы совсем не пересекаются, тогда за этими продуктами стоят разные компании
То есть у одной компании владельца не может быть совсем изолированных, непересекающихся процессов
Хм, очень странная мыль, что у компании-владельца нет изолированных процессов )
Вот у банка эмиссия и эквайринг - чем связаны?
Вот внутри T-банка продукт "доступ к бизнес-залам" как связан с остальными продуктами? Там общих данных - clientId и все.
Доступ к бизнес-залам может быть предоставлен как часть пакета премиальных услуг, например, для владельцев премиальных карт или клиентов с высоким балансом на счетах. В этом случае информация о том, что клиент имеет право на доступ к бизнес-залам, хранится в профиле клиента в системе банка.
Интеграция с другими продуктами может быть минимальной, но она все равно существует. Например, если клиент открывает новый счет или получает новую карту, система может автоматически проверять, соответствует ли клиент условиям для доступа к бизнес-залам, и обновлять его статус соответственно.
А при чем тут монолит?
И как микросервисы спасают от этих же проблем. Если разработчики некомпетентны даже в использовании интерфейсов, то откуда возьмется компетенция в создании распределенных систем?
Все те же проблемы постоянно вылезают и в МСА.
А вы найдите сотню компетентных разработчиков по цене чашки риса. И тогда и без микросервисов у вас все будет хорошо.
Так для распределенных систем (тех же МСА) нужны более компетентные специалисты. А если есть нормальные архитекторы, то без разницы, модули или микросервисы, все вполне себе контролируется.
Вы немного не понимаете как это работает с точки зрения бизнеса. Я в этом топике свои мысли и свой опыт описал, второй раз откровенно лень.
Хм, я вполне себе понимаю, как это работает с точки зрения бизнеса. Но там вообще не важен МСА, важны так или иначе автономные команды. Но автономность команд не связана с МСА, а связана с выстраиванием процессов и с entrerpise и solution архитектурой, с управлением знаниями и так далее.
с точки зрения бизнеса
Объективно? Или как бизнес, а вернее прослойка его менеджмента заблуждается или вводит в заблуждение?
Команда в 100 человек крайне редко делает один продукт. Обычно реально там много продуктов (и много монолитов). Ну и скорее всего про модульность никто и не думал никогда (впрочем, в МСА - тоже обычно никто не умеет в нормальную изоляцию, так как это сложно).
что такое один продукт на примере банковского приложения
приложение - продукт
а то, что за ним? вся эта кухня
Хм, мобильное приложение банка - не продукт, а интефейс к разным продуктам.
Вот эмиссия и эквайринг - разные продукты.
Кредитный конвеер - отдельный продукт почти всегда.
И какой-нибудь "доступ к бизнес-залам" - отдельный продукт (хотя обычно очень небольшой).
А если посмотреть на приложение чего-нибудь типа T-банка, то там куча разных продуктов (к банку вообще не имеющих отношения).
Команда в 100 человек крайне редко делает один продукт.
Вы главное продолжайте безапеляционно двигать тезисы :)
А расскажи, когда один продукт - делает команда больше 100 человек?
Который нет смысла разделить на несколько разных продуктов, независимых по процессам, данным, бизнес-транзакциям и так далее.
Эм, ну ок пример из моего недавнего прошлого. Фирма выпускает электронику под десятком разных брендов, включая эппл и самсунг, у нее около 30 крупных сборочных заводов электроники по всему миру.
Софт к котрому я руку приложил, отвечал за трекинг сборки элнектроники на конвеере: есть ли необходимоме количество запчасти для сборки нужного количества элементов сборки(плат, мониторов, целых устройств), как каждое из собираемых устройств проходит каждую стадию конвеера, как проходит тестирование собранных частей(и/или) целых устройств, сколько готово к отгруке(следуенщей части сборки) и так далее.
Начинали это все писать лет наверное 40-50 назад. Как тогда было модно - монолитом. На задаче только мигрирования всего этого в клауда и разбивки хоть на какие то сервисы (почему - отдельная история) было задействованно 80-150 только девов на протяжении лет 3х.
Оно конечно легко шашкой махать и рассказывать "как надо", а ты попробуй хоть малейшую инновацию проверни в таком инертном окружении, расскажи ПО продукта, что он теперь не совсем ПО продукта, а в дополнению к нему будут 25 ПО сервисов, которые будут иметь свое мнение.
Вот чем меня улыбают "технари" - во первых напоминают меня 20 лет назад, во вторых уверенны в том, что можно просто прийти, шашкой помахать и все будет по новому, полностью игнорируя конфликты интересов, человечский фактор и все вот эти нетехнические сопли
Хм, а где тут "один продукт"? И, заметим, тут все равно ты пишешь про примерно 100 человек, которые занимались этим софтом.
И да, я проводил довольно много разных арх.рефакторингов в очень разных окружениях. Да, это сложно. Но вполне реализуемо и внутри монолита. Но да, проблемы - не инженерные, а процессные в первую очередь. И решаются на этом уровне. А МСА - не при чем.
И, кстати, не думаю, что у меня меньше опыта )
То есть микросервисы от того что product owner или архитектор не смог организовать согласование "API" в монолите и качественной изоляции модулей в монолите? Не смог управлять сложностью. MSA же заставляет его формализовать общение команд по согласованию API, обеспечить проверку изоляции. И гарантирует это в виде барьера. Но дорого.
Причины тут могут быть разные: легаси, масштаб команд, технологическая невозможность надёжной изоляции модулей, неготовность команды и самого архитектора.
Но почему он не смог эффективно управлять сложностью?
Монолиты можно и нужно релизить когда код готов. На большинстве проектов это было не реже раза в день. Классический пример монолита - большинство ERP систем.
Ещё замечу, что пилить лучше то место, которое узко. Автор отлично подветил про БД как узкое место и про методы оптимизации и горизонтального масштабирования БД.
даже не БД узкое место а ожидание (а значит блокировки) пока пройдет транзакция
а если транзакция распределенная так приходится ждать совсем долго или выкручиваться за счет нарушения связности
обработка бизнес логики нынче редко когда узкое место
Хм, блокировка чего нужна при ожидании транзакции? Узкое место - как раз IOPSы и ядра в БД.
Но, заметим, шардирование не решает проблему транзакций.
По моему скромному опыту не согласен ни с одним из этих высказываний. Но тут сильно зависит от предметной области
Тогда поясни, про какие блокировки ты говоришь при ожидании транзакций?
И как шардирование может решать проблему транзакций?
В системах управления базами данных (СУБД) блокировки используются для обеспечения целостности данных при параллельном выполнении транзакций. Блокировка — это механизм, который предотвращает одновременный доступ к данным из нескольких транзакций, чтобы избежать конфликтов и несогласованности данных.
Когда данные разделены на шарды, транзакции, работающие с разными шардами, не конкурируют за одни и те же данные. Это снижает вероятность возникновения блокировок и дедлоков.
Поскольку транзакции работают с меньшими наборами данных, время выполнения каждой транзакции сокращается. Это также уменьшает время, которое транзакции проводят в состоянии ожидания блокировок.
Хм, релизы монолитов бывают и по три раза в день, в чем проблема-то?
Да и релизы многосервисных систем (МСА тут не при чем) бывают по полгода делают.
Релизы и архитектурный стиль крайне мало связаны. И МСА никак не решают проблему ускорения релизов.
Мода на МСА к релизам никак не привязана. Собственно, как и любая мода - она никак не связана с прагматичными соображениями.
Релизы и архитектурный стиль крайне мало связаны.
Не могу запретить вам так думать, свою точку зрения я изложил выше.
А аргументация для точки зрения есть?
Каким образом МСА (и что под ней понимаете, кстати - у термина плохо с общепринятым определением) помогает частоте релизов? За счет чего?
А аргументация для точки зрения есть?
свою точку зрения я изложил выше.
Я не увидел там аргументации за МСА. Поправь, но я видел следующий набор утверждений
1) Проблемы легаси в процессах и людях
2) При внедрении МСА придется перестраивать и процессы и людей
3) Поэтому в МСА лучше с частотой выкладки.
Первое и второе утверждение - верны.
Но вот пункт 3 никак и неоткуда не следует. И ниоткуда не следует, что переписать проект на модульный монолит или другой арх.стиль не решит тех же проблем с людьми и сервисами.
Скажите, откуда пошло заблуждение, что "...требования определяют архитектуру" ? Если вы занимаетесь созданием системы по требованиям - это обычная инженерная работа. Архитектуры в этом считай что и нет. Архитектура начинается тогда, когда вы строите систему под требования которые пока неизвестны, или может быть даже пока не существуют. Соответственно архитектор закладывает в систему точки расширения и масштабирования, хотя прямых показаний к этому в настоящий момент нет. И поскольку все эти точки расширения стоят денег - то искусство архитектора состоит в том, чтобы сбалансировать будущую стоимость содержания и рефакторинга системы и текущую стоимость избыточной адаптивности закладываемой прямо сейчас...
На более доступном языке - когда инженера просят построить дачный домик с конюшней, чтобы рано утром выезжать на коне кататься в поле - он имеет полное право сделать дом, в котором в одной комнате будете жить вы, а в другой - конь... А архитектор понимает что у вас потом появятся жена и дети, и они могут не разделять вашу любовь к конному спорту, поэтому комнат надо больше чем две, а конюшня должна быть отдельной. Ибо опыт развития человечества...
Архитектура не только и не столько учитывает текущие требования, но и определят стратегию развития продукта
И делает это, опираясь на требования. Как правило - нефункциональные. Пример:
функциональное требование требование, одинаковое для двух проектов: "я хочу смотреть видео в браузере, загруженное кем то на сервер".
В проекте 1 к этому функциональному требованию идет в нагрузку нефункциональное: "загружать видео будет моя жена раз в неделю и смотреть буду только я 3 раза в неделю ближайшие лет 20 это не изменится"
В проекте 2 к этому функциональному требованию идет в нагрузку нефункциональное: "загружать видео будут со старта 100к человек раз в день и смотреть 1млн 5 раз в день" и следом assumption "через 3 года мы планируем маcштабироваться на 100млн загрузок в день и 1млрд просмотров в день".
Определяет ли архитектура стратегию развития продукта, если будет в обоих случаях следовать требованиям? Безусловно, если архитектор все сделает правильно. Но в обоих случаях он не будет демонстировать некое "искусство угадывания несуществующих требований", а просто решать техническую задачу, опираясь на факты.
Не нужно угадывать несуществующие требования.
Но некоторый задел обычно оставляют. Примерно как в метро оставляют в тоннеле прямые участки с нужным расстоянием между тоннелями если выдвигалась идея построить тут станцию когда-нибудь.
Правильно. Этот "задел" обсуждают и подтверждают с бизнесом и помещают в секцию Assumptions. Затем работают с ними как и с остальными требованиями. Банально потому что бизнес обычно лучше понимает, в какую сторону нужен "задел" побольше, насколько "побольше" с цифрами и когда этот "задел" реально потребуется. А в какую сторону "задел" нафиг не нужен и никогда нужен не будет.
У вас очень оптимистическое понимание бизнеса. Я имел (не-) счастье видеть процесс по обе стороны баррикад: как со стороны разработки, так и со стороны бизнеса. В подавляюшем большинстве случаев - бизнес нихрена не знает. В некоторых случаях - ответственные люди выдают в качестве assumptions желаемое за действительность. Другие - общественно-приемлемые ответы и цифры. Третьи говорят что-то с потолка чтобы окружающие продолжали считать их умными... Клиентов, которые честно говорят "х его знает" там, где не знают - по пальцам пересчитать (и я их особо ценю за это!). Поэтому архитектор должен конечно слушать бизнес - но систему он строит с пониманием: не все что ему говорят - правда, а правда то - что часть требований к ней ему не говорят (и о них даже не догадываются).
Хотите пример архитектуры близкий к идеальному - посмотрите на себя. У вас примерно столько суставов, чтобы вы могли дотянуться до любой точки себя (хотя на спине и без особого удобства). Никто не знает в каком месте у вас вскочит прыщ или вы себе всадите занозу. Делать каждую руку с количеством суставов как у змеи - дорого и ненадежно. Сделать слишком мало суставов - можно помереть от заражения крови просто потому что не можешь дотянуться и вытащить щепочку. Так же и в ПО: задача архитектора - используя знания о предметной области и общую логику и опыт развития аналогичных систем заложить ровно столько точек расширения и конфигурируемости, чтобы и не умереть завтра от того что система ни в какую не удовлетворяет изменившимся требованиям, но и не дать ей умереть от чрезмерной стоимости еще на этапе проектирования и кодировнаия...
бизнес нихрена не знает
Это да. Немного бесит, когда основные компетенции по бизнес процессам не у бизнеса, а у разработки (причём, часто и не у аналитика / продакта, а именно у кодера)
У вас очень оптимистическое понимание бизнеса. Я имел (не-) счастье видеть процесс по обе стороны баррикад: как со стороны разработки, так и со стороны бизнеса. В подавляюшем большинстве случаев - бизнес нихрена не знает.
У меня реалистическое понимание бизнеса - такое как вы описали тоже бывает, и я такими "бизнесами" работаю в исключительных случаях.
В некоторых случаях - ответственные люди выдают в качестве assumptions желаемое за действительность. Другие - общественно-приемлемые ответы и цифры. Третьи говорят что-то с потолка чтобы окружающие продолжали считать их умными...
Это так же естественно для манагеров, как для кодеров - промахиваться в 3 раза с эстимейтами. И с тем и с этим можно и нужно работать, инструменты описаны лет 10-15 назад минимум.
Поэтому архитектор должен конечно слушать бизнес - но систему он строит с пониманием: не все что ему говорят - правда, а правда то - что часть требований к ней ему не говорят (и о них даже не догадываются).
И работа архитектора - эти требования выявить, обсудить и законфирмать. Для этого, неповерите, тоже есть методики, которые тоже описаны в тех же талмудах.
А вот "партизанить отсебятину" - это как раз фейспалм. Это может сработать, если у вас хороший опыт в конкретном сегменте конкретного бизнес домена и вы там сами все знаете лучше типимчного манагера. А вот шаг вправ-влево - и вероятность "приплыть" моментально подскакивает до 100%. В соседней ветке есть прекрасный гипотитический пример необходимости бассейнов на последнем этаже зданий :)
А не надо лезть в домены, в которых ничего не понимаешь. Архитектура дворца и архитектура моста - это разные архитектуры. У нас в 2000-е годы вдруг пришло поветрие, что менеджеру больше не нужно иметь опыта в домене: мол хороший менеджер сегодня может управлять типографией, а завтра - автомобильным заводом... Результаты в принципе можно наблюдать за окном.
А теперь вы пытаетесь представить дело так, что уже и архитектору не нужен опыт в домене: сегодня он проектирует интернет-магазин, завтра healthcare, послезавтра - комплекс ПО для авионики.
Я резко против этого (и по этой причине мы до крови сремся с архитектами в одной любимой организации). Если архитектуру понимать как "архитекты" из консалтинга - то есть когда вершиной архитектуры считается подготовленный ответ на RFP клиента, то да - не нужен опыт домена, достаточно по кволити-атрибутам подобрать тактики и записать в ахитектуре-десижн-лог. Если же целью архитектуры является стабильный жизненный цикл системы - то ой! Без опыта работы в домене, широкого кругозора и знания тактик (в том числе, но не в первую очередь) - удачи не видать...
А не надо лезть в домены, в которых ничего не понимаешь. Архитектура дворца и архитектура моста - это разные архитектуры.
Нет - базовые принципы не меняются. Равно как и у управленцев. Знание домена - плюс, но и без него все хорошо, всегда есть Subject Matter Experts которые все расскажут.
У нас в 2000-е годы вдруг пришло поветрие, что менеджеру больше не нужно иметь опыта в домене: мол хороший менеджер сегодня может управлять типографией, а завтра - автомобильным заводом... Результаты в принципе можно наблюдать за окном.
Я не знаю как у вас, но для топ менеджмента - это абсолютно верное утверждение. Принципы менеджмента слабо зависят от специфики бизнес домена, равно как и архитектурные - оно работает везде одинаково. Равно как и девелопер без знания домена может через 2 недели(при правильной организации процесса) писать вменяемый код, и так далее.
Возьмем Илона Маска - и машины делает, и соц сеть в чувство привел, и ракеты запускает, и paypal раскрутил и... что я забыл еще?
Или некоего Берию - и НКВД рулил, и созданием атомной бомбы ьлже, равно как и тяжелой промышленностью.
Да несть числа примеров топ-менеджеров, которые в совершенно разных отраслях делали успешные проекты, просто потому что... умели менеджить.
Или возьмите Торвальдса - что общего между ядром ОС и системой котроля версий?
Принципы менеджмента слабо зависят от специфики бизнес домена, равно как и архитектурные - оно работает везде одинаково.
Табуреткин вот с Минобороны не справился, хотя сильный менеджер, много полезного сделал. ИЧСХ Subject Matter Experts ему не сказали что нужен спец отдел против коррупции.
Идите, уважаемый с такими мыслями, э-э, в сад. Или в ту часть экономики которая ничего реально не производит, а потому неважно как там управлять или проектировать - общество нынче богато: паразитом больше, паразитом меньше...
Я не говорю о том, что менеджер должен периодически бегать в цех и точить детали (или лично программировать сортировку пузырьком для проекта). Однако, менеджер в реальном производстве абсолютно ущербен, если он не имеет знаний и опыта в домене. Потому что менеджмент в чистом виде - это набор лозунгов "за все хорошее, кроме всего плохого". И попытка полагаться на subject matter experts - это утопия. То есть нет - полагаться нужно. Но сначала нужно достаточно понимать предмет чтобы подобрать себе этих самых subject matter experts, а потом разводить их из клинчей, потому что инженеры хотят одно, маркетологи - другое, бухгалтера - третье, продажники - четвертое.
В мире есть успешные примеры когда переходя из одной отрасли в другую менеджмент приносил знания и ноу-хау которые позволяли сильно повысить эффективность путем кросс-опыления. Но на каждый такой пример - несть числа примеров где "эффективный менеджмент" вчера топил банковский бизнес, позавчера - автомобильный, а завтра он то же готов сделать с авиационным.
В мире есть единичные примеры людей, которые могут успешно работать в различных отраслях (причем Берия - еще и в очень специфичной советской системе управления). На каждого такого уникума - есть сотни, тысячи, десятки тысяч менеджеров которые не имея ни харизмы, ни работоспособности, ни IQ Маска берутся управлять производствами и процессами которых они не понимают.
Но бог с ними, с менеджерами - их задача по-учебнику управлять людьми и процессами. Но как вы собираетесь делать архитектуру без знания домена ? Наверное, как "архитекты из консалта": рот закрыл - рабочее место убрано...
Идите, уважаемый с такими мыслями, э-э, в сад. Или в ту часть экономики которая ничего реально не производит, а потому неважно как там управлять или проектировать - общество нынче богато: паразитом больше, паразитом меньше...
У меня и в производящих областях неплохо получается.
Но сначала нужно достаточно понимать предмет чтобы подобрать себе этих самых subject matter experts, а потом разводить их из клинчей, потому что инженеры хотят одно, маркетологи - другое, бухгалтера - третье, продажники - четвертое.
Вот вы одним абзацем написали то что должен уметь делать эффективный менеджер: уметь подбирать людейи выстраивать процессы. И в этом же абзаце написали что нифига не понимаете как это делать :))))
Вот поэтому вы и не представляете как можно работать в разных доменах. Что KPI на С-level не так уж и много. Что есть методики, в которых ответы на ваши сомнения расписаны до мелочей и так далее.
На каждого такого уникума - есть сотни, тысячи, десятки тысяч менеджеров которые не имея ни харизмы, ни работоспособности, ни IQ Маска берутся управлять производствами и процессами которых они не понимают.
На одного вменяемого сениор девелопера - сотни сеньоров индусов(не по национальности, а по уровню знаний и умений). На каждого вменяемого строителя - сотни узбеков. И так далее по списку. С чего вы решили, что в менеджменте как то иначе?
Ну реально, по сторонам посмотрите и примените критическое мышление не только к коду.
Но как вы собираетесь делать архитектуру без знания домена ?
Определив стейкхолдеров, собрав требования, верифицировав их и так далее по учебнику(одному из многих, который лично мне нравится больше других), делая корректировку на свой опыт. Понятное дело, что предусловие: ознакомиться с бизнес доменом чтобы как минимум понимать основы и термины.
Ну реально, почитайте книжки, я кейвордов тут накидал с головой.
Спасибо, с книжками у меня все хорошо. Но наглости в чужом домене заявить что "я в вашей отрасли не работал, но архитектуру вам сейчас даду" - у меня не хватает. Я очень (очень!!!) осторожно даю архитектурные советы, если не имею достаточной насмотренности. Ну то есть понятно, есть простые ситуации из серии "болит голова - выпейте аскофен". Однако же...
Если вы таки из гениев которые все могут и все умеют - я желаю вам продолжать. А если нет - тогда желаю научиться вовремя себя останавливать и осознавать что вселенная вокруг сложнее чем может казаться...
Про менеджмент скажу, что я видел 1 (прописью - один) случай когда руководство пришедшее из банка в сельхоз-холдинг его спасло, и холдинг прямо прыгнул вперед в своем развитии. И много (точно больше 10) случаев когда эффективные менеджеры ровно как вы их описываете - топили предприятия (но при этом, конечно же - выполняли все KPI и успевали уйти с премией до того как развал становился очевидным).
Но наглости в чужом домене заявить что "я в вашей отрасли не работал, но архитектуру вам сейчас даду" - у меня не хватает.
Дык вы ж в своем основном домене - в архитектуре. Если вам сказали что надо делать backend service availability в 99.99%, то во многих типвоых доменах вы будете использовать одни и тежи средства для этого - и не важно, это игрушки или медицинская система. Главное убедиться(и получить подтверждение) что стейкхолдеры хотят именнно этого, донести до них светлые мысли о том, сколько это будет стоить и перепроверить что они понимают все за и против конкретно этой цифры.
Если вы таки из гениев которые все могут и все умеют - я желаю вам продолжать. А если нет - тогда желаю научиться вовремя себя останавливать и осознавать что вселенная вокруг сложнее чем может казаться...
Формальность освобождает(с). Не надо быть гением. Надо знать и уметь существующие решения, процессы, логику, здравый смысл и опыт. Достигается упражнениями(с). Да, опыт в конкретной области - безусловный плюс, но тут начинается бюанальаня экономика: архитекторов с опытом в домене мало. они все работают и переманивание стоит много денег, без опыта - сделает решение на 10-20% дороже, если он процессы понимает, но такого проще найти на рынке. И все.
И много (точно больше 10) случаев когда эффективные менеджеры ровно как вы их описываете - топили предприятия
Опять таки, надо разбираться. Зачастую "эффекьтивных менеджеров" нанимают именно с целью потопить предприятие - а вы этого не видите. Да, есть уникумы типа Olli-Pekka Kallasvuo, который в считанные годы утопил непотопляемую нокию, но таких откровенных "гениев" тоже меньшенство. И если вы считаете, что СЕО может делать все что хочет, то очень сильно ошибаетесь, в огромном проценте новых "эффективных менеджеров" просто переигрывают в политику.
Увы, категорически нужно угадывать несуществующие требования, это одно из основных занятий архитектора. Иначе система становится невозможной к развитию.
Приходится думать и об изменении НФТ и о расширении ФТ. Да, иногда бизнес может в этом помочь, но архитектор вынужден знать предметную область не хуже бизнеса, увы.
несуществующие требования
недокументированные потребности
Потребитель нифига не знает чего он хочет до того момента пока ему это не дашь (С) Стив Джобс
Это про разные вещи.
Просто любой бизнес - это всегда про неопределенность. Никто не может гарантированно ответить ни про планируемые ФТ, ни про целевые НФТ. Но хороший архитектор, разбирающейся в предметной области - может, задавая бизнесу правильные вопросы, уточнить границы неопределенности и, исходя из этого, проектировать архитектуру.
Скажите, откуда пошло заблуждение, что "...требования определяют архитектуру"
Это пошло из разных книжек, написанных дядьками с десятками лет проверенного опыта.
Архитектура начинается тогда, когда вы строите систему под требования которые пока неизвестны, или может быть даже пока не существуют.
В этих самых книжках такие требования называются Assumptions и они обсуждаются с бизнесом наравне с остальными требованиями - внезапно у бизнеса зачастую есть понимание в каких местах будет масштабирование и "искусство" заключается в том, чтобы правильно вытрясти из бизнеса перспективы роста, отделить зерна от плевел и дальше начать техническую работу. В некоторых книжках техническую работу предлагают свести к выбору Architecture Tactics из описанного набора согласно требованиям и вуаля. Читайте книжки, меньше будет "проектировать под непонятно что" и "творчества".
Опять прибегну к аналогии: архитектура несущих стен в доме позволяет свободную планировку комнат. Гибкость в строго определенных пределах и пока эта гибкость не становится слишком дорогой.
А вот например бассейн на верхнем этаже никто делать не будет: перекрытия рухнут, архитектура такого изменения не допускает в принципе!
Надо было сделать задел? Вряд-ли. Слишком дорого и маловероятно что заказчик это оплатит
вот например бассейн на верхнем этаже никто делать не будет: перекрытия рухнут, архитектура такого изменения не допускает в принципе!
Надо было сделать задел? Вряд-ли. Слишком дорого и маловероятно что заказчик это оплатит
Вот вы, к примеру, проектируете отель и приняли решение что бассейн на последних этажах не нужен. Вы ж так и написали. Так и спроектировали и затем строители построили. А спустя некоторое время работы отеля, к вам приходит заказчик и говорит: я решил последний этаж переделать на пентхаус. Вы ж там комнаты даете без проблем переделывать? Значит мы переделакем и мне нужна какая то фигня - 4 бассейна на последнем этаже. И усе.
А причина в том, что вы положились на свой опыт. Самостоятельно сделали предположения и из них выбрали точки расширения Не уточнили с заказчиком, потребуются ли бассейны на последнем этаже - он бы вам моментально ответил "да, вероятность этого высока, я думаю над пентхаусом но надо будет посмотреть реальный спрос".
Из своего опыта - я позволю себе с вами не согласиться. Раньше в ИТ господствовала теория, что МОЖНО составить точные требования на любую систему. И если мы их не имеем - значит мы или ленивые жопы, или не нашли нужных людей и не задали им нужные вопросы.
Я имею утверждать что на сколько-нибудь сложную систему требования составить НЕЛЬЗЯ, если только вы не можете их потом прибить к стене в виде ограничений по эксплуатации (то есть ваши assumptions представляют собой самосбывающийся прогноз, а не требования в классическом понимании).
Соответственно - все идеи из книжек что бизнес способен разумно выработать assumptions под сложную систему - это сродни гениальной идее мышей привесить кошке на шею колокольчик. Да, это сработает если осуществить - и нет, это неосуществимо.
Собственно, вся идея Agile у вас идет ровно от идеи, что будущего не знает никто: ни ИТ, ни бизнес. Поэтому нужен процесс, который позволит как-то жить даже при том, что будущее вам известно только на ограниченный период, и без деталей. И задача архитектора системы - поддерживать систему в таком состоянии, чтобы она и смогла адаптироваться к неизвестным нам пока деталям будущего, и не оказалась бесконечно дорогой и долгой в постройке "здесь и сейчас". При этом, никакие рецепты и серебряные пули тут невозможны. Иначе бы не нужны были архитекторы... Архитект на то и архитект, что имеет широкий кругозор, общие знания, и НЕСЕТ ОТВЕТСТВЕННОСТЬ за принимаемые им решения, а не просто по таблице из книжки выписывает тактики после requirements engineering workshop...
будущего не знает никто: ни ИТ, ни бизнес
Ну, совсем без знаний и разумных предположений никак нельзя.
В остальном согласен.
Я имею утверждать что на сколько-нибудь сложную систему требования составить НЕЛЬЗЯ, если только вы не можете их потом прибить к стене в виде ограничений по эксплуатации (то есть ваши assumptions представляют собой самосбывающийся прогноз, а не требования в классическом понимании).
Welcome to Agile.
Хотя есть очень сложные проекты, основные требования к которым разрабатываются на ранних этапах и потом меняются относительно мало. Например проект авианосца. Или Бурдж-Халифа.
Соответственно - все идеи из книжек что бизнес способен разумно выработать assumptions под сложную систему - это сродни гениальной идее мышей привесить кошке на шею колокольчик. Да, это сработает если осуществить - и нет, это неосуществимо.
Если вы чего то не знаете и не умеете - то это не значит что остальные не знают и не умеют. Посмотрите на тот же TOGAF - специально для больших и крупных кейсов фреймворк, который любят разные ентерпрайзы. Причем там 2 уровня сертификации дял архитекторов, и один - для бизнеса. И представляете, есть бизнес который проходит эту сертификацию и успешно использует в реальных проектах на десятки-сотни человеколет.
Разумеется - если вы такой бизнес, который фактически является монополистом для домена, и будущее в домене - фактически определяется внутри бизнес-структуры - то отчего бы вам и не TOGAF?! Там есть другая особенность - пока вы сертифицируетесь по TOGAF и ведете проект как там написано, у нормального бизнеса скорее всего кончатся деньги. Поэтому шутят, что все проекты по TOGAF успешны, просто потому что о неудачных некому рассказывать...
Но если вы еще и являетесь со своим проектом частью государства, или просто too big to fall - то да, вы можете жить так, как будто знаете в деталях будущее на годы вперед. К счастью, это может себе позволить меньшинство бизнесов - иначе экономика бы рухнула под грузом неэффективных решений.
Разумеется - если вы такой бизнес, который фактически является монополистом для домена, и будущее в домене - фактически определяется внутри бизнес-структуры - то отчего бы вам и не TOGAF
А с чего вы взяли что TOGAF только у монополистов? Да, это оправдано на крупных проектах, но совершенно необязательно быть непотопляемым монополистом чтобы его примнять, и это не так дорого стоит. Относительно бюджетов корпораций, для которых его и придумали.
иначе экономика бы рухнула под грузом неэффективных решений.
Если вы не в курсе, TOGAF итеративен и срок итерации выбирается для конкретного проекта и вообще никак не указан в стандарте. Но вы продолжайте фантазировать :)
Давайте спорить о вкусе устриц с теми, кто их ел, а не со мной ? Я видел и тома требований, которые двадцать лет назад делали сертифицированные специалисты Microsoft с Navision и DAX, и (прости господи) ГОСТ ЕСПД, и текущий SAFe с эпиками в джире...
Мое впечатление - никто не будет разводить у себя TOGAF кроме ситуации когда у вас a) много денег (или даже нет - неприлично много денег!); b) Вы понимаете что рано или поздно надо что-то предъявить как результат на что вы их потратили; c) Отвечать лично никто не хочет
Что касается применимости TOGAF к любому проекту - то для меня это является доказательством, что после нескольких итераций стандарт наконец выродился до уровня библии, в которой можно найти при должном усердии и фантазии - аналогию к любой жизненной ситуации. То есть, результат работы по стандарту определяется не стандартом, а тем как его интерпретируют в конкретной ситуации. А зачем тогда городить этот стандарт ?!
Я бы настаивал на применении к стандартам принципа фальсифицируемости К.Поппера: можете ли вы назвать ограничения, при которых стандарт становится unfeasible. Если не можете - то это не наука, а религия. А о религии можно спорить бесконечно - доказано еще схоластами в средних веках...
Я бы настаивал на применении к стандартам принципа фальсифицируемости К.Поппера: можете ли вы назвать ограничения, при которых стандарт становится unfeasible.
Лихко: TOGAF применим только к Enterprise. И не применим к не Enterprise. На сертификации даже вопрос такой есть: выберите из списка к кому не применим TOGAF.
Мое впечатление - никто не будет разводить у себя TOGAF кроме ситуации когда
.... когда надо спланировать усилия сотен-тысяч человек для достижения целей в сотни-тысячи человеко/лет. Не нравится? Предложите альтернативу, как планировать работу корпорации в десятки отделов и сотни человек.
Скажите, откуда пошло заблуждение, что "...требования определяют архитектуру" ?
Видимо, оттуда же, откуда пошел термин "архитектурно значимое требование". И горе тому архитектору, у которого бизнес-аналитик пропустил такое на этапе обследования, или нутром не почуял, что оно может быть.
Пример на пальцах - вас просят спроектировать систему доставки. Вы проектируете курьеров на электровеликах, офисы, склады, расценки, экономику выводите. Но потом оказывается, что минимальный вес посылки- от 400 кг. И заказчик это "подразумевал", потому что "ну ведь это естественно?". И все.
Здравствуйте. Какие книги можете порекомендовать для начинающих архитекторов?
Ле Корбюзье ))
По решению проблем роста стоимости разработки для крупных систем:
Роберт Мартин — «Чистая архитектура» (Clean Architecture)
Вон Вернон — «Реализация предметно-ориентированного проектирования» (Implementing Domain-Driven Design)
Мартин Фаулер — «Рефакторинг. Улучшение существующего кода» (Refactoring: Improving the Design of Existing Code)
Инженерия требований
Карл Вигерс, Джой Битти — «Разработка требований к программному обеспечению» (Software Requirements)
Организация работы команды и роли архитектора
Гарт Форд, Мартин Фаулер — «Руководство по техническому лидерству» (The Tech Lead Handbook)
О том, как архитектору и техническому лидеру эффективно взаимодействовать с командой.
Вдохновение и философия
Фредерик Брукс — «Мифический человеко-месяц» (The Mythical Man-Month)
Классика управления разработкой ПО, которая остается актуальной и сегодня.
Эдсгер Дейкстра — «Программирование как искусство» (A Discipline of Programming)
Книга о философии программирования и подходах к созданию элегантных решений.
Обзор паттернов
Марк Ричардс, Нил Форд — «Основы архитектуры программного обеспечения» (Fundamentals of Software Architecture)
Рассматриваются ключевые архитектурные стили и паттерны, а также методы оценки и выбора подходящей архитектуры
Книги по высоконагруженным системам
Мартин Клеппманн — «Проектирование данных: построение надёжных, масштабируемых и поддерживаемых систем» (Designing Data-Intensive Applications)
Эта книга — мастрид для всех, кто работает с высоконагруженными системами. Она охватывает ключевые темы:
базы данных, распределённые системы, обработка данных, согласованность и отказоустойчивость.
модели данных (реляционные, графовые, документоориентированные).
логи и брокеры событий (Kafka, RabbitMQ).
алгоритмы репликации и распределённые транзакции.
Томас Эртл, Томас Фишер — «Высоконагруженные приложения» (Web Scalability for Startup Engineers)
Практическая книга, которая объясняет, как проектировать масштабируемые приложения. Особенно полезна для стартапов и тех, кто начинает работать над высоконагруженными системами.
Темы:
Масштабируемость базы данных.
Балансировка нагрузки.
Основы распределённых систем.
Без классификации
Современный подход к программной архитектуре: сложные компромиссы. Нил Форд, Марк Ричардс...
Здесь только те, что переведены на русский язык
Хорошая статья, но есть "но": в начале вы жестко критикуете микросервисы, описываете ряд проблем, а потом внезапно первым решением предлагаете микросервисы. Вам не кажется это странным?
Я не имею ввиду, что пример плох, я имею ввиду, что он не коррелирует с начальным тезисом статьи "микросервисы вам не нужны". Нужны, получается, а все описанные минусы вы получите в предложенном вами же решении)
Другой вопрос, что делить на МС надо с умом. Но про это ни слова в начальном тезисе - там только минусы микросервисов. Даже без перечисления плюсов.
Честно говоря, перечитывать и править статью уже не хочу: завтра её читать уже никто не будет. Формат у Хабра такой.
Но если я буду писать новую статью я учту что многие ставят знак равенства между "имеются (микро)сервисы" и "каждый домен в отдельном небольшом микросервисе, тысячи их!"
Микросервис это не про размер. Просто, термин так сложился, чтобы от SOA отличать
И мне не нравится выражение "делить на МС". Скорее, отделять от монолита.
Микросервис это не про размер. Просто, термин так сложился, чтобы от SOA отличать
Так в этом и вопрос. Вы сформировали микросервисную архитектуру, несмотря на то, что у вас есть некий микросервис - ядро. И тут же говорите, что микросервисы - не очень.
многие ставят знак равенства между "имеются (микро)сервисы" и "каждый домен в отдельном небольшом микросервисе, тысячи их!"
Ну так архитектура и там и там микросервисная. Что не пойму претензии. Это примерно как написать "многие ставят знак равенства между " имеется монолит на 50к строк и монолит на 1_000_000 строк".
И мне не нравится выражение "делить на МС". Скорее, отделять от монолита.
Все зависит от контекста. Мне приходилось и делить, и отделять.
как сделать балансировку нагрузки на монолит, если он не позволяет этого реализовать?
очень даже позволяет
Как в идеологии микросервисов и монолитов уживаются Data lake (Озёра данных)? Под озёрами данных подразумеваю данные, на основании которых строится аналитика
Аналитические сервисы могут (а могут и не) использовать микросервисы для получения данных, но сами они могут быть более похожи на интеграционные или аналитические платформы, чем на стандартные микросервисы и использовать специфические паттерны, например CQRS. И тут больше специфики CQRS чем микросервисов
Уровень изоляции READ UNCOMMITTED в PostgreSQL не отличается от READ COMMITTED. Другими словами - грязное чтение невозможно. Это написано в документации
PostgreSQL's Read Uncommitted mode behaves like Read Committed.
Прошу подсказать, а как будет реализовывать разработка нового функционала, если бизнес хочет использовать модную идеологию feature tag? Если включить одну фичу в одном сервисе, то это затрагивает изменения и в куче других сервисах-системах. Так? Значит, feature tag намного легче и быстрее, легитимнее использовать исключительно в монолите? Потому что можно включить эту фичу в одном месте и проконтролировать работу по всему монолиту сразу.
Второй вопрос - как сделать балансировку нагрузки на монолит, если он не позволяет этого реализовать? Грубо говоря, в монолит приходят данные и он (монолит) их обрабатывает и складывает в свою БД. Нельзя же обработать запрос "по частям", так как если поставить рядом второй монолит, то он просто перезатрёт в БД те данные, которые должен позже сохранить первый монолит. Значит, балансировку нагрузки летитимнее, проще и надёжнее делать исключительно с помощью атомарных микросервисов, у каждого из которых будет своя БД.
Как в идеологии микросервисов и монолитов уживаются Data lake (Озёра данных)? Под озёрами данных подразумеваю данные, на основании которых строится аналитика, прогнозы сбыта или делается отчётность. Если использовать микросервисы, то чтобы собрать с разрозненных БД всю цепочку информации о заказе, пункте выдачи (куда нужно привезти заказ) и информацию о платежах, скидках, потребуется опросить множество разных сервисов. Значит, для целостности данных и для их надёжной консистенции необходимо использовать монолит + одну-две базы под монолит?
Про DataLake ответил выше
Балансировка нагрузки какой? Со стороны обработки бизнес логики или СУБД?
По опыту первой затыкается СУБД, а не приложение обработки бизнес-логики. СУБД шардируем, реплицируем, данные кешируем и далее по списку в статье. Обработка бизнес-логики хорошо масштабируется вертикально, СУБД - часто нет (только если простая БД и большое количество простых запросов).
Если затык в ЦП, то читайте вторую часть моей статьи.
Про feature flag / feature toggle думаю не сильно важно монолит или нет. Все равно конфиг один и туда обращается либо монолит либо все микросервисы.
Боюсь автор не совсем прав соединяя CAP и ACID вместе, т.е. эти концепции независимы друг от друга: действительно, согласованность данных совершенно необязательно обеспечивается только ACID-совместимыми хранилищами данных. Было бы полезно рассмотреть этот вопрос с точки зрения «чем пожертвовать» - consistency vs availability с реальными примерами вроде Dynamo DB.
Еще один момент - на практике многие шаблоны вроде cqrs с event sourcing имеют высокую сложность реализации/внедрения (напр. не все инженеры понимают концепции aggregated root, vector clock, имеются сложности с версиями views и т.д.) и поэтому являются скорее нишевыми, а не общими и не могут быть рекомендованы в общем случае.
П.С. В следующих публикациях хотелось бы видеть как контейнеры могут помочь с развертыванием монолита и упростить релизы, ведь именно с всеобщей контейнеризацией в облаке пришла эпоха популярности микро-сервисов.
Архитектурные паттерны для высокой масштабируемости. Часть 1