Comments 17
Вопрос лишь в качестве разрабов. Если 99% кода на спринге превращается в спрингопомойку, в которой без поллитра не разобраться, то я понимаю, что это происходит только из-за того. что сам фреймворк мотивирует разрабов писать некачественный код.
Фреймворки бывают разные. Я видел такие, которые стимулировали в модель засовывать всю логику. Ну а спринг вот просто приучает к бардаку.
При этом все подходы при реализации МСА настолько отличаются от монолитной
Да ладно? Модульная архитектура существовала еще 40 лет назад, и с тех пор подходы не изменились. Отличаются лишь средства: каждый раз более громоздкие, ресурсо и трудозатратные и менее надежные.
Команда не обязана выносить на корпоративный уровень вопросы о языке, на котором будет написан микросервис. Одни могут выбрать Java, а другие — Python.
Ну написали они на пайтоне свой сервис и что дальше? Будут сидеть баластом верхом на своем коде? Другой модуль, который написан на Java уже не в их компетенции? О ротации ресурсов не подумали?
В МСА каждый микросервис отделен ненадежными и компроментируемыми сетевыми коммуникациями.
Это вы про Rest/HTTP? :)) Или про отсутствие ACID в микросервисной архитектуре? Для надежной сетевой коммуникации еще 20 лет назад использовались Queue Managers, кроме того наличие распределенных транзакций гарантировало отказоустойчивость системы при сбое в любом месте. И не надо ломать голову как координировать откат операции или повторное выполнение — все ACID.
Oracle, Postgres, MySQL — это все жуткое старье, которое было построено из расчета, что база данных должна крутиться на одном сервере.
Это было построено из рассчета, чтобы был ACID. Ваши NoSQL — это по большей мере хаки, которые жертвуют конситстентностью в угоду распределенности, поэтому никто не собирается отказываться от классических реляционных баз. Практически во всех проектах именно реляционные БД являются маэстро данных, а NoSQL используются по большей части как кэши и производные. Но, внезапно, архитектура хайлоад к микросервисам не имеет практически никакого отношения.
Вы ещё забыли написать про нормальный DevOps в компании — если его нет(он плохой) то тоже не стоит идти в микросервисы
Одна команда полностью должна нести ответственность за всю разработку этой бизнес-функции как на фронтенде, так и в базе данных.
Вот это вообще хорошо…
В большой компании, которая занимается разработкой распределенных систем, нет доступа «каждого встречного-поперечного» к уровню «базы данных». Потому что это — отдельная сущность, отделенная секьюрити, правилами маппинга метаданных и пр.
И в этом случае — все же данные отрабатываются через интерфейсы и эти интерфейсы пишут люди, отвечающие именно за data presentation, transformation и тому подобное. Поэтому от интеграции и коммуникации между различными командами никуда не уйти. Просто API согласовывается на первом этапе, затем для бэтта-тестов выдается макап-сервер с заглушками и две команды одновременно ведут проект, сводя его вместе в финальной точке.
О том, что команда должна отвечать за бизнес-фукнцию. Как только вы разбиваете бизнес-функцию по разным командам, все, сама бизнес-функция становится никому не интересной хренью. И уже никто за нее не отвечает. И что будет в момент сбоя справочника, всем тоже становится плевать. Просто потому что это «не наша зона ответственности». И кто в итоге становится ответственным? Да, тот самый архитектор, который за жизнь не написал ни строчки кода. Или аналитик, который не предусмотрел.
Ну а доступ к боевым данным в правильно спроектированной системе с нормальым devOps не должен быть вообще ни у кого кроме пары сисадминов. Тут даже обсуждать нечего
Сервисы — всего лишь инструментарий, который дает нам возможность гибко и быстро менять функционал, добавлять новые фичи и модифицировать старые. Но если при этом утратить понимание, как в целом должна работать система, то получается бардак.
Кстати, когда беседуешь на позицию архитекта, как раз эти вопросы «как сделать все в целом» и поднимают. И за такой ответ «отдадим все на откуп отдельной группе» — вас тупо с улыбкой попросят за дверь. Потому что есть разница между крохотными стартап-проектами и большим продом, который жрет ресурсы и любая ошибка в итоге приносит финансовые потери.
Мой опыт показывает что это не резерв, а часть команды и чем раньше это поймут, тем меньше повторных шишек набьет новая команда и больше шансов у проекта на успех.
Резерв, как правило, точно знает на чем лажанулись в старом решении и при переходе на микросервисы или просто миграции на новую архитектуру с этими ребятами нужно плотно работать и совмещать новую архитектуру с имеющимся функционалом, который как раз и знает «резерв».
Разбиваем монолит на микросервисы