Реализация ИТ проектов на основе микросервисной архитектуры

Познанин Л.П.

Выпускник группы MBA CIO-56B

Школа IT-менеджмента

РАНХиГС при Президенте РФ

В аттестационной работе в качестве объекта исследования будет рассматриваться проект по реализации автоматизированной системы управления дорожным движением (АСУДД) на платном участке М11 трассы Москва – Санкт-Петербург.

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

Целью работы является формирование общего подхода к использованию микросервисной архитектуры (МА) в ИТ проектах в условиях постоянных изменений.

В ходе выполнения работы будут решены следующие задачи:

1. Проведен анализ МА;
2. Определены условия применения МА;
3. Выявлены сильные и слабые стороны МА;
4. На конкретном примере будут показаны результаты применения МА;
5. Сформированы общие принципы и рекомендации для применения МА.

Область применения

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

Результаты

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

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

Были сформулированы следующие условия, которые необходимы для применения МА:

1. Масштабность проекта. Для успешного применения МА проект должен быть достаточно крупным, чтобы окупить накладные расходы, связанные с синхронизацией различных команд. Использование МА в малых проекта не целесообразно. Вместе с тем, крайне важно применять принципы МА, даже в малых проектах, чтобы иметь задел на дальнейшее развитие. В итоге малый проект может оказаться частью более крупного и его понадобиться интегрировать с другими проектами, что в современных условиях крайне важно. Абсолютно изолированных систем на рынке сейчас все меньше и меньше, основной тренд – это создание единой экосистемы в рамках цифровой экономики;
2. Четкая декомпозиция по функциональным требованиям. Крайне важное условие, без которого само понятие сервиса не имеет смысла. Сервис всегда выполняет определенную функцию и является черным ящиком для внешнего мира, предоставляя интерфейс взаимодействия. Крайне необходимо провести четкие границы между сервисами, в противном случае получится клубок и переплетение с дублированием функционала.
3. Должна быть команда, отвечающая за сервис. Сервис, как и любой продукт, имеет свой жизненный цикл. От рождения до ввода в эксплуатацию и вывода из нее сервис должен быть закреплен за командой. Команда может передавать свою компетенцию по сервису другой команде, что определяется административными условиями и регламентами.
4. Количество реализуемого функционала одного сервиса должно быть не больше, чем может обеспечить команда из 3-7 человек. Именно 3-7 человек – это оптимальное количество для прямого управления одним человеком (teamlead). В более крупных командах необходимо вводить дополнительное административное управление. Это минимальное самодостаточное звено. Из таких команд набираются проектные группы.
5. Наличие постоянных изменений. Микросервисы идеально подходят для ситуации непрерывных изменений. Не одна другая архитектура не сможет обеспечить своевременную реакцию на изменения. Это обусловлено размером команды и наличию прямого общения между ее членами без лишних административных барьеров. Если изменения редки, то как правило нет необходимости применять микросервисы.
6. Непрерывное тестирование при любых изменениях. Сервис обязан исполнять свой контракт. Чтобы это обеспечить, необходимо выстроить автоматические сценарии тестирования при любых изменениях. Если такого тестирования нет, то микросервисы превращаются в головную боль для команды разработки.
7. Автоматические сценарии развертывания обновлений. В масштабных проектах количество микросервисов может составлять несколько сотен. Управление всем этим зоопарком должно быть хорошо организовано и по возможности максимально автоматизировано.

Выводы

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