Централизация при переходе с монолита на микросервисы на примере компании Leroy Merlin
Во время цифровой трансформации необходимо сосредоточиться на надежности, производительности и стоимости обслуживания.
Не так давно компания Leroy Merlin столкнулась с классической проблемой монолита – все элементы имели высокий уровень связанности, а значит, и места риска, которые бы напомнили о себе при изменениях системы. Из-за этого появляется необходимость в более тщательном контроле изменений, расширенном тестировании и более строгим подходам к релизам. Всё это, в свою очередь, существенно увеличивает time-to-market (время выхода на рынок).
В этой статье расскажем, как можно одновременно управлять уровнем сложности продуктов и технологий при переходе с монолита на микросервисную архитектуру, как одновременно увидеть, что происходит с каждым из продуктов, и как помочь разработчикам понять, что можно использовать повторно.
Общие проблемы цифровой трансформации
В разных странах компании находятся на различных этапах цифровой трансформации. Они постоянно меняют подходы, разрабатывают новые продукты с использованием передовых методологий и технологий. Это и есть развитие. Необходимо сосредоточиться на надежности, производительности и стоимости обслуживания.
С проблемами цифровой трансформации столкнулись и наши коллеги из Leroy Merlin. По словам Вадима Пузырева, директора продукта в управлении домена “Финансы” LM, компания столкнулась с классической проблемой монолита – все элементы между собой имели высокий уровень связанности, а значит, и места риска, которые бы напомнили о себе при малейших изменениях в любой части системы. Причем не важно – масштабировании или чем-то ином. Конечно же, подобное положение приводит к определенным решениям – появляется необходимость в более тщательном контроле изменений, расширенном тестировании и более строгим подходам к релизам, и это все, в свою очередь, существенно увеличивает time-to-market.
Так возможно ли одновременно управлять уровнем сложности продуктов и технологий? Как одновременно увидеть, что происходит с каждым из продуктов, и помочь разработчикам понять, что уже доступно и возможно использовать повторно, и не нужно заново “изобретать велосипед”?
Почему повсюду слышится одно и то же: от монолита к микросервисам?
В мире идет глобальная смена технологического уклада, поэтому все идут по новому пути - переходят от монолита к микросервисам.
Рассмотрим это с точки зрения конечного результата: у традиционного монолитного приложения одна или несколько конечных точек, но все функции внутренние. С переходом к сервисам, а затем – к микросервисам, количество конечных точек увеличивается, как и количество потенциальных соединений между ними, причем в геометрической прогрессии. Предположим, у приложения 10 конечных точек, потенциал соединений между ними составит 50. Если конечных точек 100, число соединений будет уже 5000. С 1000 конечных точек количество возможных подключений составит полмиллиона. Такое стремительное развитие влечет за собой ряд трудностей, не решать которые невозможно, иначе смысл трансформации попросту теряется.
Какие же проблемы возникают в процессе цифровой трансформации?
- Надежность выполняемых функций.
- Безопасность сетей.
- Производительность сетей.
- Обнаруживаемость (от нескольких API до множества).
- Сложность: вы вынуждены переходить от однородной технологии в разнородные.
- Видимость (от нескольких единиц развертывания до множества).
Всё это следствие эволюции и перехода от монолита к микросервисам.
Разбор монолита I
Посмотрим на первый монолит. Предположим, что его работа довольно эффективна – 90% функциональности составляет бизнес-логика, 10% – политика, которая включает в себя безопасность (аутентификация и авторизация), мониторинг (журналы и метрики) и производительность (например, ограничение скорости и кэширование). А теперь возьмем этот монолит и разобьем его на микросервисы, например, на десять штук.
Получается, что теперь каждый микросервис содержит часть этой бизнес-логики. Однако каждому нужна копия всего уровня политики. В конце концов, каждому микросервису просто необходимы безопасность, наблюдаемость и возможность управлять своей производительностью. Из-за этого процент уникальной бизнес-логики в каждом микросервисе резко снижается. Давайте продолжим этот эксперимент и скажем, что монолит – это одна часть политики и 10 частей бизнес-логики. Если разделить монолит на 10 микросервисов, то у каждой службы будет одна часть политики и одна часть бизнес-логики.
И это соотношение изменяется в худшую сторону с увеличением количества микросервисов. На практике десять микросервисов будут выглядеть как «маленький» монолит по отдельности. А если у вас действительно большой монолит с десятками разработчиков, которые трудились над ним много лет, то речь пойдет о сотнях микросервисов.
Предлагаем не тратить 50% драгоценного времени на реализацию политики. Реализации отдельных политик не уникальны. Поэтому в вашем распоряжении будут общие библиотеки, общие стандарты. А также разделенная на части документация, шаблоны и фрагменты кода.
Однако, как только захотите что-то поменять в политике, придётся обновить общие библиотеки, документацию и т.д., а затем выполнить весь жизненный цикл разработки программного обеспечения – тестирование, контроль качества, постановку и, в итоге, развертывание в производственные циклы. Лучше не стало, правда? Но это еще не конец.
Разборка монолита II
На самом деле вам не удастся разделить монолит на однородные микросервисы. При делении часть функций окажется в микросервисах, другая часть - в бессерверных функциях. Некоторые попадут в сторонние API, а какие-то будут в других местах, о которых вы даже не задумывались, возможно, в еще не существующих технологиях.
Как правило, это разные технологические стеки. Ваши микросервисы сегодня реализованы в .NET и Java, но, завтра некоторые из них будут, например, в Golang. Бессерверные функции применимы на JavaScript или Python, а сторонние API предъявляют другие требования, о которых вы даже не знаете.
На самом деле теперь появляется не одна общая библиотека и один способ делать что-то, а несколько. По одному для каждой технологии. И поэтому каждый раз, когда что-то меняется, приходится обновлять и эти способы, и все службы. И в будущем приготовьтесь поддерживать разные библиотеки для различных языков, быть в курсе новых версий, включать исправления ошибок и протоколы безопасности, поддерживать внутреннюю документацию в нужном состоянии и пр.
И это только для одного монолита, а в компании их может быть несколько.
Уровень централизованной политики
Одним из способов решения этих проблем является введение общей централизованной политики, к которой подключается каждая служба и получает обратную связь. Функции аутентификации, авторизации, ограничения скорости, кеширования, мониторинга можно и нужно выполнять на верхнем уровне. Именно к нему подключаются различные службы, и все коммуникации - связь между службами и внешняя связь - проходят через него. Таким образом, отдельные сервисы могут сосредоточиться на своей уникальной бизнес-логике и иметь общую политику для всех.
Почему стоит использовать наш подход к построению микросервисной архитектуры?
- Повышение производительности разработчиков.
Отстранившись от проблем с политиками, разработчики могут спокойно сосредоточиться на бизнес-логике, что благотворно влияет на скорость вывода новых функций и продуктов на рынок.
- Снижение затрат.
Переход от старых и дорогих технологий, таких как, например, ESB, зачастую способствует сокращению общих затрат на оборудование и программное обеспечение.
- Привлечение и удержание талантов.
Как правило, разработчиков привлекают компании, использующие уже знакомые им современные технологии с открытым исходным кодом. Они рассчитывают на то, что смогут использовать в своей работе наилучший инструмент и что им не придется идти в этом на слишком большие компромиссы
- Наглядность.
Наличие центрального места, через которое проходит весь трафик, позволило реализовать вывод всей необходимой информации на одном экране
- Удобство.
Единый центр для информации и стандартов позволяет документировать все API в одном месте
- Высокая гибкость.
Отстранение от общих проблем позволяет разрабатывать уникальную бизнес-логику на любом языке программирования или фреймворке.
Децентрализация в разработке – довольно интересный и долгосрочный тренд. Многие выбирают этот путь, буквально «взрывая монолиты», и разделяют на микросервисы и бессерверные функции. Зачем? Главная причина – time-to-market – то, за что борются между собой конкуренты. Как развить функциональность? Как повысить продуктивность разработчиков?
Один из способов – это изолировать бизнес-логику от общей политики, такой как безопасность, например, и убедиться, что командам разработчиков не придется «изобретать велосипед». Всё, что не является уникальной бизнес-логикой, уже должно быть априори “вшито” на верхнем уровне. Это аутентификация, авторизация, ограничение скорости, кеширование, ведение журнала запросов и ответов и пр. Если раньше у каждой команды имелась собственная логика, то теперь всё необходимое централизовано, и у команд появляются дополнительные возможности за счет освободившегося ресурса. Остается только убедиться в том, что общие функции не только централизованы, но и совместимы с любой архитектурой и инфраструктурой.
Таким образом, ответ на главный вопрос заключается в децентрализации бизнес-логики и централизации политики.
Хотите узнать, как вашей компании перейти на микросервисную архитектуру? Напишите нам.
Источник: Kong.com
Переводчик: Николай Посунько
Редактор: Лев Буланов