Мир, Труд, Legacy!

Сегодня хотел бы поднять тему Legacy. Но не про то Legacy, которое человек получает по наследству от богатого родственника 😃, а про другое, с которым мы часто сталкиваемся в ИТ, и которое имеет негативную коннотацию.

Всё началось с того, что я наткнулся на текст Patterns of Legacy Displacement. С одной стороны, это статья, в которой в общих чертах и с разных сторон рассматриваются проблемы модернизации Legacy-решений. С другой стороны - это подборка вполне конкретных шаблонов модернизации, ссылки на описание которых приводятся по мере повествования. Авторы заверяют, что будут развивать и поддерживать этот материал в актуальном состоянии, поэтому ссылки на некоторые шаблоны, к сожалению, отсутствуют. В целом, рекомендую для ознакомления или добавления в закладки.

Между тем, хотелось бы определиться, что такое Legacy. Сталкиваясь с этим, в зависимости от ситуации могут возникать двоякие ощущения: страх или жажда всё переписать и сделать нечто совершенное. Первое, как правило, связано с боязнью нарушить работоспособность существующего решения; второе — с моральной усталостью его поддержки. И если нам предоставляется шанс пойти по пути модернизации, то вспомните, с каким опьяняющим азартом мы начинаем махать шашкой и развешивать ярлыки на авторов модернизируемого решения. Кого интересует предыстория?! Нам дали шанс уничтожить ненавистного врага! Знакомо? 😃 Получилось добиться желаемого успеха и прийти к желаемому совершенству? 😉

Прежде чем начинать модернизацию, нужно сделать шаг назад и ответить на вопрос, почему Legacy стал Legacy. Накопился слишком большой технический долг? Или дело в (устаревшем) технологическом стеке? Или просто не осталось специалистов, у которых есть нужные компетенции для поддержки? Конечно, это далеко не полный перечень вопросов, но их цель, я думаю, ясна: не повторить прошлый опыт.

🗂Посмею сделать небольшую ремарку. Я не могу согласиться с тем, что (устаревший) технологический стек может являться основной причиной получения метки "Legacy". Только если это приводит к серьезным временным/финансовым издержкам/рискам или обусловлено внешним фактором (например, импортозамещением). В остальных случаях это не Legacy. Даже на самой замшелой технологии и древнем языке код может быть написан аккуратно, выглядеть структурно и понятно и не иметь значимых технических долгов. Называя такой проект Legacy, мы просто выражаем своё нежелание работать с ним или указываем на трудность найма специалистов для его поддержки. Проект становится Legacy, когда он серьезно затрудняет развитие бизнеса. Только это может являться поводом внесения значительных изменений, модернизации или замены существующего решения.

🟢Апеллируя к своему большому опыту, авторы вышеуказанного текста заключают, что корень проблемы появления Legacy находится всё-таки на уровне культуры организации, её структуры и принятых методов. Таким образом указывают на прямую связь с законом Конвея.

🟢Вместе с этим отмечается, что нельзя рассматривать инициативу по замене Legacy в отрыве от текущих бизнес-целей. Иначе говоря, если вести разработку как обычно (Business As Usual), а замену Legacy рассматривать как параллельную инициативу без поправок на реалии, ничего не выйдет. В лучшем случае получится то же самое, в худшем — "новая версия", которая слишком сильно или ненужным образом будет отличаться от реалий и желаемого результата. Выражаясь техническим языком, не нужно делать долгоживущие fork-и проекта, они будут слишком сильно оторваны от целей.

🟢Авторы также указали на острую необходимость декомпозиции. Большой и сложный проект крайне трудно заменить целиком. Любые попытки сделать это часто обречены на полный провал либо на появление еще одной, но новой неуклюжей системы, которая будет жить вечно рядом со старой. Чаще всего можно наблюдать второй вариант, так как бизнес всё равно будет требовать результатов и вывода новой разработки в промышленную эксплуатацию.

〰️〰️
Всех поздравляю с Майскими праздниками, желаю прорывных успехов и грандиозных побед!🚀 А в комментариях призываю делиться своим опытом работы с Legacy.😉

Неизбежность эволюции (1/2)

Многие сходятся в том, что, начиная новый проект, нужно начать с чего-то простого, чтобы как можно быстрей сделать MVP и получить первую обратную связь. Вполне разумный и рациональный подход. Действительно, зачем собирать космический корабль, который, возможно, никогда не выйдет за пределы ангара или на содержание которого нет ни денег, ни людей. 🚀 Тем не менее в душе каждого творца всегда искрится надежда создать нечто уникальное и неповторимое. Почему бы не поддаться этому порыву в новом/текущем проекте?! 😃 Как понять, что пришло время для особенных решений?!

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

🗂 A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. — John Gall, Systemantics (1975)

Позволю себе внести важные уточнения.

🔘 Простота системы означает не примитивизм, а наличие ограниченного числа взаимодействующих между собой элементов с понятными и прослеживаемыми связями между ними.
🟢 Сложность системы означает не трудность организации самой системы, а её зрелость, точность модели предметной области.

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

Гибкость архитектуры — понятие ортогональное к простоте и сложности, означающее степень готовности системы к изменениям. Простая не значит гибкая, обратное также справедливо. Гибкость становится возможной, в том числе, если система не зависит от специфических возможностей составляющих её элементов или особенностей взаимодействия между ними. Например, гибкость снижается, если появляется зависимость от уникальных особенностей определенной базы данных или зависимость этой базы данных от определённого окружения. Между тем, слишком гибкое решение — бесформенное, рыхлое, оно не может задавать структуру, следовательно, вектор развития, обрекая весь проект на провал.

➡️ Подобные умозаключения не являются каким-то открытием, об этом пишут и говорят многие. Я лишь хочу подчеркнуть, что для архитектора важно не только принять обоснованное решение, но и определить пути его дальнейшего развития. Нужно мыслить на несколько ходов вперед, как можно дольше сохраняя простоту и гибкость решения. Пожалуй, это лучший ответ на исходный вопрос о своевременности и возможности тех или иных решений. Каждый следующий шаг должен приближать нас к цели, формировать базу для следующего шага и уточнять направление развития. Если это так, то действуйте! 🚀

#arch #view

⬇️⬇️⬇️⬇️⬇️

⬆️⬆️⬆️⬆️⬆️

Неизбежность эволюции (2/2)

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

🔴 Выбор технологии, принимая во внимание только её популярность. ("Так принято в лучших домах!", "Kafka справится с любой задачей" и т.п.)
🔴 Немедленные действия, обоснованные амбициями или ощущениями. ("Некогда думать — надо действовать!", "Мир сам себя не захватит!", "Это слишком дорого, но я не скажу, насколько" и т.п.)
🔴 Неоправданное и/или преждевременное усложнение. ("У меня нет задач, нужно придумать что-то интересненькое", "У меня скучные задачи, нужно добавить драйва", "Я предусмотрел обработчик на случай вторжения инопланетян!" и т.п.)
🔴 Неоправданное расширение технологического стека. ("CV-Driving Development", "Решил попробовать", "Мне так удобней" и т.п.)

Принимая неизбежность эволюционного развития систем, важность гибкости архитектуры на ранних стадиях, а также необходимость постоянной корректировки направления развития (стратегии), остаётся вопрос, почему кто-то начинает не с простых вещей. Почему кто-то сразу начинает с гексагональных архитектур или микросервисов? 😃

Согласен, что иногда это является преждевременным усложнением. Однако, если архитектор или разработчик достаточно опытный, он может позволить себе "срезать углы", действуя на опережение. В данном случае он должен осознавать и указывать на все риски подобных действий, в том числе понимать, кто будет поддерживать и сопровождать такой продукт. Тут можно вернуться к метафоре с "космическим кораблём": нужен ли он на старте, есть ли у вас подходящая команда, инфраструктура, ресурсы? 🤔

〰️〰️〰️

⁉️ Я постарался описать тактику принятия решений, которой стараюсь пользоваться в работе. К сожалению, иногда эмоции берут верх, и приходится себя останавливать. Было бы интересно узнать, как вы справляетесь с соблазнами несвоевременного применения понравившегося решения.

P.s. На самом деле я хотел написать пост про распределенные (реляционные) хранилища, но меня понесло немного в другую сторону, и я не стал сопротивляться этому потоку. Надеюсь, что не напрасно. Будем считать данный пост вступлением к следующему. 😃

#arch #view

Распределенные SQL-базы

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

В том числе по этой причине многие основательно подходят к выбору БД: фундамент должен быть прочным, его должно хватить надолго, он должен выдерживать нагрузку с хорошим запасом. Поскольку кривая эволюции может увести далеко от начальных архитектурных предположений, большинство делают выбор в пользу универсального и проверенного решения — реляционного хранилища. Чаще всего это монолитные реляционные базы вроде PostgreSQL или MySQL/MariaDB. Откровенно говоря, я не поддерживаю идею выбора хранилища на основе принципа "проверенное — значит подходящее". Выбор следует делать осознанно, учитывая требования к системе, возможности хранилища, результаты прикладных экспериментов и тестов.

Ясно, что принести на сопровождение подходящее, но никому неизвестное решение — это зачастую совсем не вариант, особенно на ранних этапах развития продукта. Но это один из возможных вариантов, который нужно отвергать обоснованно. Возможно, что миграция данных в будущем обойдётся дороже, чем освоение нового инструмента на старте.

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

О каких усложнениях идет речь? Основные усилия направлены на обеспечение согласованности данных (saga, 2PC, inbox/outbox patterns), в том числе по той причине, что часть данных переносят в отдельное (NoSQL) хранилище и/или микросервис. В таких случаях инфраструктурного кода становится на порядок больше кода с бизнес-логикой. Возрастает вероятность возникновения ошибок, порог входа в проект и требования к специалистам для его поддержания и развития.

Чтобы однажды не дойти до предела возможностей БД и не начать городить огород раньше времени, лучше воспользоваться следующим чек-листом:

🔲 Предвидится большой размер базы данных.
🔲 Необходимо горизонтальное масштабирование.
🔲 Необходимы высокие гарантии отказоустойчивости.
🔲 Необходимы гарантии высокой доступности.

Если хотя бы на один вопрос ответ 👍, то следует смотреть в сторону распределенных (SQL-) баз данных. С одной стороны, это гораздо более сложное решение, чем какой-нибудь легковесный монолитный PostgreSQL, 🆚 с другой стороны, это позволит существенно упростить код приложения, оставив в нём место только для бизнес-логики. Все вопросы согласованности делегируются хранилищу, и кажется, что это очень хорошо и правильно. Может, действительно, не стоит изобретать велосипед?! 🚲

В качестве распределенных SQL-баз мне показались интересными следующие решения:

🔵 YDB
🔵 CockroachDB
🔵 YugabyteDB
🔵 TiDB

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

#db #arch

Безопасное исполнение ненадёжного кода

Дал слово — держи! 💪 Так я и сделал, оформив тезисы своего доклада в виде статьи на Дзен. 🚀 Да-да, после "марафона" я решил не останавливаться и еще немного прокатиться на волне вдохновения. 🏄🏻‍♂️ Чуть позже обещают выложить видео, а пока желаю приятного чтения всем интересующимся. 😉

#conf #dev #arch #untrusted_code

Борьба с техническим долгом и Legacy

Если 10-15 лет назад рассказывали, что такое технический долг, почему он возникает и как может повлиять на дальнейшую разработку, то сейчас начали рассказывать, как с ним бороться. Очевидно, за прошедшие годы многие сильно задолжали. 😂

Судите сами, на прошедшей конференции TechLeadConf 2025 около 30% докладов была посвящена борьбе с техническим долгом и замене Legacy. ⚔️⚔️

Каждого волнует вопрос, как именно бороться с техдолгом, как его идентифицировать, оценить критичность, существующие и будущие издержки и риски, разработать план по его устранению, устранить и, наконец, убедиться в том, что проблема действительно ушла. У каждого своя тактика и стратегия, так как многое зависит от масштаба компании и её возможностей, но, к счастью, многие сходятся во мнении. Я бы сказал, что у более крупных компаний методы борьбы с техдолгом более системны и основательны.

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

#conf #arch #dev #tip

Ускорение интеграционных тестов

Недавно я узнал об инструменте Zonky, который на одном из проектов позволил ускорить выполнение интеграционных тестов в среднем в 3.5-4 раза. 🚀 Делать практически ничего не пришлось: подключил зависимость и добавил аннотацию.

Об инструменте

Если вы испытываете проблемы с долгим выполнением интеграционных тестов, пишете на Java/Kotlin, используете Spring (не обязательно) и Testcontainers, то сможете за пару часов повторить мой опыт и проверить эффективность использования Zonky в своём проекте.

🗂 У меня есть страсть — узнавать происхождение необычных слов. Оказалось, что зонки — искусственно созданные виды непарнокопытных. Гибрид зебры и осла, выведенный в XIX веке. На вид они мультяшно-миловидные, но свободолюбивые и упрямые. Впрочем, это уже совсем другая история. 😃

Перед запуском интеграционных тестов Zonky создаёт и настраивает указанную embedded-базу данных и регистрирует её в качестве источника. Заявлена поддержка PostgreSQL, MSSQL, MySQL, MariaDB, H2, HSQLDB и Derby. Библиотека интегрирована со Spring, генераторами схемы данных Liquibase и Flyway, может работать без Docker (проверено для PostgreSQL). В основе реализации два ключевых момента: использование embedded-базы данных и оптимизация процессов её инициализации и восстановления. Для базового использования достаточно пометить тестовый класс аннотацией @AutoConfigureEmbeddedDatabase(provider = ZONKY).

О тестировании

Долгое прохождение тестов — явный признак нарушения пирамиды тестирования. 😏 Проект, где я ускорил тесты, имеет очень мало модульных и очень много интеграционных тестов. Это и стало причиной получения столь значительного эффекта.

Если с пирамидой тестирования всё нормально, то инструменты, подобные Zonky, скорей всего, не принесут желаемого ускорения. В этом случае лучше продолжать использовать популярный и проверенный временем Testcontainers. Если же тяжёлых интеграционных тестов с участием баз данных очень много, то Zonky поможет сэкономить время. Однако последнее я бы воспринимал как инвестицию: сэкономленное время лучше потратить на наведение порядка и выравнивание пирамиды тестирования. 😉

#dev #db #tip

📌 Подборка постов

Для удобства навигации по каналу собрал подборку постов. 🚀

Потоки данных
🟡Ускорение потоков данных
🟡Log-based- и Queue-based-брокеры сообщений
🟡Фэйл с RabbitMQ и Kubernetes API
🟡Гарантированная отправка сообщений

Базы данных
🟡Что не так с PostgreSQL
🟡ACID, AID или AD
🟡Calvin Protocol для распределенных транзакций
🟡Проблемы изоляции транзакций
🟡Конкурентный доступ к данным
🟡Слабая или сильная изоляция транзакций
🟡Распределенные SQL-базы
🟡Выбор UUID для первичного ключа таблицы
🟡Lamport Timestamp: генерация целочисленного идентификатора в распределённой БД без ACID-транзакций
🟡Snowflake ID: генерация целочисленного идентификатора в распределённой системе
🟡Интеграция и внешние идентификаторы
🟡Моделирование данных / Структуризация
🟡Моделирование данных / Переиспользование
🟡Моделирование данных / Производительность
🟡Решардирование данных через промежуточный топик
🟡Вспомогательная таблица для ускорения выборки
🟡Меры предосторожности при работе с РСУБД

Архитектура и разработка
🟡Надёжность, прочность, устойчивость
🟡Принцип прочности
🟡Структура, высеченная в камне
🟡Чего не написано - того нет
🟡Способы борьбы с Legacy-кодом
🟡Борьба с техническим долгом и Legacy
🟡Неизбежность эволюции программных систем
🟡Безопасное исполнение ненадёжного кода
🟡Как еще определять границы микросервисов
🟡Оптимистичная архитектура
🟡Доступность
🟡Волшебная кнопка
🟡Второй закон архитектуры
🟡Базовые элементы архитектурного фреймворка
🟡Декомпозиция в стиле квантовой архитектуры
🟡Порочные связи между компонентами
🟡9 архитектурных заблуждений о распределённых системах
🟡Первичный анализ задачи поиска медицинских документов
🟡Плохо знаешь данные - рискуешь здоровьем
🟡Архитектура лечит причину
🟡Domain Vision Statement

Системное программирование
🟡Борьба с зомби-процессами
🟡Устранение уязвимостей в коде
🟡Throttling == бесполезная трата CPU
🟡OOM/Killer к нам приходит

Алгоритмы и шаблоны
🟡Удаление конфиденциальных данных
🟡Миграция данных и HLL

Безопасность
🟡DevSecOps & Shift-Left
🟡DevSecOps - build phase
🟡Контракт между приложением и окружением

📱 Мои статьи и лонгриды доступны на тут ⬅️

#pin

Голосование за канал

Я уже говорил, что участвую в конкурсе авторских каналов. В минувшее воскресенье закончился приём заявок и началось голосование. 🏆

Прежде всего, предлагаю пройтись по списку номинаций и выбрать для себя что-то интересненькое. 😉 Если после этого у вас останутся силы, проголосуйте за своих фаворитов, они этого ждут. 😃 Однако есть нюанс: чтобы исключить вероятность накрутки, голосовать могут только подписчики @tg_contest_main. 🙈

Если что, мой канал находится в номинации "Разработка и управление командой" — список каналов и форма для голосования тут. 😏

Помимо этого, участники нашей номинации сформировали подборку каналов и оформили её в виде Telegram-папки. Открывайте, смотрите, выбирайте, что по душе. 🚀

Стала доступна 📱 видеозапись моего доклада "Безопасное исполнение ненадежного кода" с TechLead Conf X 2025. Также напомню, что ранее я выкладывал текстовый вариант и презентацию. 😉

📱 YouTube
📱 VK Video

Для тех, кто не в курсе истории появления и развития содержательной части доклада, можно воспользоваться хэш-кодом #untrusted_code. Всё началось с обещания рассказать, как справляться с потенциально вредоносным кодом. Чтобы не делать доклад слишком прикладным и скучным, привязанным к какому-то конкретному домену, я обобщил подход и выделил ключевые, повторно используемые приёмы.

🗂О чём доклад? Даю определение ненадёжного кода и рассматриваю различные способы его исполнения. Рассказываю про уровни изоляции кода, методы ограничения ресурсов процесса операционной системы, проблемы жёсткого лимитирования и техники их устранения. Сравниваю два архитектурных подхода управления песочницами. Затрагиваю вопросы использования инструментов контейнеризации.

〰️〰️〰️
Я рад, что в канале стало больше людей. Ваше внимание вдохновляет меня. Спасибо! ❤️

#conf #untrusted_code