От монолита к микросервисам

  • Tages
  • /
  • Блог
  • /
  • От монолита к микросервисам

Централизация при переходе с монолита на микросервисы на примере компании Leroy Merlin

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

Не так давно компания Leroy Merlin столкнулась с классической проблемой монолита – все элементы имели высокий уровень связанности, а значит, и места риска, которые бы напомнили о себе при изменениях системы. Из-за этого появляется необходимость в более тщательном контроле изменений, расширенном тестировании и более строгим подходам к релизам. Всё это, в свою очередь, существенно увеличивает time-to-market (время выхода на рынок).

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

Общие проблемы цифровой трансформации

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

С проблемами цифровой трансформации столкнулись и наши коллеги из Leroy Merlin. По словам Вадима Пузырева, директора продукта в управлении домена “Финансы” LM, компания столкнулась с классической проблемой монолита – все элементы между собой имели высокий уровень связанности, а значит, и места риска, которые бы напомнили о себе при малейших изменениях в любой части системы. Причем не важно – масштабировании или чем-то ином. Конечно же, подобное положение приводит к определенным решениям – появляется необходимость в более тщательном контроле изменений, расширенном тестировании и более строгим подходам к релизам, и это все, в свою очередь, существенно увеличивает time-to-market.

Так возможно ли одновременно управлять уровнем сложности продуктов и технологий? Как одновременно увидеть, что происходит с каждым из продуктов, и помочь разработчикам понять, что уже доступно и возможно использовать повторно, и не нужно заново “изобретать велосипед”?

Почему повсюду слышится одно и то же: от монолита к микросервисам?

В мире идет глобальная смена технологического уклада, поэтому все идут по новому пути - переходят от монолита к микросервисам.

Рассмотрим это с точки зрения конечного результата: у традиционного монолитного приложения одна или несколько конечных точек, но все функции внутренние. С переходом к сервисам, а затем – к микросервисам, количество конечных точек увеличивается, как и количество потенциальных соединений между ними, причем в геометрической прогрессии. Предположим, у приложения 10 конечных точек, потенциал соединений между ними составит 50. Если конечных точек 100, число соединений будет уже 5000. С 1000 конечных точек количество возможных подключений составит полмиллиона. Такое стремительное развитие влечет за собой ряд трудностей, не решать которые невозможно, иначе смысл трансформации попросту теряется.

Какие же проблемы возникают в процессе цифровой трансформации?

  1. Надежность выполняемых функций.
  2. Безопасность сетей.
  3. Производительность сетей.
  4. Обнаруживаемость (от нескольких API до множества).
  5. Сложность: вы вынуждены переходить от однородной технологии в разнородные.
  6. Видимость (от нескольких единиц развертывания до множества).

Всё это следствие эволюции и перехода от монолита к микросервисам.

Разбор монолита I

Посмотрим на первый монолит. Предположим, что его работа довольно эффективна – 90% функциональности составляет бизнес-логика, 10% – политика, которая включает в себя безопасность (аутентификация и авторизация), мониторинг (журналы и метрики) и производительность (например, ограничение скорости и кэширование). А теперь возьмем этот монолит и разобьем его на микросервисы, например, на десять штук.

Получается, что теперь каждый микросервис содержит часть этой бизнес-логики. Однако каждому нужна копия всего уровня политики. В конце концов, каждому микросервису просто необходимы безопасность, наблюдаемость и возможность управлять своей производительностью. Из-за этого процент уникальной бизнес-логики в каждом микросервисе резко снижается. Давайте продолжим этот эксперимент и скажем, что монолит – это одна часть политики и 10 частей бизнес-логики. Если разделить монолит на 10 микросервисов, то у каждой службы будет одна часть политики и одна часть бизнес-логики.

И это соотношение изменяется в худшую сторону с увеличением количества микросервисов. На практике десять микросервисов будут выглядеть как «маленький» монолит по отдельности. А если у вас действительно большой монолит с десятками разработчиков, которые трудились над ним много лет, то речь пойдет о сотнях микросервисов.

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

Однако, как только захотите что-то поменять в политике, придётся обновить общие библиотеки, документацию и т.д., а затем выполнить весь жизненный цикл разработки программного обеспечения – тестирование, контроль качества, постановку и, в итоге, развертывание в производственные циклы. Лучше не стало, правда? Но это еще не конец.

Разборка монолита II

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

Как правило, это разные технологические стеки. Ваши микросервисы сегодня реализованы в .NET и Java, но, завтра некоторые из них будут, например, в Golang. Бессерверные функции применимы на JavaScript или Python, а сторонние API предъявляют другие требования, о которых вы даже не знаете.

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

И это только для одного монолита, а в компании их может быть несколько.

Уровень централизованной политики

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

Почему стоит использовать наш подход к построению микросервисной архитектуры?

  1. Повышение производительности разработчиков.

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

  1. Снижение затрат.

Переход от старых и дорогих технологий, таких как, например, ESB, зачастую способствует сокращению общих затрат на оборудование и программное обеспечение.

  1. Привлечение и удержание талантов.

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

  1. Наглядность.

Наличие центрального места, через которое проходит весь трафик, позволило реализовать вывод всей необходимой информации на одном экране

  1. Удобство.

Единый центр для информации и стандартов позволяет документировать все API в одном месте

  1. Высокая гибкость.

Отстранение от общих проблем позволяет разрабатывать уникальную бизнес-логику на любом языке программирования или фреймворке.

Децентрализация в разработке – довольно интересный и долгосрочный тренд. Многие выбирают этот путь, буквально «взрывая монолиты», и разделяют на микросервисы и бессерверные функции. Зачем? Главная причина – time-to-market – то, за что борются между собой конкуренты. Как развить функциональность? Как повысить продуктивность разработчиков?

Один из способов – это изолировать бизнес-логику от общей политики, такой как безопасность, например, и убедиться, что командам разработчиков не придется «изобретать велосипед». Всё, что не является уникальной бизнес-логикой, уже должно быть априори “вшито” на верхнем уровне. Это аутентификация, авторизация, ограничение скорости, кеширование, ведение журнала запросов и ответов и пр. Если раньше у каждой команды имелась собственная логика, то теперь всё необходимое централизовано, и у команд появляются дополнительные возможности за счет освободившегося ресурса. Остается только убедиться в том, что общие функции не только централизованы, но и совместимы с любой архитектурой и инфраструктурой.

Таким образом, ответ на главный вопрос заключается в децентрализации бизнес-логики и централизации политики.

Хотите узнать, как вашей компании перейти на микросервисную архитектуру? Напишите нам.

Источник: Kong.com

Переводчик: Николай Посунько

Редактор: Лев Буланов

Назад