ИТ-директору на заметку: что учесть при разработке нового приложения

Создание ИТ-решения проходит через четыре стандартные стадии — проектирование, разработка, тестирование и эксплуатация. На этом работа не заканчивается: ПО постоянно обновляют, улучшают его функциональность, устраняют уязвимости. На что обратить внимание при создании нового приложения и какие исторические ошибки учесть, рассказал евангелист-архитектор VK Cloud и Tarantool Александр Белоцерковский.

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

Нюанс 1. Выбираем архитектурные решения, учитывая тренды

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

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

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

Большой выбор компонентов и возможность доработать под задачу Open Source решения не сделали создание ПО элементарной задачей. Теперь надо учесть риски внедрения сторонних решений – например для информационной безопасности будущего проекта.

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

Нюанс 2. Придерживайтесь курса на унификацию и интеграцию

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

Придерживайтесь стандартизированных решений, распространяемых в формате фреймворка, библиотеки (API) или даже в открытых кодах. В таком случае нет риска, что проект перестанет развиваться, если какая-нибудь конкретная команда разработчиков потеряет к нему интерес.

Стоит обратить внимание на наиболее устойчивую модель проектов, сочетание полнофункциональной версии в исходных кодах и платной версии. Например, платформа Tarantool родилась как внутренний продукт VK. Сейчас она имеет и Open Source версию с сообществом разработчиков-энтузиастов, и Tarantool Enterprise Edition, адаптированную под требования корпораций: с техподдержкой, консультациями архитекторов и другими бонусами. Такие проекты показывают большую жизнеспособность и даже коммерческую ценность – например, компания Red Hat получала $3,4 млрд от Enterprise-поддержки клиентов. В результате в 2018 году IBM купила ее за $34 млрд.

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

Нюанс 3. Архитектура как часть бизнес-процессов

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

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

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

Следующим вступает в дело solution-архитектор. Его задача — разработать высокоуровневую архитектуру проекта совместно с enterprise-архитектором и перейти к выбору технологий и оценке их влияния на проект. Вместе с solution-архитектором на этом этапе могут понадобится security-, data- и application-архитекторы, каждый из которых отвечает за собственное направление. Итогом работы команды архитекторов должно стать понимание архитектуры проекта, перечень необходимых ресурсов для его запуска и план работы с продуктовыми менеджерами и, возможно, командой эксплуатации.

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

Нюанс 4. Ориентируйтесь на технологии и процессы в облаке

Стадии разработки и тестирования идут обычно рука об руку. ИТ-специалисты часто используют специальные периметры "для разработки и тестирования" — обычно это публичная облачная или локальная инфраструктура. Так как природа самого процесса подразумевает постоянное изменение различных параметров, требуется подобрать баланс между преимуществами и недостатками подходов.

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

Идеально подошла бы для разработки и тестирования частная облачная инфраструктура, которая сочетает преимущества обоих подходов (быстрое выделение ресурсов и их контроль).

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

Нюанс 5. Безопасность каждого компонента

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

- Безопасность. Команда должна четко понимать, что и зачем делает рассматриваемый компонент. Если взяли его извне, то должны помнить о регулярном аудите всего, что работает на этом компоненте.

- Юридическая чистота. У каждого проекта, который используется в разработке, скорее всего, есть своя лицензия. Даже доступные исходные коды не означают, что компания может использовать их по своему усмотрению. Нужно изучить лицензию применяемого компонента, проверить, что она не противоречит публикации конечного продуктов под запланированной вами лицензией. Не соответствующее лицензии использование даже очень маленького компонента может привести к необходимости срочно переписывать его с нуля.

- Знания сотрудников. Документация должна максимально отражать как общие сведения об использовании системы, так и ретроспективные анализы об инцидентах и возможных ситуациях, в которых может потребоваться вмешательство на разных уровнях.

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