Комментарии 10
IMO много воды, мало конкретики и реально интересных вещей. Не заметил упоминания темы vendor lock-in, выбора корректной базы данных исходя из load pattern приложения и многих других вещей. Приведённый пример вообще выглядит как маркетинг для клиента.
1. Сомневаюсь, что микросервисы с отдельными базами могут обеспечить доступность всего приложения. Его частей — безусловно.
2. За счёт чего в 5 раз меньше сбоев? Какого рода сбои? Почему отдельные базы сервисы и базы их решили?
3. Про экспертизу на сторона клиента читается как «когда мы меняли архитектуру, мы не нагородили там такого треша, что клиент не смог бы потом поддерживать». Ну, круто.
Хотелось бы более комплексных историй. Например, возьмём, сравнение разных message queues для конкретного юз-кейса. Поэтапно: вот была такая задача, мы решили что нужна очередь, так мы выбирали. Смотрели, скажем, на скорость, на то, есть ли у клиента опыт с этой конкретной технологией, на интеграцию технологии с нашим стеком, etc.
Пока что статья выглядит крайне слабо. Бросаем наших архитекторов на проект, они делают магию, всем хорошо.
Решением стала разработка новой микросервисной архитектуры ДБО, в которой каждый микросервис имеет отдельную базу данных, обеспечивая доступность приложения в любой момент. Результаты – в 5 раз меньше сбоев уже на старте, возможность выпускать несколько релизов каждую неделю. При этом сохранение экспертизы на своей стороне позволило банку дальше развивать продукт самостоятельно или с привлечением любого подрядчика.
1. Сомневаюсь, что микросервисы с отдельными базами могут обеспечить доступность всего приложения. Его частей — безусловно.
2. За счёт чего в 5 раз меньше сбоев? Какого рода сбои? Почему отдельные базы сервисы и базы их решили?
3. Про экспертизу на сторона клиента читается как «когда мы меняли архитектуру, мы не нагородили там такого треша, что клиент не смог бы потом поддерживать». Ну, круто.
Хотелось бы более комплексных историй. Например, возьмём, сравнение разных message queues для конкретного юз-кейса. Поэтапно: вот была такая задача, мы решили что нужна очередь, так мы выбирали. Смотрели, скажем, на скорость, на то, есть ли у клиента опыт с этой конкретной технологией, на интеграцию технологии с нашим стеком, etc.
Пока что статья выглядит крайне слабо. Бросаем наших архитекторов на проект, они делают магию, всем хорошо.
Спасибо за обратную связь.
В этой статье мы хотели поделиться опытом, почему в нашей практике необходим архитектурный комитет, рассказать о задачах и процессах, потому что не всегда роль архитектора очевидна. Нередко можно услышать мнение, что с задачами по выбору технологического решения легко справится сама команда разработки. Безусловно, команда справится, но по нашему опыту для этого понадобится значительно больше времени и ресурсов, чем если получить рекомендацию архитектора.
Мы обязательно будем делиться с вами интересными кейсами (теми, которыми можем делиться, всё-таки NDA никто не отменял))
В этой статье мы хотели поделиться опытом, почему в нашей практике необходим архитектурный комитет, рассказать о задачах и процессах, потому что не всегда роль архитектора очевидна. Нередко можно услышать мнение, что с задачами по выбору технологического решения легко справится сама команда разработки. Безусловно, команда справится, но по нашему опыту для этого понадобится значительно больше времени и ресурсов, чем если получить рекомендацию архитектора.
Мы обязательно будем делиться с вами интересными кейсами (теми, которыми можем делиться, всё-таки NDA никто не отменял))
Как суммаризация вполне интересно, только в MVP — разве внутренний контроль тоже только из 3-5 человек?
Стоит уточнить, что любой MVP делают с расчетом на полноценный продукт, да и внутренний контроль при проработке архитектуры нужен всегда: как ни крути, один человек не может знать все технологии, а вот группа специалистов – может.
Процесс внутреннего контроля нацелен на то, чтобы «объять необъятное» и найти оптимальное решение для каждого случая. С проверяющей командой в 3-5 человек можно за 30-40 минут обозначить проблемы, описать пути их решения и отправить ответственного на доработку.
Мы выбирали количество проверяющих эмпирическим путем, но наши выводы в целом соответствуют тому, что пишут об «идеальной команде» и фасилитации. Если команда больше – на принятие решения уходит много времени, если меньше – есть риск упустить отдельные важные моменты.
Процесс внутреннего контроля нацелен на то, чтобы «объять необъятное» и найти оптимальное решение для каждого случая. С проверяющей командой в 3-5 человек можно за 30-40 минут обозначить проблемы, описать пути их решения и отправить ответственного на доработку.
Мы выбирали количество проверяющих эмпирическим путем, но наши выводы в целом соответствуют тому, что пишут об «идеальной команде» и фасилитации. Если команда больше – на принятие решения уходит много времени, если меньше – есть риск упустить отдельные важные моменты.
Мне кажется архитектура — не совсем системно правильная конструкция. Т.е. все, что описано выше — опирается только на good will людей. Но у людей нет мотиваторов делать правильно/неправильно. Архитектура не несет риск от принятых ими решений. И то выражается в том, что крайне сложно архитектурным подразделениям поставить хоть какие-то цели/kpi.
Ключевое преимущество нашей компании в том, что мы имеем дело с очень разными предметными областями, подходами и даже областями. Таким образом, нам удается поддерживать интерес, а значит и мотивацию архитекторов на высоком уровне. Каждая задача на проработку архитектуры уникальна, это вызов для архитектора.
Что касается правильно/не правильно: правильно составленная архитектура учитывает все нефункциональные требования клиента и результирующий продукт удовлетворяет их. Если нефункциональные требования не выполняются — это неправильно разработанная архитектура. Как вы видите из статьи, у нас существует процесс архитектурного надзора, когда архитектор подключается к проекту и следит за реализацией.
Безусловно, иногда встречаются моменты, когда команда сталкивается со сложностями и приходится корректировать архитектуру «на ходу», но даже в таком случае архитектор, прикрепленный к проекту, участвует в выборе решения и несет за это ответственность.
Что касается правильно/не правильно: правильно составленная архитектура учитывает все нефункциональные требования клиента и результирующий продукт удовлетворяет их. Если нефункциональные требования не выполняются — это неправильно разработанная архитектура. Как вы видите из статьи, у нас существует процесс архитектурного надзора, когда архитектор подключается к проекту и следит за реализацией.
Безусловно, иногда встречаются моменты, когда команда сталкивается со сложностями и приходится корректировать архитектуру «на ходу», но даже в таком случае архитектор, прикрепленный к проекту, участвует в выборе решения и несет за это ответственность.
>> мы имеем дело с очень разными предметными областями, подходами и даже областями
И?
>> архитектура учитывает все нефункциональные требования клиента и результирующий продукт удовлетворяет их
А зачем это надо, если есть команда, которая отвечает за end-to-end продукт? Это дело команды искать правильный trade offs. И у этой команды есть все мотиваторы, так как именно им дальше поддерживать разрабатываемое решение.
И?
>> архитектура учитывает все нефункциональные требования клиента и результирующий продукт удовлетворяет их
А зачем это надо, если есть команда, которая отвечает за end-to-end продукт? Это дело команды искать правильный trade offs. И у этой команды есть все мотиваторы, так как именно им дальше поддерживать разрабатываемое решение.
Не совсем понятен ваш первый вопрос, мы постарались дать максимально подробный ответ)
Если команда одна и состоит сплошь из сеньоров, то часто так и есть, как вы описали. Но правда жизни в том, что очень сложно собрать такую команду. Если продукт успешен, всегда наступает такой момент, когда над ним трудится более пяти и даже десяти команд. Нередки случаи, когда над одним продуктом трудятся аутсорс-команды из разных компаний, которые ничего не знают о работе друг друга. Вот в такой системе архитектор незаменим.
Если команда одна и состоит сплошь из сеньоров, то часто так и есть, как вы описали. Но правда жизни в том, что очень сложно собрать такую команду. Если продукт успешен, всегда наступает такой момент, когда над ним трудится более пяти и даже десяти команд. Нередки случаи, когда над одним продуктом трудятся аутсорс-команды из разных компаний, которые ничего не знают о работе друг друга. Вот в такой системе архитектор незаменим.
Не хабровская статья, ну видно же что писалось для продажи клиенту своей экспертизы. Молодцы, подход с выделением отдельного комитета при таком-то опыте отличная и вполне логичная мера. Но в статье хотелось бы больше подробностей технических, а не рекламных, про процессы, взаимодействие, подходы и решения.
Спасибо! Мы уже опубликовали одну статью по ДБО с техническими деталями, насколько позволило NDA, с ней можно ознакомиться здесь: habr.com/ru/company/simbirsoft/blog/512310. В будущем мы будем продолжать публиковать статьи, где постараемся раскрыть кейсы, с которыми сталкиваемся
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как работают IT-архитекторы – наши примеры и задачи