Переход на микросервисы
5 (100%) 1 vote

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

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

Изучите систему. Выясните зависимости с помощью специальных средств, таких как Retrace, Dynatrace, SchemaCrawler и т. п., либо сделайте это вручную.

Формализуйте архитектуру(инструменты, фреймворки и т. д.). Не откладывайте выбор платформы и по возможности предусмотрите необходимые механизмы поддержки DevOps, причем чем раньше, тем лучше.

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

Разделите проект на этапы проектирования, написания кода, тестирования и интеграции. Освойте agile-методы. По возможности используйте средства DevOps на каждом этапе, например Fuge, Git/GiHub, Jenkins, Phantom или Kubernetes.

Переход на микросервисы, как и любое преобразование ПО, способен сильно повлиять на качественные характеристики приложения:

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

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

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

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

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

***

Технологии микросервисов развиваются сегодня весьма стремительно, в частности, получили развитие бессерверные вычисления — предоставление облачным микросервисом стандартных функций, которые можно использовать в приложениях для реализации необходимой бизнес-логики. Такие платформы могут называться «бессерверными» или предоставляющими «функции в виде сервиса» (Function-as-a-Service, FaaS): Amazon Web Services Lambda, Iron.io и Google Functions.

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