Технический долг для масштабирования: как избежать банкротства

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

Между прототипом и готовым к производству программным обеспечением есть короткие пути, которые должны быть краткосрочными, но имеют очень длительный период окупаемости. Разработка на начальных этапах будет сосредоточена на быстром прототипировании и прямой функциональности, а не на таких абстрактных вопросах, как модульность или расширяемость. Этот метод абсолютно рационален, когда основной целью является подтверждение гипотез, а также захват рыночных возможностей до входа конкурентов. Но такие мелкие победы могут привести к большим проблемам. Монолитные архитектуры, которые казались классными для небольших групп, становятся проблемой, когда организация растет. Схемы баз данных, которые были идеальными вначале, сложно изменить, чтобы поддержать новые функции. Сотни систем аутентификации пользователей не справляются с тысячами. Шаблоны интеграции, которые были эффективны с несколькими сторонними сервисами, становятся неуправляемыми из-за масштабов экосистемы.

Неэффективный API может без проблем справляться с текущей нагрузкой трафика, но потерпит крах, когда нагрузка удвоится. Тесно связанная кодовая база может сначала позволить быстро разрабатывать функции, но параллельная разработка может стать еще более сложной с увеличением размера команды. Компании часто неправильно понимают эти симптомы как временные проблемы роста, которые не являются системными и не требуют архитектурных исправлений. Руководство может думать, что больше инженеров ускорит процесс разработки, но потом поймет, что накладные расходы на координацию и конфликты кода на самом деле замедляют разработку. Проблемы, связанные с производительностью, решаются путем увеличения мощности серверов, а не путем повышения базовой эффективности. Проблемы безопасности решаются с помощью точечного решения, а не системного обзора сайта. Экономические последствия и масштабы гораздо шире, чем просто производительность в инженерии. Это влияет на опыт клиентов, потому что системы становятся менее стабильными и отзывчивыми. Когда платформа не может удовлетворить потребности потенциальных корпоративных клиентов, теряются возможности для продаж. Конкурентные преимущества уменьшаются, потому что функции развиваются медленно. Это усложняет процесс найма, потому что инженеры не хотят работать в организациях с техническими проблемами.

Создание модульной архитектуры

Чтобы эффективно разрабатывать архитектуру, нужно знать принципы, которые помогают создавать хороший дизайн, а также практические ограничения, которые нужно учитывать при принятии решения о внедрении того или иного решения. Основа начинается с модульности и разделения задач. Разработанные системы структурируют функциональность в виде отдельных элементов, определенных интерфейсов и обязанностей. Такая стратегия позволяет командам создавать и вносить изменения или заменять отдельные части без нарушения работы всей системы. Сервис-ориентированные архитектуры — это хороший пример этой концепции в целом. Вместо того чтобы разрабатывать монолитные приложения со всеми функциями, использующие одну и ту же кодовую базу и развертываемые одинаковым образом, организации могут разбить системы на специализированные сервисы, которые взаимодействуют через единые API. Сервисы независимы и могут разрабатываться, тестироваться и развертываться разными командами одновременно, не мешая друг другу.

Хитрость в том, чтобы определить четкие контракты между разными частями системы и не делать их слишком тесно связанными, чтобы изменения не распространялись по всему коду.

Что нужно помнить про архитектуру данных

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

• Выбирайте базы данных документов вместо реляционных баз данных, если это вам удобнее
• Использовать стратегию управления версиями данных
• Создание API, которые скрывают реализации базового хранилища

Баланс между настоящими и будущими потребностями

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

Наблюдаемость и безопасность

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

Техническое принятие решений

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

• Разработка процедур архитектурного обзора по основным техническим решениям
• Документируйте компромиссы
• Часто оценивайте технический долг, который возник из-за бизнес-приоритетов

Тестирование и интеграция

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

Проверка кода и обмен знаниями

При проверке кода нужно смотреть и на архитектурные последствия, и на то, как он работает. Если проверять только то, как он работает прямо сейчас, то не получится найти и исправить структурные проблемы, пока они не стали серьезными. Чтобы повысить качество решений в компании, нужно научить инженеров находить и обсуждать архитектурные компромиссы.

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

Регулярные обзоры архитектуры

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

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