• Wirex відкриває R&D-центри у Львові й Вроцлаві та шукає спеціалістів з України

    Привіт, Денис.
    Через пів року можемо зробити чекап, щоб відповісти на твоє запитання.
    Але хочу нагадати, що після складношів із залученням інвестиційв на початку 2019 року, ми змогли стабілізувати ситуацію до кінця 2019 року і повернути більшість людей в команду.
    А зараз, компанія залучила ще до війни 15 мільйонів доларів інвестицій (почитати можна тут — dou.ua/forums/topic/36453) та з кінця 2019 року прибуткова (що рідкість для компаній в цьому секторі).

  • Wirex відкриває R&D-центри у Львові й Вроцлаві та шукає спеціалістів з України

    Привіт, Юрій.
    Буде круто, якщо напишеш, що ж тебе конкретніше підштовхнуло до такого коментаря? Адже я не пригадую, щоб з нашої спільної роботи, коли ми почали роботу з тобою як з middle-level розробником, підчас бурхливого росту компанії 5 років назад (!), були хоча б натяки на токсичну та ватну атмосферу. Пригадую, що закінчили роботу з тобою вже в набагато вищій позиції та з дуже високим рівнем довіри.
    Дуже вдячний за розкриття справжніх причин, чому тоді розірвав тоді співпрацю, які ми так і не змогли зрозуміти в спільній розмові в 2018 році.
    Хочу поцікавитися, ти дійсно думаєш, що компанія не розвивалася всі ці 4 роки і проблеми зростання не виправили?
    Буду дуже вдячний, якщо поцікавишся справами у теперішньої команди IOS і напишеш більш актуальний коментар, по тому які справи зараз або хоча б як було до війни.

  • Софт из 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 в каждый релиз. Послностью раскрыть детали такого подхода планирем в следующей статье.