Журнал "Системы Безопасности" № 6‘2018

www.secuteck.ru декабрь 2018 – январь 2019 УПРАВЛЕНИЕИДЕНТИФИКАЦИЕЙ С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 77 dormakaba – системы контроля доступа дня, на устаревшем стеке можно делать две недели или два месяца, а потом еще столько же тестировать. Высокая стоимость поддержки и низкая скорость устранения дефектов – еще одно последствие, которое влечет за собой использование устаревших технологий. 2. Проблемы с высокоуровневой архитектурой и большой технический долг. Масштабные изменения, сопутствующие портированию, могут быть удачным поводом для пересмотра архитектуры, а в случае необходимости гло- бальных изменений пересмотр стека основных технологий может значительно ускорить выпол- нение задачи и заложить хорошую базу для развития продукта. Вне зависимости от принятого решения относи- тельно изменения стека при любых масштабных нефункциональных изменениях продукта под- ход к выполнению задачи будет примерно оди- наков. Проектирование На этапе проектирования необходимо: 1) проработать архитектуру развертывания и ответить на вопросы: l какие модули будут в приложении; l на какое окружение они будут ориентирова- ны (Web-серверы, Middleware, СУБД); l как будут взаимодействовать с внешними сервисами; 2) экспериментально подтвердить все основные архитектурные решения, направленные на под- держку нового окружения. Если меняется спо- соб кластеризации, стоит проверить, использу- ется ли какое-то окружение, доступное на обеих платформах, и уточнить сценарии работы с ним в новой инфраструктуре. Результатом должна стать уверенность в реализуемости выбранного технического решения. Разработка Сама разработка при портировании будет раз- делена на два больших этапа: 1) поддержка нового окружения, результатом которого должно стать появление запускаю- щихся и взаимодействующих между собой ком- понентов приложения; 2) перенос функций в новое решение. Первый этап ввиду новизны для команды раз- работки и наличия рисков (особенно если был пропущен или недостаточно тщательно выпол- нен второй этап проектирования) плохо прогно- зируем по срокам и должен выполняться отно- сительно небольшим количеством ведущих раз- работчиков. Это позволит заложить правильную основу и избежать множества "грабель", на которые команда сможет наступить в будущем. Если при портировании не происходит полная замена платформы, то перенос функций прой- дет проще, поскольку как минимум часть при- ложения сохранит свой первоначальный вид и поведение, на которое можно опираться при тестировании. Если же производится замена платформы, то неплохим подспорьем может стать документация, описывающая пользова- тельские сценарии. Не имея ее, крайне сложно сохранить все функции и особенности поведе- ния, необходимые пользователям. Положительную роль на этапе разработки может сыграть применение гибкой методоло- гии (в первую очередь Scrum), что при наличии документации с описанием пользовательских историй и сценариев позволит достаточно точно прогнозировать трудозатраты и сроки, а также масштабировать команду разработки на этапе переноса функций. Критерии выбора технологического стека В случае если принято решение о полной заме- не технологического стека, выбор, доступный в современном мире разработки, может ввести в заблуждение даже опытных проектировщиков, поработавших какое-то время в определенной технологической нише. Помимо функциональ- ных требований, стабильности и надежности выбираемого инструмента, стоит учитывать сле- дующие моменты: l наличие опыта у имеющихся ведущих разра- ботчиков. Так или иначе, именно они являют- ся основой команды и носителями знаний о реализации текущего продукта. Возможность использовать эти знания и опыт на этапе "тех- нологической революции" продукта и сохра- нение текущей команды в условиях совре- менного рынка труда стоят очень дорого; l популярность технологии на рынке труда. Опять же, можно выбрать очень крутой стек (например, набирают популярность функцио- нальные языки программирования), сделать красивый прототип и в итоге застрять на под- боре Clojure-разработчиков; l архитектурные стандарты потенциальных и текущих клиентов. Если мы говорим о систе- мах, связанных с ИБ и взаимодействующих с окружением, то предоставление их по модели SaaS широкому кругу заказчиков в ближай- шем будущем – несбыточная мечта разработ- чиков, поэтому стоит учитывать требования компаний, службы сопровождения которых будут эксплуатировать ПО. Как правило, эти требования приводят к отказу от технологий, находящихся на пике хайпа, что может не понравиться разработчикам, но с этим при- дется мириться; l простота освоения. От того, как быстро исполь- зуемую технологию могут освоить опытные разработчики и как быстро на нее можно натаскать начинающего, зависит успех коман- ды и продукта в долгосрочной перспективе. Какие "грабли" лучше обойти стороной? От рекомендаций конкретных технологий я воз- держусь, но постараюсь перечислить решения, от которых при разработке коммерческого про- дукта по возможности стоит воздержаться. Первое: внешние зависимости необходимо све- сти к минимуму. Под внешними я понимаю любые сервисы, которые разворачиваются и сопровождаются отдельно от ПО. Например, если нет веских оснований использовать Apac- heKafka и есть возможность реализовать необходимые кейсы, решаемые им, на уровне своего ПО или с помощью встраиваемых зави- симостей, стоит отдать предпочтение встроен- ной реализации. Конечно, есть зависимости, реализация которых неподъемна и неадекватна на уровне приклад- ной системы, например СУБД или Web-сервер. Для таких случаев стоит воздержаться от использования новых, не принятых в индустрии решений. К примеру, NoSQL СУБД, возможно, даже больше подходит продукту по архитекту- ре, нежели традиционное решение, но она явно не будет тепло принята клиентами – крупными компаниями. Прежде чем ее применять, стоит еще раз взвесить все за и против. Web-технологии – отдельный предмет для раз- говора. Тренды в них меняются настолько часто, что продукт с использованием нового крутого SPA-фреймворка еще не выпущен, а уже уста- рел, и фронтэндеры с рынка не хотят с ним работать. Здесь важно соблюсти разумный баланс между новизной и качеством и, возмож- но, отказаться от применения каких-то нововве- дений в принципе в пользу более простых и доступных фуллстек-разработчикам технологий. Все вышесказанное – квинтэссенция опыта, полученного в реальных условиях разработки коммерческого продукта. Надеюсь, что этот опыт поможет специалистам в принятии важ- ных решений, убережет от ошибок или спо- двигнет на реализацию казавшейся неподъем- ной задачи. n Методология портирования и выбор технологического стека В предыдущей статье "Портирование IdM в Linux: 7 ключевых предпосылок" (журнал "Системы безопасности" № 5/2018) я рассказал, как наша компания пришла к реше- нию портирования своего флагманского продукта на Linux, а сегодня на примере нашей задачи покажу, как это сделать и каких ошибок стоит избегать Ваше мнение и вопросы по статье направляйте на ss @groteck.ru