В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций
Начнем с постановки задачи. Имеется многопользовательское приложение со сложной бизнес-логикой, требованиями к производительности (до 1500 одновременно работающих пользователей), отказоустойчивости, масштабируемости и безопасности, которое, помимо пользователей, взаимодействует на прикладном уровне со смежными системами в рамках своих бизнес-процессов. Приложение ориентировано на Windows-окружение и проприетарные СУБД. Если рассматривать ИБ-системы, под такое определение, кроме IdM, могут попасть GRC, IRP, c некоторой натяжкой SIEM и множество других продуктов, не относящихся напрямую к рынку информационной безопасности.
Требуется обеспечить работоспособность этого приложения в ОС Linux и поддержку открытой СУБД.
При возникновении потребности портирования приложения на другую платформу, в зависимости от условий, наиболее важным из которых является текущий технологический стек, компания всегда встает перед выбором: портировать имеющийся код или переписать с нуля? Даже если текущий технологический стек продукта поддерживается новой платформой, решение в пользу переписать может быть принято по следующим причинам:
1. Устаревание текущего технологического стека или его неадекватность решаемой задаче в современных реалиях. Например, если продукт (являющийся многопользовательским приложением) написан на С++, можно столкнуться с множеством проблем на всех этапах его жизненного цикла. Первая – недостаток разработчиков на рынке. Современные разработчики С++ хотят работать в тех сферах, где применение их инструмента оправданно: это высокая нагрузка и системная разработка. Найти адекватного разработчика, который возьмется писать сложную бизнес-логику на C++, затруднительно. Следующая проблема – высокая стоимость добавления функций: то, что можно сделать на современном фреймворке за два дня, на устаревшем стеке можно делать две недели или два месяца, а потом еще столько же тестировать. Высокая стоимость поддержки и низкая скорость устранения дефектов – еще одно последствие, которое влечет за собой использование устаревших технологий.
2. Проблемы с высокоуровневой архитектурой и большой технический долг. Масштабные изменения, сопутствующие портированию, могут быть удачным поводом для пересмотра архитектуры, а в случае необходимости глобальных изменений пересмотр стека основных технологий может значительно ускорить выполнение задачи и заложить хорошую базу для развития продукта.
Вне зависимости от принятого решения относительно изменения стека при любых масштабных нефункциональных изменениях продукта подход к выполнению задачи будет примерно одинаков.
На этапе проектирования необходимо:
1) проработать архитектуру развертывания и ответить на вопросы:
2) экспериментально подтвердить все основные архитектурные решения, направленные на поддержку нового окружения. Если меняется способ кластеризации, стоит проверить, используется ли какое-то окружение, доступное на обеих платформах, и уточнить сценарии работы с ним в новой инфраструктуре. Результатом должна стать уверенность в реализуемости выбранного технического решения.
Сама разработка при портировании будет разделена на два больших этапа:
Первый этап ввиду новизны для команды разработки и наличия рисков (особенно если был пропущен или недостаточно тщательно выполнен второй этап проектирования) плохо прогнозируем по срокам и должен выполняться относительно небольшим количеством ведущих разработчиков. Это позволит заложить правильную основу и избежать множества "грабель", на которые команда сможет наступить в будущем. Если при портировании не происходит полная замена платформы, то перенос функций пройдет проще, поскольку как минимум часть приложения сохранит свой первоначальный вид и поведение, на которое можно опираться при тестировании. Если же производится замена платформы, то неплохим подспорьем может стать документация, описывающая пользовательские сценарии. Не имея ее, крайне сложно сохранить все функции и особенности поведения, необходимые пользователям.
Положительную роль на этапе разработки может сыграть применение гибкой методологии (в первую очередь Scrum), что при наличии документации с описанием пользовательских историй и сценариев позволит достаточно точно прогнозировать трудозатраты и сроки, а также масштабировать команду разработки на этапе переноса функций.
В случае если принято решение о полной замене технологического стека, выбор, доступный в современном мире разработки, может ввести в заблуждение даже опытных проектировщиков, поработавших какое-то время в определенной технологической нише. Помимо функциональных требований, стабильности и надежности выбираемого инструмента, стоит учитывать следующие моменты:
От рекомендаций конкретных технологий я воздержусь, но постараюсь перечислить решения, от которых при разработке коммерческого продукта по возможности стоит воздержаться.
Первое: внешние зависимости необходимо свести к минимуму. Под внешними я понимаю любые сервисы, которые разворачиваются и сопровождаются отдельно от ПО. Например, если нет веских оснований использовать ApacheKafka и есть возможность реализовать необходимые кейсы, решаемые им, на уровне своего ПО или с помощью встраиваемых зависимостей, стоит отдать предпочтение встроенной реализации.
Конечно, есть зависимости, реализация которых неподъемна и неадекватна на уровне прикладной системы, например СУБД или Web-сервер. Для таких случаев стоит воздержаться от использования новых, не принятых в индустрии решений. К примеру, NoSQL СУБД, возможно, даже больше подходит продукту по архитектуре, нежели традиционное решение, но она явно не будет тепло принята клиентами – крупными компаниями. Прежде чем ее применять, стоит еще раз взвесить все за и против.
Web-технологии – отдельный предмет для разговора. Тренды в них меняются настолько часто, что продукт с использованием нового крутого SPA-фреймворка еще не выпущен, а уже устарел, и фронтэндеры с рынка не хотят с ним работать. Здесь важно соблюсти разумный баланс между новизной и качеством и, возможно, отказаться от применения каких-то нововведений в принципе в пользу более простых и доступных фуллстек-разработчикам технологий. Все вышесказанное – квинтэссенция опыта, полученного в реальных условиях разработки коммерческого продукта. Надеюсь, что этот опыт поможет специалистам в принятии важных решений, убережет от ошибок или сподвигнет на реализацию казавшейся неподъемной задачи.
Опубликовано: Журнал "Системы безопасности" #6, 2018
Посещений: 2721
Автор
| |||
В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций