Переход на микросервисы: опыт «М.Видео-Эльдорадо» и «МегаФона»

11 минут

Мы собрали самые яркие цитаты дискуссии про переход от монолитной архитектуры к микросервисам, прошедшей в рамках конференции mailto:CLOUD про облака и вокруг.

Успешными кейсами избавления от монолитов поделились Александр Деулин, руководитель центра исследования и разработки бизнес-систем «МегаФона», и Сергей Сергеев, директор по информационным технологиям группы «М.Видео-Эльдорадо».

Как продать микросервисы бизнесу?

Сергей:

Мы продавали не подход, а бизнес-выгоду. Была проблематика в бизнесе, и мы ее пытались снять. В тот момент она выражалась в том, что в разных каналах использовались разные принципы расчета цены — отдельно для промо, для акций и так далее. Это было сложно поддерживать, возникали ошибки, мы выслушивали нарекания клиентов. То есть мы продавали устранение проблемы, но приходили с тем, что нам нужны деньги на создание платформы. И показывали бизнес-кейс на примере первого этапа инвестирования: как мы дальше будем его окупать и что это позволит нам делать.

Александр:

У нас микросервисы родились из «пены морской» — за счет экономии ресурсов, за счет каких-то остатков в виде серверных мощностей и перераспределения сил внутри команды. Изначально мы не продавали этот проект бизнесу. Это был проект, где мы и исследовали, и разрабатывали соответственно. Мы стартовали в начале 2018 года и просто на энтузиазме развивали направление.

Как оценить успешность перехода на микросервисы?

Сергей:

В первую очередь это родилось внутри IT как enabler — «разлочивание» новых возможностей. У нас была потребность делать все быстрее за условно те же деньги, отвечая на вызовы рынка. Сейчас успешность выражается в количестве сервисов, переиспользованных разными системами, унификация процессов между собой.

Александр:

Успешность — это, скорее, внутреннее ощущение. Бизнес всегда хочет больше, и глубина нашего backlog’а — это и есть подтверждение успешности.

Сергей:

За три года у нас уже больше двухсот сервисов и backlog. Потребность в ресурсах внутри команды только растет — ежегодно на 30%. Так происходит потому, что люди почувствовали: это быстрее, по-другому, другие технологии, все это развивается.

Когда микросервисы выгодны, а когда нет?

Сергей:

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

А вот когда есть 5 модулей в бэк-офисе, из которых собираются куски информации в бизнес-процесс, которым потом пользуются 8-10 фронтовых систем — здесь сразу заметна выгода.

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

Закончился ли для бизнеса переход на микросервисы?

Сергей:

Вы как считаете: замена телефонов — это бесконечный процесс? Мы же покупаем телефоны каждый год. И здесь так: пока существует потребность в скорости, в адаптации к рынку, будут требоваться какие-то изменения. Это не значит, что мы отказываемся от стандартных вещей.

Мы не можем сразу все охватить и переделать. У нас есть legacy, стандартные интеграционные сервисы, которые были до этого: шины enterprise и так далее. Но есть backlog, и потребность тоже есть. При этом никто не говорит о том, что вам выдадут на 30% больше денег. То есть с одной стороны есть потребности, а с другой — поиск эффективности.

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

Микросервисы — хайп или необходимость?

Сергей:

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

Мы видим такое развитие:

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

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

Микросервисы и HR

Сергей:

Есть несколько проблем. Технология новая. Это в хорошем смысле хайп, и найти специалиста, который будет разбираться и сможет создавать это — большая сложность. Еще одна проблема — хотя это по-своему и хорошо — это внутренняя конкуренция. Люди разные. Есть те, кто привык писать на Java, и те, кто пишет и использует Docker и Kubernetes. Это абсолютно другие люди, они по-разному разговаривают, используют другие термины и иногда друг друга не понимают. Умение или неумение делиться практикой, knowledge sharing, в этом смысле тоже проблема.

Александр:

HR задает вопрос: «Где же ваш розовый единорог между backend’ом и frontend’ом?» HR не понимают, что такое микросервис. Мы открыли им секрет и сказали, что это backend все сделал, и там нет единорога. Но HR меняются, быстро учатся и подбирают в рекрутинг людей, которые владеют базовыми IT-знаниями.

Как разрабатывать надежные микросервисы?

Александр:

Мы сдаем микросервисы по правилам, по которым сдаются коробочные продукты. Во-первых, нужно собрать команду, которая будет полностью готовить микросервис к продакшену. Сама разработка — это, условно, 40%. Остальное — аналитика, методология DevSecOps, правильные интеграции и правильная архитектура. Особое внимание уделяем принципам построения безопасных приложений. В каждом проекте участвуют представители ИБ как на этапе планирования архитектуры, так и в процессе реализации. Еще они заведуют системами анализа кода на уязвимости.

Допустим, мы деплоим свои сервисы stateless — у нас они в Kubernetes. Это и позволяет всем спать спокойно за счет автомасштабирования и автоподнятия сервисов, а дежурная смена подхватывает инциденты.

Эволюция микросервисов

Сергей:

Мы уже переписали несколько протоколов взаимодействия. Повышаем безопасность и надежность. Начинали с enterprise-технологий — Oracle, WebLogic. Теперь уходим от технологических enterprise-продуктов в микросервисах и переходим на open source или на совсем открытые технологии. Отказываемся от баз данных, переходим на то, что более эффективно работает для нас в этой модели. Технологии Oracle нам стали не нужны. Безопасность очень важна, пришлось менять подходы к тестированию и мониторингу, команду, структуру управления поставкой, CI/CD.

Это эволюция — как с телефонами, только гораздо быстрее: сначала были кнопочные телефоны, потом появились смартфоны. Переписали, переделали продукт потому, что у рынка появилась другая потребность. Так и мы эволюционируем: первый класс, десятый класс, работа.

Итеративно в год закладывается что-то с точки зрения технологий, еще что-то — с точки зрения backlog’а и потребностей. Мы соединяем одно с другим. Команда тратит 20% на техдолг и техническое обеспечение команды, 80% — на бизнес-сущность. И двигаем, с пониманием, зачем делаем, почему делаем эти технологические улучшения, к чему они приведут.

Александр:

Основной вызов во время нашего прихода в микросервисы — не свалиться в хаос. К нам сразу подключился, даже стал инициатором и драйвером архитектурный офис «МегаФона» — теперь у нас очень сильная архитектура.

Следующий вопрос был: «А как потом это все эксплуатировать?». И еще один: «Как обеспечить прозрачное взаимодействие между микросервисами?». На последний вопрос нам помог ответить service mesh. Мы пропилотировали Istio, и результаты нам понравились. Сейчас мы находимся на этапе раскатки в продуктивные зоны. Ко всем вызовам мы относимся позитивно — к тому, что нужно постоянно менять стек, изучать что-то новое. Нам интересно развиваться, а не эксплуатировать старые решения.

Как переход к микросервисам меняет IT-менеджмент компании?

Сергей:

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

Но стандартные, базовые принципы разработки, бизнес-анализ, тестирование и разработку — никто не отменял. Мы просто добавили скорость. Раньше цикл занимал столько-то, установка на тестовые среды — еще столько-то. Сейчас бизнес видит выгоду и говорит: «А почему в других местах нельзя так же сделать?».Это как, в хорошем смысле, инъекция в виде вакцины, которая показала: можно вот так, а можно и по-другому. Конечно, есть проблема в персонале, в компетенциях, в знаниях, в сопротивлении.

Сложности с тестированием и разработкой микросервисов

Александр:

Сложности есть при переходе от микросервисов к платформе, но они решаемые.

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

Эта сложность вызвана только масштабированием. Мы понимаем, что микросервисы не могут существовать в вакууме, абсолютной изоляции не существует. Меняя один сервис, мы обязательно стараемся сохранить API-контракт. Если что-то меняется под капотом, front сервиса остается. Если изменения фатальны — только тогда мы говорим о том, что появляется API-спецификация сервиса v2. Мы поддерживаем одновременно первую и вторую версии, а после перехода всех потребителей на вторую версию первую просто закрываем.

Сергей:

Ландшафт усложняется, вырастают накладные расходы, особенно на тестирование. Как с этим бороться: переходить на автотестирование. Да, придется дополнительно инвестировать в написание автотестов и unit-тестов. Чтобы разработчики не могли коммитить без прохождения теста, не могли менять код. Чтобы даже кнопка push не работала без автотеста, unit-теста.

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

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

Kubernetes в облаке от Mail.Ru Cloud Solutions — надежная платформа для микросервисов с автоматическим масштабированием и посекундной оплатой за потребляемые мощности.

Что еще посмотреть?

Все видео с конференции можно посмотреть на YouTube-канале MailRu Cloud Solutions. Несколько хайлайтов:

  1. На одной сцене собрались основные российские провайдеры — про специфику нашего облачного рынка и своих сервисов говорили Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, «Ростелеком — ЦОД» и «Яндекс.Облако».
  2. Коллеги из «Битрикс24» рассказали, как они пришли к мультиклауду.
  3. «Леруа Мерлен», «Открытие», Burger King и Schneider Electric предоставили интересный взгляд со стороны потребителей облаков — какие задачи их бизнес ставит перед IT и какие технологии, в том числе облачные, видятся им наиболее перспективными.
Group 40Group 44Group 43Group 46Group 41Group 27Group 42Group 39