Check Levi9 best QA positions to Backbase team!
×Закрыть
  • Что следует знать об организации работы при переходе на микросервисную архитектуру

    Детальное сравнение проводили еще когда начали вводить изменения. Верхнеуровнево разница есть, но все кроется в том, какие технологии, встроеные функциональности cloud поставщиков используются, и тд. Все можно и нужно обсуждать детально с провайдером, в большинстве случаем охотно выходят на связь. И тогда же, после такого ревью и общения, выбрали вектор platform agnostic подхода, чтобы была возможность активно рассматривать разных клауд провайдеров.
    С другой стороны мы очень тесно сотрудничаем сейчас с Microsoft по многоим направлениям, где Azure Cloud — одно из основных. Сейчас наш продукт работает во многих регионах. Это в т.ч значит, что мы активно используем клауд ресурсы, что дает нам возможность развивать более активно наше партнерство с Microsoft, где мы обсуждаем не только цены, но и ценность,которую получает Wirex, кроме простого потребления продуктов/услуг. Например мы напрямую взаимодействуем с инженерами, архитекторами Microsoft, организованы knowledge-sharing сессии, организовываем сертификации и тд. Придерживаемся такого подхода со всеми партнерами, ну и общаемся с AWS и Google Cloud постоянно.

  • Что следует знать об организации работы при переходе на микросервисную архитектуру

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

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

    По остальным вопросам, они довольно объемные для комментария, можем встретиться на каком-то событии и детально обсудить. Например мы будем учавствовать на .NET fwdays’20, можем пообщаться.

    Поддержал: Max Shnurenok
  • Что следует знать об организации работы при переходе на микросервисную архитектуру

    Правильно собрать все релизы в кучу — это основная организационная задача в рамках перехода на микросервисы. Для этого мы создали особую матричную организационную структуру из независимых команд и точек синхронизаций релиз-pipeline в синергии с принципами реализации новой функциональности с обязательным включением feature toggles в каждый релиз. Послностью раскрыть детали такого подхода планирем в следующей статье.