Хабрахабр

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

Несколько хайлайтов: 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.

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

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

Дмитрий:

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

Сергей:

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

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

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

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

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

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

Дмитрий:

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

Сергей:

У нас была потребность делать все быстрее за условно те же деньги, отвечая на вызовы рынка. В первую очередь это родилось внутри 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 в компаниях — они работают достаточно давно.

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

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

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

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

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

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

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

Александр:

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

Дмитрий:

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

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

Дмитрий:

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

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

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

Александр:

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

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

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

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

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

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

Сергей:

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

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

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

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

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

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

Дмитрий:

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

Сергей:

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

Александр:

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

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

Дмитрий:

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

Сергей:

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

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

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

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

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

Дмитрий:

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

Александр:

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

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

Дмитрий:

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

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

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

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

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

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

Сергей:

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

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

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

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

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

Александр:

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

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

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

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

Сергей:

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

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

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

Александр:

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

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

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

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

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

Александр:

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

Сергей:

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

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

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

Александр:

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

Сергей:

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

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

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

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

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

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

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

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть