Методология портирования IDM в Linux и выбор технологического стека

В предыдущей статье "Портирование IdM в Linux: 7 ключевых предпосылок" я рассказал, как наша компания пришла к решению портирования своего флагманского продукта на Linux, а сегодня на примере нашей задачи покажу, как это сделать и каких ошибок стоит избегать.

Начнем с постановки задачи. Имеется многопользовательское приложение со сложной бизнес-логикой, требованиями к производительности (до 1500 одновременно работающих пользователей), отказоустойчивости, масштабируемости и безопасности, которое, помимо пользователей, взаимодействует на прикладном уровне со смежными системами в рамках своих бизнес-процессов. Приложение ориентировано на Windows-окружение и проприетарные СУБД. Если рассматривать ИБ-системы, под такое определение, кроме IdM, могут попасть GRC, IRP, c некоторой натяжкой SIEM и множество других продуктов, не относящихся напрямую к рынку информационной безопасности.

Требуется обеспечить работоспособность этого приложения в ОС Linux и поддержку открытой СУБД.

Портировать или переписывать?

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

1. Устаревание текущего технологического стека или его неадекватность решаемой задаче в современных реалиях. Например, если продукт (являющийся многопользовательским приложением) написан на С++, можно столкнуться с множеством проблем на всех этапах его жизненного цикла. Первая – недостаток разработчиков на рынке. Современные разработчики С++ хотят работать в тех сферах, где применение их инструмента оправданно: это высокая нагрузка и системная разработка. Найти адекватного разработчика, который возьмется писать сложную бизнес-логику на C++, затруднительно. Следующая проблема – высокая стоимость добавления функций: то, что можно сделать на современном фреймворке за два дня, на устаревшем стеке можно делать две недели или два месяца, а потом еще столько же тестировать. Высокая стоимость поддержки и низкая скорость устранения дефектов – еще одно последствие, которое влечет за собой использование устаревших технологий.

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

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

Проектирование

На этапе проектирования необходимо:

1) проработать архитектуру развертывания и ответить на вопросы:

• какие модули будут в приложении;
• на какое окружение они будут ориентированы (Web-серверы, Middleware, СУБД);
• как будут взаимодействовать с внешними сервисами;

2) экспериментально подтвердить все основные архитектурные решения, направленные на поддержку нового окружения. Если меняется способ кластеризации, стоит проверить, используется ли какое-то окружение, доступное на обеих платформах, и уточнить сценарии работы с ним в новой инфраструктуре. Результатом должна стать уверенность в реализуемости выбранного технического решения.

Разработка

Сама разработка при портировании будет разделена на два больших этапа:

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

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

Положительную роль на этапе разработки может сыграть применение гибкой методологии (в первую очередь Scrum), что при наличии документации с описанием пользовательских историй и сценариев позволит достаточно точно прогнозировать трудозатраты и сроки, а также масштабировать команду разработки на этапе переноса функций.

Критерии выбора технологического стека

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

• наличие опыта у имеющихся ведущих разработчиков. Так или иначе, именно они являются основой команды и носителями знаний о реализации текущего продукта. Возможность использовать эти знания и опыт на этапе "технологической революции" продукта и сохранение текущей команды в условиях современного рынка труда стоят очень дорого;
• популярность технологии на рынке труда. Опять же, можно выбрать очень крутой стек (например, набирают популярность функциональные языки программирования), сделать красивый прототип и в итоге застрять на подборе Clojure-разработчиков;
• архитектурные стандарты потенциальных и текущих клиентов. Если мы говорим о системах, связанных с ИБ и взаимодействующих с окружением, то предоставление их по модели SaaS широкому кругу заказчиков в ближайшем будущем – несбыточная мечта разработчиков, поэтому стоит учитывать требования компаний, службы сопровождения которых будут эксплуатировать ПО. Как правило, эти требования приводят к отказу от технологий, находящихся на пике хайпа, что может не понравиться разработчикам, но с этим придется мириться;
• простота освоения. От того, как быстро используемую технологию могут освоить опытные разработчики и как быстро на нее можно натаскать начинающего, зависит успех команды и продукта в долгосрочной перспективе.

Какие "грабли" лучше обойти стороной?

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

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

Конечно, есть зависимости, реализация которых неподъемна и неадекватна на уровне прикладной системы, например СУБД или Web-сервер. Для таких случаев стоит воздержаться от использования новых, не принятых в индустрии решений. К примеру, NoSQL СУБД, возможно, даже больше подходит продукту по архитектуре, нежели традиционное решение, но она явно не будет тепло принята клиентами – крупными компаниями. Прежде чем ее применять, стоит еще раз взвесить все за и против.

Web-технологии – отдельный предмет для разговора. Тренды в них меняются настолько часто, что продукт с использованием нового крутого SPA-фреймворка еще не выпущен, а уже устарел, и фронтэндеры с рынка не хотят с ним работать. Здесь важно соблюсти разумный баланс между новизной и качеством и, возможно, отказаться от применения каких-то нововведений в принципе в пользу более простых и доступных фуллстек-разработчикам технологий. Все вышесказанное – квинтэссенция опыта, полученного в реальных условиях разработки коммерческого продукта. Надеюсь, что этот опыт поможет специалистам в принятии важных решений, убережет от ошибок или сподвигнет на реализацию казавшейся неподъемной задачи.

Александр Махновский, руководитель отдела разработки Аванпост

Системы Безопасности