Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

.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-протоколе, мы пытались общаться с очередями с ее помощью, но тоже был ряд проблем. И, насколько мы знаем, не планируется. Да, снова прослойки. Решение?

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

Теги
Показать больше

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

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

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

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