Комментарии 33
Не могу согласиться или возразить.
Каждой задаче своя архитектура.
Иногда, весь бизнес компании - набор API сервисов. Тут выбор архитектуры очевиден.
Иногда, нужен софт для работы ... лесопилки. Простой, как табуретка. Выбор тоже прост.
It depends.
При выборе архитектуры нужно учитывать не только требования к готовому изделию на основе этой архитекутры, но и к процессу разработки (к размеру и составу команды, к жизненному циклу отдельных фич и изделия в целом, etc). Микросервисность, например, она не столько про то, как поделить логику на кучу инстансов, сколько про то, как развести несколько разработчиков, чтобы они не погрызлись за место в мердж-очереди :).
Да, всё зависит от всего, а статья - про некоторые суеверия и приметы, которые помогают осуществить этот выбор :).
С удовольствием прочитал.
Увы, больше тезисов, чем доводов. "Микросервисы - система сложная, энтропия, значит - ненадежная; а монолит простой, маленький, красивый"; если авторизация в Спотифае вынесена в отдельный сервис - она собой завалит всё; а если она часть монолита - то может падать безболезненно.
И ещё понравилась очевидная же вещь, что на любой конференции будут рассказывать про сложное внедрение сложной системы из микросервисов, а 10050 просто успешных запусков на простой архитектуре останутся в тени, это ж неинтересно - и вот вам ошибка выжившего.
Монолиты — всегда монорепозитории
У проектов бывают зависимости, нередко встречается что отдельные модули/компоненты лежат в разных репозиториях (или вообще в разных системах контроля версий)
Монолиты они больше про технический долг. Если писать тесты, следовать SOLID, применять code style фиксеры, использовать ci, то оно может быть нормальным довольно долго. Но со временем кодовая база растет, хотелки растут, число разрабов растет. И вот уже тесты проходят по 40 минут, каждый деплой - это тьма гит конфликтов, понять что делает система от начала и до конца уже никто в одиночку не способен - тут да приходят микросервисы. И снова можно быстро деплоиться, знать небольшой кусок архитектуры и вообще расти. За счет утилизации времени и процессорных мощностей на уровне интеграции микросервисов - но в целом альтернатива что корректно в огромный монолит новый функционал может и добавить будет нетривиально
тут да приходят микросервисы. И снова можно быстро деплоиться
И деплой одного сервиса роняет кучку зависимых.
Не роняет, если сделать всё нормально - контрактное тестирование, end-to-end и всё прочее. Всякие Нетфликсы и прочие уже собрали кучу граблей и рассказали, как надо (ну и никто не заставляет, можно сидеть на монолите долго, главное, помнить об ограничениях).
Одна из ключевых особенностей микросервисов - независимое развёртывание, т.к. микросервисы могут обновляться часто, и это не должно приводить к ошибкам.
Для этого есть QA окружение, которое нужно ронять вместо прода. Упавший сервис подскажет вам о ваших ошибках.
А просто сервисы не приходят?
Вы просто довольно большой кусок ада, который вы описали в монолите переложили на протокол микросервисов.
При этом вы подразумеваете, что "консистентность протокола" - как-нибудь сама-собой (без 40-минутных тестов, да) разрулится.
Например, при сбое одного модуля шифрования могут полностью прекратить работу другие сервисы, включая движок рекомендаций, а в монолите такого не произойдёт.
Не совсем понятно, почему сделан такой вывод. Какие-то части других сервисов, которые работают с модулем шифрования перестанут работать, но полностью-то они с чего перестанут работать? В монолите все то же самое.
booking не монолит уже много лет
уже много лет
Ключевое слово: "уже". То есть booking вполне себе нормально рос будучи монолитом. А потом, как раскрутился - нанял +100500 разрабов, чтобы разделить всё не микросервисы. Если писать сразу микросервисы, то с самого начала требовалось бы больше времени на допилку и поддержку микросервисов, что кушало бы лишние ресурсы, замедляло разработку. И не факт, что booking выжил бы, если бы всё изначально писал на микросервисах.
Я просто напомню, что между микросервисами и монолитом есть просто сервисы. Старые, простые и удобные просто сервисы. Как баланс между простотой поддержки микросервисов и простотой деплоя монолита.
где та грань, между микро- и просто сервисами?
Пример: сервис видео который позволяет загружать новое видео и получать список видео. А в микросервисах для этих двух фич 2 микросервиса.
В сервис-ориентированном приложении каждый сервис отвечает за свой домен. Например сервис доставки, сервис заказов.
В микро сервисном приложении эти домены будут разбиты ещё на несколько сервисов, которые будут выполнять отдельные операции.
Как минимум, это один из критериев.
Ну вот, а теперь нюансы. Уже сами домены могут иметь разную подчиненность - крупный домен, субдомен. Если за большой домен, содержащий много бизнес-логики, отвечают два сервиса - это уже микро? Или если архитектура приложения выглядит как множество небольших слабо связанных доменов, каждый со своим сервисом - это не микро?
За такими заявлениями явно есть свои интересы!!!)
Отрицать МСА - это как не пользоваться смартфоном, а только городским телефоном проводным.
Любые сложные системы/подходы/продукты появляются не на ровном месте, не от гения творца, а в ходе длительного развития.
Смысл MSA в том что описанные сложности решаются системно, для всего ландшафта сразу, что даёт "эффект масштаба", позволяет применять эту архитектуру. При этом, конечно, имею место предпосылки к развитию архитектуры на ландшафте.
Выбор архитектуры программного обеспечения, как формы его развития, тесно связан с реализуемой функциональностью и окружающими обстоятельствами. По мере количественного роста, с одной стороны, реализованных фичей, и, с другой стороны, количества заинтересованных сторон, в движении этих внутренних и внешних факторов, форма программного обеспечения склонна изменяться, выражаясь в новой архитектуре решения.
Задача гибкой архитектуры при этом: предвосхитить возможные изменения, производя наиболее адаптируемый к изменениям продукт, приносить заинтересованным сторонам продукт с наиболее высокими потребительскими качествами.
Воспроизведу подобный материализм развития:
Монолитное приложение - это продукт, состоящий из нескольких слоёв или уровней, которые можно выделить логически, иногда физически:
Интерфейс;
Логика приложения;
Слой доступа к данным;
База данных.
Многие продукты и процессы начинаются именно с такой формы. По мере усложнения логики, описания всё большего количества процессов, т.е. при изменении содержания, форма также изменяется.
2. Так или иначе, по мере роста и развития приложения, возникают проблемамы монолитных архитектур:
сложность системы постоянно растет;
поддерживать ее все сложнее и сложнее;
разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика - забывалась, люди уходили и приходили, а комментариев и тестов нет);
много ошибок;
мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
дорого вносить изменения;
застревание на технологиях
Однако, если приложение приносило пользу стейкхолдерам и развивалось, со временем количество пользователей/операций в системе может значительно вырасти. Появиться необходимость масштабировать систему.
3. Чтобы масштабировать систему, снизить время выхода функциональности, повысить отказоустойчивость и доступность, приходят к микросервисам и облакам.
Т.о. есть предпосылки к появлению микросервисной архитектуры: качественный рост количества фич, правок в них, потребителей.
сложность системы постоянно растет;
Тоже применимо к микросервисам - их становится много.
дорого вносить изменения
На ваш (микро)сервис авторизации подписано 100 внутренних систем. Вы уже не можете внести в неё изменения, без изменения логик 100 других систем.
Задача гибкой архитектуры при этом: предвосхитить возможные изменения, производя наиболее адаптируемый к изменениям продукт
Как-бы и да, и нет. Изначально у вас одни требования, завтра нужны другие, послезавтра требования. На этапе зарождения нового продукта практически невозможно всё предусмотреть, всё-равно будут дикие переделки и поломки всех архитектур. Рано или поздно нужно будет решать - шашечки или ехать.
Задача ИТ - соблюдать баланс между скоростью, стоимостью и качеством разработки. Я бы добавил ещё гибкостью. Этот баланс всегда, в любой момент времени разный. На старте продукта тебе нужны mvp , чтобы проверить гипотезу и жизнеспособность продукта (быстро и дёшево). Если он не выстрелил - выбрасываем, не жалко. Если выстреливает - уделяем время на доделку/переделку архитектуры. Если проект прям печатает тебе деньги, и у тебя на носу миллионы-миллиарды, значит ты спокойно можешь нанять ещё +10 разработчиков, которые сделают вторую версию очень качественного продукта хоть на микросервисах с масштабированием, итд.
Обычный ИТ-специалист не умеет сам соблюдать такой баланс. Дай волю - он закроется на 10 лет, бесконечно вылизывать свой код. Но бизнес скорее всего разорится раньше, и его творение просто никогда не увидит свет. Поэтому ему в пару ставят продакт-менеджера, который тянет другой конец одеяла на себя, торопя в разработках, и так они пытаются нащупать этот баланс.
Вы воспроизвели мой ответ, своими словами.
Ещё раз, повторю свою мысль, в доказательство непротиворечивости: форма ПО соответствует материальным условиям развития. В какой-то момент, от вашего продукта может потребоваться рост, с разделением монолита, чтобы соответствовать каким-то метрикам.
Интересная мысль про баланс. ИМХО, лиды/архитекторы/owner'ы именно для соблюдения баланса и нужны, именно в движении противоречивых интересов рождаются, выраствют, умирают все продукты)
"Отрицать МСА - это как не пользоваться смартфоном, а только городским телефоном проводным." не могу согласиться с таким сравнением. Смартфон - это монолит. А вот если у вас будет экран в одной руке, клавиатура - в другой, а приёмопередатчик где-то в кармане, и т.д. - это микросервисы. В некоторых случаях это оправдано, в некоторых - нет. Если проводить аналогии, подобные вашей, то микросервисы - это ПДУ от телевизора и сам телевизор. Каждый отвечает за свою задачу, а в итоге пользователеть получает желаемую картинку на экране. Для каждой задачи своё решение.
Уважаемый собеседник, боюсь вы не правильно поняли мою аналогию. Она не в делимости на части, а в сложности применяемого решения. Внешне для пользователя и то и другое будет схоже. Но для производства смартфонов нужна очень сложная производственная база, цепочки поставок, много версий нужно выпустить. Это уже не говоря о инфраструктуре телекомов.
Позволю себе больше, определю эту статью
как агитацию простых решений, которые не требуют больших затрат.
как пропаганду сегрегации ролей в производственном процессе.
И смею думать, что авторов интересовал в этой теме только хайп. Сама же пропаганда коренится в столкновении интересов менеджера и инженера. В одном месте это формулируется как излишняя сложность технического решения, в другом как низкая квалификация программистов и инженеров, в третьем апеллируют к абсолютам. По факту, менеджер всегда преследует задачу оптимальной утилизации ресурсов. И эта статья сильно подыгрывает подобной позиции.
Часто вместо микросервисной архитектурой строят расколотый монолит. Вроде как код растащили по разным репозиторям и API сделали, но при этом осталась жесткая зависимость между компонентам - один упавший сервис каскадом тащит за собой остальные, да и релизы надо делать совместные.
В статье правильно написано - нормальную микросервисную архитектуру достаточно сложно реализовать, например обеспечить одновременную поддержку нескольких версий API между сервисами.
При проведении собеседований у меня один из любимых вопросов - назовите плюсы монолита и минусы микросервисов) Очень мало кандидатов могут вдумчиво ответить на этот вопрос)
Статья как бальзам на душу. Примеров разумной микросервисной архитектуру очень мало.
Если взять аналогию со строительством, то можно заметить, что на лицо подмена (скорее всего не осознаная) понятий архитектуры, стиля, материала и назначения. Строя дом вы придёте к архитектору и не может быть, что диалог у вас будет из одного слова. Типа Баухаус или Брутализм. Скорее всего у вас будет что то типа: "классический дачный домик из дерева", но и этого мало. Вы начнёте обсуждать избушку ли вам строить или скандинавский вариант, и как вы планируете его использовать. Но почему то в ИТ все считают, что можно просто сказать "микросервисы" и это будет ответ на главный вопрос жизни, вселенной и всего такого.
Хорошие монолиты. Простая архитектура лучше всего