Интервью с руководителем центра компетенции .NET на DotNext 2018

    22 и 23 ноября в Москве прошла очередная конференция DotNext 2018 для любителей .NET. Меня зовут Максим Смирнов, я руковожу центром компетенций .NET в Альфа-Банке и хочу представить вам текстовую версию одного из интервью, взятых в кулуарах DotNext.


    Про жизнь и приключения дотнета в нашем банке, про сосуществование с джавой и проблемы внедрения — под катом.

    Сколько в Альфе вообще .NET и для чего он нам нужен


    За последнее время мы довольно ощутимо выросли в плане использования .NET. Если еще лет 5 назад дотнета в Альфе было не так много (в основном — в корпоративных приложениях, кредитовании корпоративного бизнеса, инвестиции и прочее), с такой нагрузкой справлялись примерно 16-20 человек. А сейчас в банке активно развиваются сегменты массового и среднего корпоративного бизнеса, что стало хорошим толчком к развитию кредитных систем.

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

    Само собой, подобный переезд сразу оказался под угрозой, потому что риски [ применения новой технологии прим. ред.]. Но мы смогли взять эти риски на себя, мы доказали коллегам, что .NET вполне себе сможет адекватно работать на тех же кластерах и инфраструктурных решениях, на которых себя прекрасно чувствует Java. Здесь я имею в виду наш так называемый кластер “единого фронта”, Apache Mesos — Marathon. И мы стали делать фронтовые решения, включая мидловую часть для них. Фронт остался тем же самым, что и на Java, мидловая часть где-то оставалась на Java, где-то на .NET.

    И понеслось — 5 лет назад с .NET справлялись максимум 20 человек, а сейчас задач столько, что у нас таких бравых ребят уже 75. И мы продолжаем расширяться — сейчас ищем архитектора и еще разработчиков. Хоть Java все равно пока суммарно больше, раза в полтора-два, потому что она стабильно доминирует на розничном и массовом бизнесах. Мы же на .NET освоились в рамках корпоративного и среднего регионального, плюс электронные каналы еще, само собой.

    Проверить – доказать – внедрить


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

    Сложнее всего было с инфраструктурщиками. У нас было железобетонное требование от них — чтобы все это разворачивалось в докере и нормально работало в линуксе. А тут стоит отметить, что тогда еще не было .NET Core 2.0, тогда была только первая версия, в которой не было всего того добра, которое зарелизили во второй, в общем, получилось, что мы сами не знали точно, с какими именно подводными айсбергами можем столкнуться, но сказали, что все сделаем, как надо. Сумели доказать это и бизнесу, запустив первые пилоты — Альфа-Кредит, приложение для онлайн-кредитования, выдачи траншей и прочее.

    Затем доказывать состоятельность идеи пришлось и саппортерам. Им надо было объяснить, что им самим не надо знать .NET, чтобы сопровождать наши контейнеры (они почему-то были уверены в обратном). Доказали им, что проблем с производительностью не будет, я был одним из первых, кто собрал все это на кластере — мы разворачивали контейнер, снимали с него кучу метрик, смотрели, насколько сильно он грузит CPU, сравнивали все это с Java. У нас просто был код на Java в контейнере, который выдавал розничным клиентам справки. Ну мы для чистоты эксперимента сделали абсолютно такой же сервис, но на .NET, чтобы можно было честно сравнить их по производительности, по скорости отклика, по загрузке памяти. Я писал нагрузочные тесты для всего этого, в итоге — у нас все прокатило, и на данный момент в таком режиме работают 6 команд.

    Сейчас мы потихоньку избавляемся от легаси — оборачиваем его в сервисы и функционально переписываем на микросервисы.

    .NET Core VS .NET Framework


    Еще раз обращу внимание, что внедряли мы именно .NET Core. Поэтому остается ряд проблем в том плане, что какие-то клевые вещи в .NET-фреймворке есть, а в .NET Core их нет, причем нет и по сей день. Например, SOAP-сервисы.

    Вот представьте. Вы — банк, у вас есть одна система, которая потребляет другую. И потреблять она привыкла SOAP, а у тебя его нет. Вообще. Мы не нашли ни одной нормальной реализации WCF-сервисов с SOAP и подобными штуками. Может, плохо искали, все возможно. Поэтому пришлось изгаляться и писать прослойки на старом .NET Framework.

    Второй набор граблей — REST API. С новыми сервисами, где он реализован, проблем нет. А заставлять старые сервисы вместо SOAP использовать REST API это уже другая история, пришлось бы переписывать все другие зависимые системы. И снова прослойки, заплатки, костыли.

    А еще общение с очередями. У нас в Альфе активно используется IBM MQ, типичная энтерпрайз-шина очередей сообщений. Клиент под .NET Framework существует, нативный от IBM. А вот под .NET Core клиента у них нет. И, насколько мы знаем, не планируется. есть лишь реализация на открытом AMQP-протоколе, мы пытались общаться с очередями с ее помощью, но тоже был ряд проблем. Решение? Да, снова прослойки.

    В общем, у нас была итерация в попытках заставить все это добро нормально работать через AMQP-протокол и не тупить. Но парни из IBM отписались нам, мол, пардон, ребята, но он для нас deprecated, поэтому ну его. И что будут использовать только проприетарный протокол по определенным причинам. В общем, сидим теперь и думаем, как все это переделывать. Скорее всего, напишем свой клиент вместо IBM-овского, вот такой вот будет опенсорс.

    Фронт, .NET и NodeJS


    По большей части для фронта мы используем React JS, он работает с нодой нормально. Когда мы только начинали, у нас был ряд старых MVC-шных проектов. Там приходилось фронт прокидывать, чтобы server side рендеринг сделать нормальный, через ReactJS.NET.

    Сейчас мы подобного избегаем, решили отделить мух от котлет, в итоге вышло, что есть отдельно фронт с нодой, и что NodeJS использует наши сервисы на rest api в web app. И, собственно, все. На .NET мы реализуем уже миддл. А жесткой связки, как я наблюдал с .NET и Angular, что прям вообще их никак не разделить, мы не делаем специально, потому что стремимся к развитию у людей специализаций.

    Если ты хорошо знаешь чисто фронт, то можешь смело идти с java-командой писать для нее фронт. Это удобно, ты таким образом можешь перетекать из команды в команду. А если ты знаешь фуллстек, ты можешь делать приложения end-to-end. И бекенд с .NET, и мидл, и фронт на реакте. У нас тут получился единый стандарт технологий.

    Интеграция с мобилками


    Ее у нас не так много. Там, где есть, это просто использование наших сервисов на web api. Сами мобильные приложения на .NET мы не пишем, даже попыток не было. Нативные все равно лучше делать. Если можешь сразу взять и написать нативное — лучше сразу взять и написать. Да, есть полезные штуки типа Xamarin от Microsoft, но это имеет смысл, когда тебе нужен быстрый универсальный старт. А вот если стоит вопрос с удобством приложения под каждую платформу, с производительностью, ты все равно пойдешь уже и будешь нормально писать нативное. И у нас нативные были изначально.

    Про сопротивление новому


    Когда у тебя большая компания (да даже просто несколько команд), то всегда при внедрении новых инструментов будут недовольные. Вообще всегда, это нормально. Художники, которые так видят, и вот это все.

    Когда ты сверху внедряешь что-то не очень популярное, или что-то, что не нравится разрабам, у людей всегда найдется куча способов саботировать процесс, да еще и показать в процессе, какой же ты идиот, что все это затеял. У нас так было, когда мы внедряли StyleCop для .NET. Но со временем его все равно все приняли и сейчас активно юзают. Помогла простая аргументация — настройки от StyleCop это довольно общепринятые вещи. В итоге получается красивый и более или менее понятный всем код. Хотя, есть у меня подозрение, парочка разрабов таки все ещё точат зуб. Ведь у всех свои стандарты, у всех свое понимание красоты кода, свои любые редакторы и приемы.

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



    Конечно, если писать все в визуалке, этот вопрос вообще снимается.

    Кто-то у нас пишет код в Visual Studio, а кто-то — нет. Мы когда переходили на кластер, выяснилось, что там ряд технологий есть, которые не работают под виндой. Например, Ansible. Клиентская часть на винде есть, а вот серверную уже не поднять. Поэтому или иди и поднимай виртуалку на линуксе, или просто делай все на линуксовом серваке.

    В общем, так и живем. Если у вас есть какие-то вопросы насчет .NET в банке, да и .NET в принципе — пишите, буду рад ответить.
    Альфа-Банк
    170,00
    Компания
    Поделиться публикацией

    Комментарии 13

      0
      Так и не понял из статьи, каков конечный профит от внедрения .net. Вы много пишете про героические костыли и преодоление сопротивления коллег, но что именно стало лучше? Приложения потребляют меньше ресурсов, быстрее работают, требуют меньше обслуживания (в статье есть намёки, что как раз наоборот) — что из этого?

      Слишком часто повторяется слово «внедрять», но нет ответа, зачем менять привычное шило на недоваренное мыло. Инструмент должен выбираться под задачи, а не по принципу «мы можем, и поэтому будем».
        +3
        Зачем дотнет, я раскрывал здесь:
        За последнее время мы довольно ощутимо выросли в плане использования .NET. Если еще лет 5 назад дотнета в Альфе было не так много (в основном — в корпоративных приложениях, кредитовании корпоративного бизнеса, инвестиции и прочее), с такой нагрузкой справлялись примерно 16-20 человек. А сейчас в банке активно развиваются сегменты массового и среднего корпоративного бизнеса, что стало хорошим толчком к развитию кредитных систем.

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


        Но повторюсь, делалось это все ради того, чтобы сделать end-to-end продуктовые команды, где 1 full-stack разработчик (фронт + .NET) мог сделать полностью конечную фичу для клиента, в которой нужно будет поправить что-то и на фронте и на бэкэнде, который исторически был написан на .NET-те.
        Также плюсом такого решения является то, что мы можем использовать сразу оба рынка специалистов и .NET и Java.

        Альтернативой было:
        1. Либо развивать .NET системы только как бэкэнд решения с сервисами, которые потом потреблялись бы middle системами на Java, что требует наличие в команде и Java и .NET разработчика для реализации полной end-to-end фичи для клиента. Так происходит в некоторых командах прямо сейчас и минус этого в необходимости двух разных компетенций в команде и иногда в коммуникации между разработчиками.
        2. Либо переписывать все .NET системы на Java технологии, но это огромные косты т.к. системы огромные и эту идею отбросили почти сразу после ее оценки.


        Касательно костылей, мы их потихоньку фиксим, а с появление новых версий .NET Core они явно будут уходить в прошлое.

        Касательно проблем с производительностью — их замечено не было, .NET Core работает +- также как и Java Spring Boot, например. Это в целом подтверждают бенчмарки тут

        Я ответил на ваш вопрос?
          +1

          Ответили, но логика вашего ответа мне малопонятна.


          Вот вы говорите


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

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


          Касательно


          делалось это все ради того, чтобы сделать end-to-end продуктовые команды, где 1 full-stack разработчик (фронт + .NET) мог сделать полностью конечную фичу для клиента

          — в банковском энтерпрайзе такого не бывает, это утопия. Никогда не поверю (я имею достаточно опыта, чтобы не поверить). Либо продукты, о которых идёт речь, нишевые, и далеко не основные для бизнеса.


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

            +2
            То есть, вы почему-то вместо повышения эффективности использования уже имеющегося инструмента стремитесь заменить и сам инструмент, и тех работников, которые должны его использовать. Если у вас уже была хорошая команда джавистов, то переучивание их на соседнюю, но менее развитую и сильно отличную в мелочах технологическую платформу — это неэффективно. Или они у вас настолько дорогие, что оказалось дешевле набрать с рынка новых?

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

            Вопрос у нас скорее стоял переучивать .NET-чиков на JAVA с риском их ухода их банка вместе с экспертизой по ряду ключевых систем.

            Поэтому сейчас ситуация такая, что и .NET развивается и Java развивается и никого принудительно ничему не переучивают, а наоборот стараются развивать оба направления.

            — в банковском энтерпрайзе такого не бывает, это утопия. Никогда не поверю (я имею достаточно опыта, чтобы не поверить). Либо продукты, о которых идёт речь, нишевые, и далеко не основные для бизнеса.

            Ну тут мне нечего сказать, ваш опыт — ваше право не верить. Могу лишь еще раз повторить, что такие команды есть и продукты вполне не нишевые.
              –2
              Вы опять не поняли вопроса. Вот была Java, большая команда, «сильная сторона». Потом стали что-то писать на C# (или на чем там) и набрали аж 25% спецов от общего кол-ва программистов. Вопрос — зачем? Почему не продолжали испорльзовать Java и ее экосистему? Или мы что-то не поняли?
                +2
                В банке всегда существовала и .NET (> 8 лет) и JAVA, просто в различных направлениях бизнеса.
                В тех направлениях, где была сильна JAVA продолжилась использоваться JAVA, где был силен .NET — продолжился использоваться на .NET, только уже используя некоторые наработки JAVA направления и часть ее экосистемы — микросервисная архитектура, Docker, Apache Mesos, Ansible, Spring Boot Config Server, Jenkins и т.п.

                Вы правы, можно было бы этого не делать и напротив бэкэндовых систем на .NET писать JAVA middle бизнес слой и не нанимать тех самых 25% .NET, а нанять такое же количество но JAVA. Но минусы у этого решения следующие и я их уже описывал:
                Либо развивать .NET системы только как бэкэнд решения с сервисами, которые потом потреблялись бы middle системами на Java, что требует наличие в команде и Java и .NET разработчика для реализации полной end-to-end фичи для клиента. Так происходит в некоторых командах прямо сейчас и минус этого в необходимости двух разных компетенций в команде и иногда в коммуникации между разработчиками.

                + к этому добавляется высоконкуретный рынок JAVA разработчиков с точки зрения работодателя (Yandex, Mail.ru, Tinkoff, Sberbank и т.д.)

        0
        Давно мучает вопрос, но до этого момента я не знал кого спросить. Но обо всем поп порядку.
        Вы банк, а это значит, что вы как никто другой заботитесь о скорости загрузки страницы и в случае ssr, её выдачи. И раз вы упомянули о том что работаете и с react и с angular, то значит обязательно должны были производить замеры сравнения производительности. Кто быстрее? Кто быстрее на клиенте и при ssr? Это, конечно, если вы о angular, а не angularjs…
          +2
          В банке в >95% используется только ReactJS
          Деталей выбора фреймворка я вам не скажу, т.к. конкретно JavaScript framework был выбран не нами, а экспертами именно по JavaScript. Мы просто используем их выбор
          Я постараюсь найти их контакты, которые смогут ответить на этот вопрос.
            +4
            serpentcross, привет!
            Можешь ты подскажешь почему ReactJS, а не angular был выбран?
              0
              DINAMITmax, сорри что так поздно отвечаю)) — не мог никак залогиниться. Хабр писал, что — «нет такого email» :D

              А теперь делу: На самом деле, всё сводится к банальному выбору архитектора, который работал в лабе с самого начала. Он типа сказал, что «а я вот только реакт знаю, давайте на нём делать».
              Хотя я ещё подозреваю, что тут имело место быть то, что всё таки нам нужен был прежде всего уровень представления (UI), и реакт как нельзя лучше его реализует. А ангуляр это аж целый MVC :)
          +1
          А жесткой связки, как я наблюдал с .NET и Angular, что прям вообще их никак не разделить
          — что???
          Единственная жесткая связка — это при реализации Universal SSR на базе .Net core, что на мой взгляд не лучший выбор, в остальном нет никаких жестких связок. Или вы про извращенное желание совместить работу Razor и Angular? — так такие извращения чаще с React делают(ибо его поставить сбоку легче).
          Лучшие вариант это: .net core Web Api и отдельный фронт на Nginx/Node (Angular,React и т.д/SSR)
            +1
            Ключевая фраза в моем сообщение:
            как я наблюдал

            Именно так в основном делали фронт в тех проектах, что я видел, где пытались использовать Angular (тогда еще 2 версии) вместе с .NET

            Сейчас мы с ReactJs делаем именно так, как вы написали:
            Лучшие вариант это: .net core Web Api и отдельный фронт на Nginx/Node (Angular,React и т.д/SSR)

            То, что также можно делать и с Angular, я не знал. Спасибо, что просветили.
            0
            Изложу лишь факты и рекомендации:
            1) в статье нет конкретики и полезных знаний, которые можно применить в других проектах (в будущем пишите более детально и конкретно по знаниям, а также подкрепляйте свои выводы конкретными данными и цифрами и четким описанием как делали сравнение)
            2) текст не отредактирован должным образом-очень много выпячивания с Я (старайтесь обезличивать, ведь заслуга всегда командная, даже если Вы это сделали-лучше всего аккумулировать это с командой, тем более Вы-руководитель, а значит должны быть едины с командой
            3) «доверяй своей команде» (то, чего не умеете сами-делегируйте тому, кто умеет, в частности здесь текст стоит отдать на редактирование имеющим опыт в публикациях людям)
            4) не сопротивляйтесь критике (как Вы и сами писали в статье «художник видит», но для объективной оценки всегда нужно все свои выводы подкреплять фактами и конкретикой (см п 1), а также всегда подвергать все авторитеты и выводы сомнениям и перепроверять их лично прежде чем что-то советовать и уж тем более публиковать)
            5) вот хороший пример статьи, которая похожа на Вашу: habr.com/ru/post/437610
            6) Вас читают и Ваши подчиненные (так пишите статьи так, чтобы это вызывало гордость в их умах, а не выглядело как голый пиар себя самого), и весь русскоязычный интернет (так пишите статьи так, чтобы описанные знания и опыт могли люди применить в своих работах)
            Желаю Вам совершенствоваться и избавляться от сильного себялюбия, т к Вы ответственны за своих подчиненных. Так будьте достойным руководителем во всем

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое