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

25 апреля мы в Mail.ru Group провели конференцию про облака и вокруг — mailto:CLOUD. Несколько хайлайтов:

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

Все видео с конференции mailto:CLOUD можно посмотреть по ссылке, а здесь можно почитать, как прошла дискуссия про микросервисы. Своими — успешными — кейсами избавления от монолитов поделились Александр Деулин, руководитель центра исследования и разработки бизнес-систем «МегаФона», и Сергей Сергеев, директор по информационным технологиям группы «М.Видео-Эльдорадо». Также обсудили близкие вопросы IT-стратегии, процессов и даже HR.

Участники дискуссии

• Сергей Сергеев, директор по информационным технологиям группы «М.Видео-Эльдорадо»;
• Александр Деулин, руководитель центра исследования и разработки бизнес-систем «МегаФона»;
• Модератор — Дмитрий Лазаренко, руководитель PaaS-направления Mail.ru Cloud Solutions.

После выступления Александра Деулина «Как МегаФон расширяет свой бизнес за счёт микросервисной платформы» к нему присоединяются для дискуссии Сергей Сергеев из «М.Видео-Эльдорадо» и модератор дискуссии Дмитрий Лазаренко, Mail.ru Cloud Solutions.

Ниже мы подготовили для вас расшифровку дискуссии, но также можно посмотреть видео:

Переход на микросервисы — реакция на потребности рынка

Дмитрий:

Был ли у вас успешный опыт перехода на микросервисы? И вообще: где вы видите наибольшую пользу в бизнесе от применения микросервисов или перехода от монолитов к микросервисам?

Сергей:

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

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

Одним из первых сервисов, самых высоконагруженных, стал сервис расчета цены. Каждый раз, когда вы приходите в любой канал, в группу компаний «М.Видео-Эльдорадо», будь то сайт или розничный магазин, подбираете там товар, видите цену на сайте или в «Корзине», стоимость автоматически рассчитывает один сервис. Зачем это нужно: до этого у каждой системы были свои принципы работы с промо — со скидками и так далее. Ценообразованием у нас занимается бэк-офис, функционал скидок реализован в другой системе. Это нужно было централизовать и создать такой уникальный, отделяемый сервис в виде бизнес-процесса, который позволял бы нам это реализовать. Примерно так мы стартовали.

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

За последние три года у нас добавились три фронтовые системы. Их было сложно поддерживать в том же объеме ресурсов, которые могла позволить себе компания. Поэтому возникла задача искать новые выходы, отвечая на рынок с точки зрения скорости, с точки зрения внутренних затрат и эффективности.

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

Дмитрий:

Как определяется успешность в переходе на микросервисы? Что было «до» в каждой компании? Какую метрику вы использовали для определения успешности перехода, кто ее определял на самом деле?

Сергей:

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

Александр:

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

Сергей:

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

Микросервисы придут, но core останется

Дмитрий:

Это похоже на бесконечный процесс, где вы инвестируете в разработку. Сам переход на микросервисы для бизнеса уже закончился или нет?

Сергей:

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

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

Дмитрий:

Жизнь в тонусе. (Смеется)

Александр:

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

Но мы планируем сохранить core-часть, так как в ландшафте оператора всегда будут какие-то платформы, которые мы покупаем. Опять же, нужен здоровый баланс: мы не должны бросаться в «выпиливание» core. Мы ставим системы рядом, а сейчас, оказывается, что уже и над многими core-частями. Дальше, развивая функционал, делаем нужные представления для всех каналов, которые работают с нашими услугами связи.

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

Дмитрий:

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

Сергей:

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

Дмитрий:

А вы как-то фиксировали время первого этапа?

Сергей:

Да, конечно. Мы отводили 6 месяцев на создание core как платформы и проверку пилота. За это время мы пытались создать платформу, на которой откатали пилот. Дальше подтвердили гипотезу, а раз она работает — значит, можно продолжать. Начали тиражировать и усилили команду — вывели ее в отдельное подразделение, которое только этим и занимается.

Дальше идет планомерная работа, исходящая из потребностей бизнеса, возможностей, доступности ресурсов и всего того, что есть сейчас в работе.

Дмитрий:

Окей. Александр, что скажете?

Александр:

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

Дмитрий:

А бывает, что бизнес позволяет заниматься таким делами по принципу Google — в один свободный день в неделю? У вас есть такое направление?

Александр:

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

И уже понятно материальное влияние — нас уже можно посчитать, оценить скорость вывода продуктов и недополученную выручку, если бы мы шли старым путем. Вот на этом мы и строим кейс.

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

Дмитрий:

Цифры есть цифры. И выручка или сэкономленные деньги — это очень важно. А если посмотреть на другую сторону? Кажется, что микросервисы — это тренд, хайп и многие компании злоупотребляют этим? Насколько четко вы разграничиваете, что вы переводите и не переводите на микросервисы? Если legacy сейчас, то останется ли у вас legacy через 5 лет? Каким будет возраст информационных систем, которые работают в «М.Видео-Эльдорадо» и в «МегаФоне» через 5 лет? Будут ли там десятилетние, пятнадцатилетние информационные системы или это будет новое поколение? Как вы это видите?

Сергей:

Мне кажется, что совсем далеко сложно загадывать. Если обернуться назад, то кто предполагал, что так будет развиваться рынок технологий и того же машинного обучения, идентификации пользователей по лицу? Но если посмотреть в ближайшие годы, мне кажется, что core-системы, enterprise-системы класса ERP в компаниях — они работают достаточно давно.

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

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

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

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

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

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

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

Александр:

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

Дмитрий:

Здесь как раз сертификация — это одна история. Наверное, еще поддержка. Если вы тратите на поддержку немного или система не требует поддержки и доработки, лучше ее не трогать. Разумный компромисс.

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

Дмитрий:

Хорошо. А вот мне еще интересно. Сейчас вы рассказываете success story: все было хорошо, мы перешли на микросервисы, защитили идею перед бизнесом, и всё получилось. Но я слышал другие истории.

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

У вас были подобные истории? Были или есть какие-то сложности? Например, обслуживание микросервисов, тот же мониторинг — тоже головная боль в операционной деятельности компании. Ведь количество компонентов увеличивается в десятки раз. Как вы это видите, были ли неудачные примеры инвестиций здесь? И что можно посоветовать людям, чтобы они не сталкивались с подобными проблемами?

Александр:

Неудачные примеры были в том, что бизнес менял приоритеты и отменял проекты. Когда на хорошем этапе готовности (фактически готов MVP) бизнес говорил: «У нас новые приоритеты, идем в другой проект, а этот закрываем».

Глобальных фейлов с микросервисами у нас не было. Мы спокойно спим, у нас есть дежурная смена 24/7, которая обслуживает весь BSS [business support system].

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

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

За все время существования наших микросервисов был всего один или два инцидента, которые дошли до нашей линии. Сейчас проблем с эксплуатацией нет. У нас, конечно, не 200, а порядка 50 микросервисов, но они используются во флагманских продуктах. Если бы они сбоили, мы бы узнали об этом первыми.

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

Сергей:

Согласен с коллегой про передачу в поддержку — что нужно правильно организовывать работу. Но скажу о проблемах, которые, конечно же, есть.

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

Во-вторых, при создании определенных ландшафтов и растущем количестве сервисов должна постоянно решаться задача с переиспользованием. Как любят делать разработчики: «Давайте сейчас понапишем здесь много всего интересного…» Из-за этого система разрастается и теряет свою эффективность с точки зрения денег, стоимости владения и так далее. То есть, нужно закладывать переиспользование в архитектуру систем, включать в road map внедрения сервисов и перевода legacy на новую архитектуру.

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

Ну и масштабирование ресурсов. «Здорово, поехали! А теперь хотим быстрее, больше. А что, не можете? Разве в два раза больше поставить за год нельзя? А почему?» Такие проблемы роста — стандартны, наверное, для многих вещей, многих подходов, и они чувствуются.

По поводу мониторинга. Мне кажется, что сервисы или промышленные инструменты мониторинга уже учатся или умеют работать и с Docker, и Kubernetes в другом, нестандартном режиме. Чтобы у вас, например, не появилось 500 Java-машин, под которыми все это запущено, а именно агрегирует. Но этим продуктам еще не хватает зрелости, им предстоит это пройти. Тема действительно новая, она еще будет развиваться.

Дмитрий:

Да, очень интересно. И это касается HR. Возможно, ваш НR-процесс и HR-бренд немного поменялись за эти 3 года. Вы стали набирать других людей, с другой компетенцией. И тут есть, наверное, и плюсы, и минусы. Раньше хайповыми были blockchain и data science, и специалисты по ним стоили просто миллионы. Сейчас стоимость спадает, рынок насыщается, и в микросервисах похожий тренд.

Сергей:

Да, абсолютно.

Александр:

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

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

Дмитрий:

Если посмотреть на целевую архитектуру, то микросервисы выглядят таким себе монстром. Ваш путь занял несколько лет. У других год, у третьих — три года. Вы предвидели все проблемы, целевую архитектуру, менялось ли что-то? Например, в случае микросервисов сейчас появляются опять gateways, service mesh’ы. Вы использовали их в начале или меняли саму архитектуру? Есть ли такие вызовы у вас?

Сергей:

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

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

Безопасность очень важна. Как только вы начинаете быть доступными и у вас есть сервис, по которому можно много чего интересного получить, и очень быстро, за доли секунд, то возникает желание получить это не самым безопасным образом. Чтобы от этого уйти, пришлось менять подходы к тестированию и мониторингу. Пришлось менять команду, структуру управления поставкой, CI/CD.

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

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

Дмитрий:

Круто. А что в «МегаФоне»?

Александр:

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

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

Дмитрий:

Золотые слова! Такие вызовы держат в тонусе команду и бизнес и создают будущее. GDPR создал chief data protection officers, а нынешние вызовы создают главных по микросервисам и архитектуре. И это радует.

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

Спасибо всем участникам, спасибо Сергею и Александру!

Вопросы из зала

Вопрос из зала (1):

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

Сергей:

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

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

Это как, в хорошем смысле, инъекция в виде вакцины, которая показала: можно вот так, а можно и по-другому. Конечно, есть проблема в персонале, в компетенциях, в знаниях, в сопротивлении.

Вопрос из зала (2):

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

Александр:

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

Например, мы делаем продукт, который состоит из 5-7 микросервисов. Нам нужно обеспечить интеграционные тесты по всему скоупу микросервисов, чтобы дать зеленый свет к переходу в мастер-ветку. Эта задача была для нас не нова: мы долго занимались этим в BSS, когда вендор поставлял нам уже отгруженные решения.

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

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

Сергей:

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

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

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

Александр:

Да, автотесты и unit-тесты позволяют сделать качественный сервис. Мы за пайплайн, который нельзя пройти без unit- и интеграционных тестов. Приходится часто тащить в тестовые зоны и в среды разработки эмуляторы, системы с прода, потому что не все системы можно разместить в тестовых зонах. Причем они не просто мокаются — мы генерируем полноценный ответ от системы. Это серьезная часть работы с микросервисами, и мы в нее тоже вкладываемся. Без этого наступит хаос.

Вопрос из зала (3):

Насколько я понимаю, изначально микросервисы росли из отдельной команды и сейчас существуют в этой модели. Какие у нее плюсы и минусы?

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

Соответственно, эксплуатация у нас тоже уходит к системам, то есть мы децентрализуем эту тему. Какой у вас подход и какая целевая история для вас?

Александр:

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

Сергей:

Расскажу, какой путь мы прошли. Мы действительно начинали работать одной командой, но сейчас она не одна. Я сторонник следующего: должен быть владелец процесса. Кто-то должен понимать, управлять, контролировать и строить процесс разработки по микросервисам. Он должен владеть ресурсами и заниматься ресурс-менеджментом.

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

При этом процесс остается общим, контролируемым, он протекает по общим технологическим принципам, с unit-тестированием и так далее — всем, что надстроено сверху. Тут могут быть колонны в виде ресурсов, собранных из разных подразделений продуктового подхода.

Александр:

Сергей, вы фактически являетесь владельцем процесса, да? Backlog задач общий? Кто занимается его распределением?

Сергей:

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

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

Допустим, бизнес говорит: «Хотим вот такую функцию, хотим создать новый продукт — переделать кредит». Мы отвечаем: «Да, переделаем». Архитекторы говорят: «Давайте подумаем: где в кредите впишем микросервисы и как это сделаем?». Дальше раскладываем это на проекты, продукты или на технологический стек, опускаем в команды и реализуем. Создали внутри продукт и решили в этом продукте использовать микросервисы? Говорим: «Теперь legacy-системы, которые у нас были, или фронтовые, должны переходить на эти микросервисы». Архитекторы говорят: «Так: в технологический backlog внутрь фронтовых продуктов — переход на микросервисы. Поехали». И продуктологи или владельцы от бизнеса понимают, сколько отведено capacity, когда это будет сделано и почему.

Конец дискуссии, но ещё не всё

Конференция mailto:CLOUD была организована Mail.ru Cloud Solutions.

Мы также делаем другие мероприятия — например, @Kubernetes Meetup, куда всегда ищем классных спикеров:

• Следите за новостями @Kubernetes и других @Meetup в нашем Telegram-канале t.me/k8s_mail
• Хотите выступить на одном из @Meetup? Оставьте заявку на mcs.mail.ru/speak

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