Переход от монолитной архитектуры к распределенной

Последние 2 года большая часть проектов моей компании - это унаследованные системы. Я уже писал, что это за системы, какие риски возникают при работе с такими системами и каким образом проводится анализ. Интересно, что все эти системы имели монолитную архитектуру, которая была основной проблемой на пути к горизонтальному масштабированию. Для меня было вопросом как и почему получается монолитная архитектура? Как избежать такого подхода?

Описанные ниже проблемы и способы решения не являются исчерпывающим руководством по переходу к распределенной архитектуре. Скорее, это перечисление шагов и практик, которые пригодились на наших проектах и привели к нужным результатам.

IT-конференции на ближайшее время

В ближайшее время я приму участие в нескольких IT-конференциях, которые пройдут в Пензе, Москве и Челябинске. Накопились знания и опыт, которыми я хочу поделиться. Буду рад встретиться на них с вами и просто пообщаться на интересные темы. Обратите внимание, что названия и описания докладов могут немного измениться в конечных программах.

Приемочное тестирование как производственная необходимость

Все программисты — оптимисты. Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»
"Мифический человеко-месяц", Ф.Брукс

Не сосчитать сколько раз я сам и мои коллеги спотыкались о проблему, описанную Бруксом. В последнее время появилась полезная привычка остановиться и подумать над тем, что делаешь. Не как раньше кидаться на проблему с шашкой на перевес. Видимо 7 лет в разработке ПО наталкивают на новые схемы восприятия проблем. Хочу, чтобы этот пост был маячком, который заставит вас в нужный момент задуматься о том, как сделать правильно, без спешки.

Я выбрал 3 задачи из практики, с которыми скорее всего сталкивался каждый разработчик. Многие разработчики делали эти задачи и ленились, как и я, сначала придумать как измерить успешность задачи. До начала надо ответить на вопрос: "Как я могу узнать, что сделал всё правильно?". Обо всем по порядку.

Integration Patterns: Shared DB, state machine и очередь сообщений

На примере краулинга данных я предлагаю рассмотреть реализацию машины состояний с использованием двух подходов: общая БД и очередь сообщений. Оба подхода одинаково часто встречаются при реализации этой задачи, у обоих подходов есть плюсы и минусы. Думаю, будет полезно изучить их, чтобы при возникновении такой задачи делать осозданный выбор.

Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы

В предыдущей статье я описал один из вариантов, как IT-проект может катиться к провалу из-за слабых технических специалистов и неподготовленных заказчиков. Результатом этого движения будут прошедшие сроки релиза, много плохого кода, негодующие пользователи и грустные инвесторы. После осознания того, что проект идет к провалу, его отдают команде, которая берет на себя миссию по спасению.

Сейчас я хочу рассмотреть более общий вариант работы со старыми или плохоработающими системами. Хочу дать ответ на вопрос: Что делать, если вам досталась в работу legacy system? В статье я буду использовать термины legacy system (унаследованная система) и legacy code (унаследованный код).

Вообще унаследованный не значит плохой по-умолчанию. Бывают унаследованные системы с отличной архитектурой, документацией и т.п. В этой статье унаследованный будет иметь негативную окраску. Я буду говорить о проектах с проблемами в архитектуре, плохим кодом, отсутсвием тестов и документации. В этих системах бывает много чего "так исторически сложилось", "это лучше не трогать", использованы устаревшие фреймворки, подходы к разработке, языки программирования и СУБД.