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 в принципе — пишите, буду рад ответить.
Автор: DINAMITmax
