Микросервисы решили одну из главных проблем монолитных систем — позволили развивать и масштабировать отдельные компоненты независимо друг от друга. Но за эту гибкость приходится платить. Михаил Чухломин, руководитель Guardant, бизнес-направления компании «Актив», разбирает девять ключевых вызовов, с которыми сталкивается вендор при защите и лицензировании микросервисного ПО, и предлагает проверенные решения — от сетевых лицензий и grace-периодов до шифрования и анализа статистики использования.
Микросервисная архитектура давно стала ключевым подходом: вместо монолита продукт разбивается на независимые сервисы, каждый отвечает за свою бизнес-функцию и может разрабатываться, обновляться и разворачиваться отдельно. Пользователь получает возможность независимо размещать сервисы в разных контурах, масштабировать компоненты под нагрузку, снижать риски при обновлениях, а отказ одного сервиса не останавливает всю систему. Вендору тоже удобнее развивать продукт и продавать расширения.
Однако возникают и технические нюансы. Усложняется развертывание у заказчика — требуется подготовленная инфраструктура с оркестрацией контейнеров и управлением зависимостями, а также хорошая сетевая связанность между сервисами.
Кроме того, повышаются требования к безопасности, поскольку вместо одной границы (внешний API или UI) в микросервисной архитектуре их становится много — API каждого сервиса, межсервисное общение, переменные окружения, секреты, сетевые права. И наконец, само лицензирование ПО усложняется. Разработчику нужно определить, какой сервис проверяет лицензию, где она хранится, как учитывать количество экземпляров, действовать при масштабировании и миграции контейнеров, обеспечивать отказоустойчивость.
Почему микросервисы усложняют лицензирование
В монолитном ПО, как правило, вопрос решается относительно просто. Приложение запускается на конкретной машине, обращается к локальному или сетевому ключу и получает информацию о действующих лицензионных условиях: например, о наличии права на работу, сроках действия или ограничениях по функциональности.
В микросервисной архитектуре все значительно сложнее:
- количество сервисов может достигать сотен;
- каждый сервис может иметь несколько одновременно работающих экземпляров, которые автоматически запускаются, останавливаются в зависимости от нагрузки;
- контейнеры могут мигрировать между узлами (нодами) оркестратора,
- инфраструктура заказчика, как правило, неоднородна — сервисы работают в контейнерах, виртуальных машинах и на физических серверах;
- внутренняя сеть клиента может быть частично изолирована от интернета, что ограничивает внешние проверки лицензий;
- взаимодействие между микросервисами осуществляется по сети;
- физические характеристики конкретной машины (идентификаторы оборудования, MAC-адреса и т.п.) перестают быть надежной основой для привязки лицензии.
Именно виртуализация и контейнеры снижают надежность классической привязки лицензии к аппаратным идентификаторам. Внутри виртуальной среды приложение часто видит не физическое оборудование, а виртуальные характеристики среды исполнения. Кроме того, окружение может меняться в зависимости от миграции контейнеров между нодами. Это усложняет node-locking (привязку к конкретному узлу или устройству) и требует более продуманной модели лицензирования.
В результате у вендора возникает ряд вопросов:
- Где должен располагаться лицензионный файл (или ключ) и какой компонент отвечает за проверку права на запуск — каждый микросервис индивидуально или выделенный сервис лицензирования?
- Как ограничивать количество одновременно запущенных экземпляров и как лицензировать разные типы микросервисов?
- Как обеспечить работоспособность при кратковременном сбое сети (чтобы временная потеря связи с сервером лицензий не останавливала критичные сервисы) и как защититься от несанкционированного копирования и распространения контейнеров?
- Как измерять потребление по времени, по числу вызовов API, по объему обработанных данных?
- Как спроектировать систему лицензирования так, чтобы она не стала настолько тяжелой, что начнет мешать нормальной эксплуатации продукта?
Рекомендации по решению типовых задач лицензирования микросервисов
Рассмотрим, как на практике надежно защитить и лицензировать программное обеспечение, разработанное по микросервисной архитектуре и работающее в распределенной среде.
Децентрализация запуска
В микросервисной системе нет одной точки запуска. Один клиент может поднять три экземпляра сервиса обработки данных, другой — 30. Если лицензия не контролирует количество экземпляров, клиент технически может использовать больше мощностей, чем купил.
Решение: использовать сетевые лицензии с контролем одновременного потребления. Каждый экземпляр микросервиса при старте запрашивает право на работу у менеджера лицензий. Если лимит исчерпан, сервис не запускается или работает в ограниченном режиме. При остановке экземпляра микросервиса лицензия освобождается и может быть использована другим экземпляром.
Миграция контейнеров между нодами
В Kubernetes или других системах оркестрации контейнер может быть пересоздан на другой ноде. Если лицензия жестко привязана к конкретной ноде, это делает нормальную эксплуатацию невозможной.
Решение: не привязывать лицензию каждого микросервиса к конкретному контейнеру или рабочему узлу (worker node). Более удобная модель — размещать сетевую лицензию и менеджер лицензий на хосте или выделенной ноде, а микросервисы должны получать разрешение по сети.
Закрытые корпоративные контуры
Многие B2B-клиенты работают в изолированных сетях. У них может отсутствовать постоянный доступ к интернету, а иногда его нет совсем.
Решение: предусмотреть онлайн- и офлайн-активацию, а также обновление лицензии. Проверку наличия лицензии необходимо делать полностью автономно, без привязки к внешним сервисам.
Отказоустойчивость лицензирования
Если микросервис не может обратиться к менеджеру лицензий из-за кратковременного сетевого сбоя, продукт не должен мгновенно прекращать свою работу. Это требование крайне важно для любого крупного заказчика.
Решение: использовать контролируемый льготный период (grace period) или временное кэширование лицензии. Например, сервис может локально сохранить разрешение на ограниченное время и продолжить работу, несмотря на кратковременные проблемы с сетью. При этом срок и условия такого кэша должны быть ограничены, чтобы он не превратился в механизм обхода лицензирования.
Защита от копирования и реверс-инжиниринга
Лицензирование само по себе не защищает код. Если ценный алгоритм лежит в контейнере в незащищенном виде, его можно изучать, копировать, патчить или пытаться отключить проверку лицензии.
Решение: защищать только действительно ценные части продукта: алгоритмы, расчетные ядра, уникальные бизнес-правила, криптографически значимые участки. Эти участки кода имеет смысл защищать с помощью автоматических средств защиты от реверс-инжиниринга, чтобы усложнить злоумышленнику процесс взлома ПО.
Сложность коммерческого учета
Микросервисы позволяют продавать продукт гибко, но без централизованного учета это быстро превращается в хаос. У разных клиентов могут быть разные наборы модулей, разное количество экземпляров на каждый микросервис, разные сроки, демоверсии, обновления и переносы лицензий.
Решение: использовать систему управления жизненным циклом лицензий, которая охватывает создание, выдачу, обновление, блокировку, перенос, а также учет клиентов, продуктов и модулей. Такая система должна давать возможность менеджерам по продажам самостоятельно сконфигурировать нужную лицензию с требуемыми лицензионными ограничениями, а также формировать обновления для лицензий, которые уже находятся на стороне конечного пользователя.
Скорость работы и масштабирование
Количество микросервисов и их экземпляров может достигать нескольких сотен. Микросервисы могут регулярно перезапускаться и обращаться к сетевой лицензии, чтобы получить разрешение на запуск и работу с учетом существующих лицензионных ограничений.
Решение: менеджер лицензий изначально должен разрабатываться с учетом повышенных требований к производительности, стабильности и предоставлять возможность кэшировать лицензионные ограничения на конечных устройствах для снижения нагрузки.
Обеспечение безопасности лицензии
Сетевая лицензия, установленная на хосте или в выделенном контейнере, должна быть надежно защищена от тиражирования и изменения лицензионных ограничений.
Решение: использовать безопасное зашифрованное хранилище лицензионных ограничений в программном или аппаратном ключе. При использовании программного ключа важно предусмотреть систему гибких и надежных «привязок» к параметрам окружения. В случае повышенных требований к безопасности нужно хранить сетевую лицензию в аппаратном ключе защиты.
Удобство администрирования
Системному администратору конечного пользователя важно иметь возможность быстро продиагностировать ситуацию в случае проблем в работе программного комплекса.
Решение: сетевой менеджер лицензии должен не только выдавать лицензии по запросу, но и отображать статистику текущего использования лицензий, позволять настраивать политики доступа микросервисов к лицензиям и логировать все события. Например, фиксировать, когда пользователь достиг установленных лицензией лимитов. Это позволит заказчику и менеджерам по продажам получить статистику для принятия решения о расширении существующего пула лицензий.
Платформа для защиты и лицензирования микросервисов
Микросервисная архитектура делает ПО для B2B более гибким, масштабируемым и удобным для развития. Но при этом архитектура продукта и требуемая инфраструктура становится значительно сложнее и требует дополнительной экспертизы в построении и администрировании микросервисных архитектур. Кроме того, меняется и сама природа лицензирования, и вместо одного приложения на одном сервере появляется распределенная система из множества сервисов, контейнеров и экземпляров.
Чтобы такая архитектура не разрушила коммерческую модель, лицензирование нужно проектировать на ранних этапах разработки. Важно заранее определить, какие микросервисы представляют коммерческую ценность, какие лимиты нужно контролировать, где будет находиться лицензия, как продукт будет работать в закрытых сетях и что произойдет при временном сбое в сети.
Оптимальная стратегия — не пытаться механически перенести старую монолитную модель лицензирования в новую архитектуру, а построить гибкую систему с сетевыми лицензиями, менеджером лицензий, раздающим их по сети, модульными правами, ограничением количества экземпляров или потоков, контролируемым offline/grace-периодом, сбором статистики и защитой критичного кода и данных.
При таком подходе микросервисы становятся не проблемой для монетизации, а, наоборот, инструментом более точной упаковки продукта, гибких тарифов и понятной схемы лицензирования.
Одним из примеров решений, поддерживающих описанные механизмы, является Guardant — профессиональная платформа защиты, лицензирования и управления продажами программных продуктов. Она предоставляет экосистему инструментов для монетизации как классического, монолитного ПО, так и для построения микросервисной архитектуры.
Лицензии записываются в программные или аппаратные (USB) ключи Guardant. В них задается перечень разрешенных микросервисов, количество их экземпляров, а также дополнительные ограничения (время работы, число пользователей, запусков, вычислительных потоков, доступные модули). Программные ключи привязываются к параметрам окружения, что предотвращает несанкционированное тиражирование и изменение прав.
Сетевой менеджер Guardant Control Center обеспечивает раздачу лицензий в контейнеры по сети, адаптирован к высоким нагрузкам, позволяет настраивать доступ, собирать статистику и кэшировать данные на конечных устройствах.
Запускаемое приложение проверяет наличие лицензий и их ограничения через Guardant Licensing API. Дополнительный уровень безопасности реализуется утилитой Guardant Protection Studio, которая защищает не только нативные и .NET приложения, но и ПО на Python. Генерацию лицензий с нужными ограничениями на стороне вендора, их обновление, доставку и учет обеспечивает сервис управления Guardant Station. Он выступает центральным компонентом всей платформы монетизации ПО. Система позволяет внедрять новые схемы лицензирования ПО без привлечения отдела разработки.
Система представляет собой гибкий SDK, который дает разработчикам ПО необходимые компоненты, чтобы легко и эффективно монетизировать свои программные продукты и сконцентрироваться на разработке основной функциональности — том, за что платят конечные пользователи.
Выводы
Микросервисная архитектура — устоявшаяся практика в B2B-разработке, и ее применение будет расти. Усложнение систем требует пересмотра монетизации. Компаниям необходимо с самого начала проектировать систему лицензирования с учетом распределенного характера работы, опираясь на специализированные платформы для лицензирования, защиты и управления продуктами.
Реклама. АО «АКТИВ-СОФТ», ИНН: 7729361030.