Планирование Service Mesh: ключевые аспекты

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

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

• Зачем нужна платформа Service Mesh?
• Определение бизнес-возможностей
• Организация
• Создание модели управления
• Вопросы эксплуатации и безопасности
• Основные этапы реализации архитектуры
• Выводы

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

Определение и достижение ценностей бизнеса

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

Планирование интеграции Service Mesh начинается с продуманной стратегии. Без стратегии поток задач, необходимых для завершения перехода, может показаться бесконечным, задавить объёмом и увести проект от намеченной цели - достижения ценностей бизнеса.

В рамках этой статьи мы сосредоточимся на четырех из пяти основных аспектов реализации Service Mesh:

1. Определение бизнес-возможностей
2. Организационные действия
3. Управление
4. Операции и безопасность

Первым шагом в процессе трансформации является определение составляющих вашего бизнеса. Эти возможности затем определяются как микросервисы на платформе Service Mesh. Этот шаг помогает предотвратить создание дублирующих сервисов и сопровождается созданием политик управления жизненным циклом (подробнее об этом позже). Эти политики взаимосвязаны и определяют бизнес-процессы с общим видением проекта.

Разработка эталонной архитектуры

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

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

Рассмотрим две самых важных подструктуры.

Центр компетенций

Центр компетенций предоставляет компании руководство по созданию микросервисов, реализующих определенные бизнес-возможности, необходимые для платформы Service Mesh.

В его задачи входит:

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

Подразделы по сферам компетенций

Формирование подразделов по сферам компетенций помогает установить и распространить стандарты и процедуры управления, упомянутые выше.

Эти стандарты и процедуры управления затем доводятся до команд в следующих областях:

• Управление конфигурацией
• Управление релизами
• Управление операциями
• Обеспечение безопасности
• Управление жизненным циклом сервисов
• Управление операциями
• Управление бизнес-требованиями

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

• Управление жизненным циклом микросервисов (Определение, Анализ, Разработка, Производство, Оптимизация, Операции)
• Политики (Безопасность, QoS, Уведомления, Эскалация)
• Эталонная архитектура (Высокоуровневая модель)
• Таксономия микросервисов (Утилита, Сущность, Возможности, Процесс)
• Стандартные канонические модели (Модель документа бизнес-объекта)
• Модель бизнес-возможностей
• Показатели сервисов (Не поставленные, Аутентификация, Доступ, Использование)

Политики управления микросервисами

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

Обеспечение соблюдения политик для сети

Установка и обеспечение соблюдения регламентов, регулирующих использование сервисов, денежных ресурсов и SLA - еще один важный шаг в планировании архитектуры Service Mesh. Независимо от вида (будь то обеспечение качества сервиса или шифрования), политики должны разрабатываться и соблюдаться для обеспечения успеха проекта.

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

Политики безопасности:

•  Контроль доступа
•  Шифрование
•  Логирование
•  Аудит

Переход на архитектуру Service Mesh позволяет согласовать операционные регламенты в соответствии с требованиями безопасности. Это также позволяет воспользоваться преимуществами DevOps практик, поскольку инфраструктура теперь - это код. Безопасность перестаёт быть тем, о чём думают в последнюю очередь, даже на уровне абстракции виртуализированных микросервисов. Для создания и поддерживания уровня метрик на этапе трансформации необходимо обеспечить более строгое соблюдение операционных политик.

Управление конфигурацией

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

Управление релизами

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

Разработка метрик

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

Рекомендуемый начальный набор метрик, которые должна зафиксировать переходная команда:

• Количество выполненных услуг
• Количество недоставленных сообщений
• Количество отказов обслуживания
• Количество ошибок авторизации
• Количество сбоев аутентификации

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

Ключевые выводы этой статьи следующие:

1. Убедитесь, что составлен план процесса перехода, и чётко видна окупаемость инвестиций.
2. Убедитесь, что процесс трансформации основан на ваших бизнес-целях, а не на отдельных технологиях.

Источник