• Софт из 90-х VS микросервисы: что банки могут перенять у финтех-компаний

    Сценарії, про Амазон дуже поширені в дискусії про хмари, їх також потрібно планувати в побудові інфраструктури. З серверами імо набагато більші ризики, особливо зі сторони відмовостійкості, впливу зовнішнього середовища і тд.
    Що цікаво — моживість відновлення роботи системи на базі іншого провайдера критична не тільки для фінансового сектору. Наприклад Netflix заявляє, що можуть відновити роботу своєї платформи на базі будь-якого клауд провайдера за 10-20 хвилин.
    Cloud-agnostic — саме той підхід, що повинен завжди бути в рамках корпоративних рішень, де є можливість відновлення сервісів без прив’язки до продвайдера послуг та без втрати даних (ми ж працюємо з грошима). В розробці наших систем ми теж дотримуємося цього принципу та активно працюємо над рішеннями що допомагають масштабуватися, розгортати сервіси в будь-якому середовищі.

  • Софт из 90-х VS микросервисы: что банки могут перенять у финтех-компаний

    Богдане, привіт
    релевантні коменти

    на рахунок вибору серваки-хмара, проблема якраз в тому, що в більшості випадків саме застарілі вимоги регуляторів не дають можливість зробити економічно зважений вибір. А надійність хмари вже давное переступила співвідношення інвестиції/надійність, коли для організації аналогічної гнучкості, масштабування та відмовостійкості системи на базі on-land інфраструктури робить існування бізнесу нелогічним. Звичайно при обслуговуванні 100+ клієнтів через 2 відділення не потрібні супер технології, але ми розглядаємо кейси масс продуктів заснованих на цифровому підході, куди все активно рухається в світі і Україні.
    Розвиваючи ліцензований британським FCA (аналог нашого НБУ в частині повноважень регуляції фінансових компаній) продукт, який працює в хмарі ми побудували і далі продовжуємо працювати над рішеннями, що працють на ринки Європи, Азії та США та відповідає вимогам (в деяких випадках жорсткішим, ніж до банків) на кожному з цих ринків.
    В будь-якому разі питання в тому, щоб все таки почати перехід та модернізацю для банків, що відразу відобразиться на швидкості впродвадження фіч, гнучкості сервісів та в результаті на рівні послуг. А деякі регулятори, в т.ч. наш НБУ сильно застаріли в своїх вимогах, в більшості випадків це виглядає як регуляція заради регуляції.

    Щодо надійності крипто-компаній, так, в 2017-18 роках, проекти з цифровими валютами тільки розвивалися, виникали питання до стабільності. Ми активно приймали участь в розвитку цієї індустрії і маю сказати, що зараз продукти, які є ліцензованими і працюють в Європі, США, Азії зобов’язані дотримуватися таких же вимог до систем, як і банки. Оскільки в таких юриздикціях криптовалюти в більшості прирівнюються до електронних грошей, де діють такі ж правила ліцензування і слідуючі за цим вимоги до інфраструктури, систем, швидкодії, відмовостійкості і тд.
    Дійсно, за 2 роки індустрія пройшла мега апгрейд до рішень корпоративного рівня, що підтверджується роботою, наприклад, Mastercard з продуктами WIirex.

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

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

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

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

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

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

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

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