В банке всегда существовала и .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 и т.д.)
В банке в >95% используется только ReactJS
Деталей выбора фреймворка я вам не скажу, т.к. конкретно JavaScript framework был выбран не нами, а экспертами именно по JavaScript. Мы просто используем их выбор
Я постараюсь найти их контакты, которые смогут ответить на этот вопрос.
То есть, вы почему-то вместо повышения эффективности использования уже имеющегося инструмента стремитесь заменить и сам инструмент, и тех работников, которые должны его использовать. Если у вас уже была хорошая команда джавистов, то переучивание их на соседнюю, но менее развитую и сильно отличную в мелочах технологическую платформу — это неэффективно. Или они у вас настолько дорогие, что оказалось дешевле набрать с рынка новых?
Я нигде не писал, что мы переучиваем джавистов на дотнет. Джависты по прежнему и в большом количестве работают и требуются в банке на направлениях там, где они всегда и были и это отражено в основном статье:
И мы встали перед выбором — либо переписывать все это на Java, которая у нас исторически всегда была сильной стороной, да и до сих пор превалирует в рознице
Вопрос у нас скорее стоял переучивать .NET-чиков на JAVA с риском их ухода их банка вместе с экспертизой по ряду ключевых систем.
Поэтому сейчас ситуация такая, что и .NET развивается и Java развивается и никого принудительно ничему не переучивают, а наоборот стараются развивать оба направления.
— в банковском энтерпрайзе такого не бывает, это утопия. Никогда не поверю (я имею достаточно опыта, чтобы не поверить). Либо продукты, о которых идёт речь, нишевые, и далеко не основные для бизнеса.
Ну тут мне нечего сказать, ваш опыт — ваше право не верить. Могу лишь еще раз повторить, что такие команды есть и продукты вполне не нишевые.
За последнее время мы довольно ощутимо выросли в плане использования .NET. Если еще лет 5 назад дотнета в Альфе было не так много (в основном — в корпоративных приложениях, кредитовании корпоративного бизнеса, инвестиции и прочее), с такой нагрузкой справлялись примерно 16-20 человек. А сейчас в банке активно развиваются сегменты массового и среднего корпоративного бизнеса, что стало хорошим толчком к развитию кредитных систем.
И мы встали перед выбором — либо переписывать все это на Java, которая у нас исторически всегда была сильной стороной, да и до сих пор превалирует в рознице, либо продолжать развивать все на .NET, для чего пришлось бы нанимать кучу дотнетчиков и выходить для фронта на те же технологии, аналогичные для микросервисной архитектуры, что и на Java.
Но повторюсь, делалось это все ради того, чтобы сделать end-to-end продуктовые команды, где 1 full-stack разработчик (фронт + .NET) мог сделать полностью конечную фичу для клиента, в которой нужно будет поправить что-то и на фронте и на бэкэнде, который исторически был написан на .NET-те.
Также плюсом такого решения является то, что мы можем использовать сразу оба рынка специалистов и .NET и Java.
Альтернативой было:
Либо развивать .NET системы только как бэкэнд решения с сервисами, которые потом потреблялись бы middle системами на Java, что требует наличие в команде и Java и .NET разработчика для реализации полной end-to-end фичи для клиента. Так происходит в некоторых командах прямо сейчас и минус этого в необходимости двух разных компетенций в команде и иногда в коммуникации между разработчиками.
Либо переписывать все .NET системы на Java технологии, но это огромные косты т.к. системы огромные и эту идею отбросили почти сразу после ее оценки.
Касательно костылей, мы их потихоньку фиксим, а с появление новых версий .NET Core они явно будут уходить в прошлое.
Касательно проблем с производительностью — их замечено не было, .NET Core работает +- также как и Java Spring Boot, например. Это в целом подтверждают бенчмарки тут
Подскажите альтернативы?
Суть то задачи простая — есть куча компаний, которые проводят митапы, которые надо между собою согласовывать, чтобы и темы были максимально интересные/ уникальные и в течение года мероприятия были равномерно размазаны. При этом такие активности планируются заранее, а не по шелчку пальца, ведь нужно забронировать локацию, спикер должен быть не в командировке и не в отпуске и т.д.
Кто кроме MskDotNet занимается подобным для дотнета?
К сожалению все подобные мероприятия планируются заранее, площадки (в нашем случае она внешняя) арендуются и бронируются заранее, что лично мы сделали еще в Марте и перенести мы никак уже не сможем.
И чтобы специально наш митап не совпал с кем-то другим, мы заранее запланировали его с помощью коллег из MskDotNet, как это делают в том числе и другие банки (например Тинькофф, Сбербанк).
Почему так не сделал Райф и решил сделать единоличный митап, лично мне не понятно — возможно они могут перенести свой. Если же нет, то мой вам совет идите туда, где интереснее темы.
Я надеюсь это будем мы =)
В тех направлениях, где была сильна JAVA продолжилась использоваться JAVA, где был силен .NET — продолжился использоваться на .NET, только уже используя некоторые наработки JAVA направления и часть ее экосистемы — микросервисная архитектура, Docker, Apache Mesos, Ansible, Spring Boot Config Server, Jenkins и т.п.
Вы правы, можно было бы этого не делать и напротив бэкэндовых систем на .NET писать JAVA middle бизнес слой и не нанимать тех самых 25% .NET, а нанять такое же количество но JAVA. Но минусы у этого решения следующие и я их уже описывал:
+ к этому добавляется высоконкуретный рынок JAVA разработчиков с точки зрения работодателя (Yandex, Mail.ru, Tinkoff, Sberbank и т.д.)
Именно так в основном делали фронт в тех проектах, что я видел, где пытались использовать Angular (тогда еще 2 версии) вместе с .NET
Сейчас мы с ReactJs делаем именно так, как вы написали:
То, что также можно делать и с Angular, я не знал. Спасибо, что просветили.
Можешь ты подскажешь почему ReactJS, а не angular был выбран?
Деталей выбора фреймворка я вам не скажу, т.к. конкретно JavaScript framework был выбран не нами, а экспертами именно по JavaScript. Мы просто используем их выбор
Я постараюсь найти их контакты, которые смогут ответить на этот вопрос.
Я нигде не писал, что мы переучиваем джавистов на дотнет. Джависты по прежнему и в большом количестве работают и требуются в банке на направлениях там, где они всегда и были и это отражено в основном статье:
Вопрос у нас скорее стоял переучивать .NET-чиков на JAVA с риском их ухода их банка вместе с экспертизой по ряду ключевых систем.
Поэтому сейчас ситуация такая, что и .NET развивается и Java развивается и никого принудительно ничему не переучивают, а наоборот стараются развивать оба направления.
Ну тут мне нечего сказать, ваш опыт — ваше право не верить. Могу лишь еще раз повторить, что такие команды есть и продукты вполне не нишевые.
Но повторюсь, делалось это все ради того, чтобы сделать end-to-end продуктовые команды, где 1 full-stack разработчик (фронт + .NET) мог сделать полностью конечную фичу для клиента, в которой нужно будет поправить что-то и на фронте и на бэкэнде, который исторически был написан на .NET-те.
Также плюсом такого решения является то, что мы можем использовать сразу оба рынка специалистов и .NET и Java.
Альтернативой было:
Касательно костылей, мы их потихоньку фиксим, а с появление новых версий .NET Core они явно будут уходить в прошлое.
Касательно проблем с производительностью — их замечено не было, .NET Core работает +- также как и Java Spring Boot, например. Это в целом подтверждают бенчмарки тут
Я ответил на ваш вопрос?
Суть то задачи простая — есть куча компаний, которые проводят митапы, которые надо между собою согласовывать, чтобы и темы были максимально интересные/ уникальные и в течение года мероприятия были равномерно размазаны. При этом такие активности планируются заранее, а не по шелчку пальца, ведь нужно забронировать локацию, спикер должен быть не в командировке и не в отпуске и т.д.
Кто кроме MskDotNet занимается подобным для дотнета?
И чтобы специально наш митап не совпал с кем-то другим, мы заранее запланировали его с помощью коллег из MskDotNet, как это делают в том числе и другие банки (например Тинькофф, Сбербанк).
Почему так не сделал Райф и решил сделать единоличный митап, лично мне не понятно — возможно они могут перенести свой. Если же нет, то мой вам совет идите туда, где интереснее темы.
Я надеюсь это будем мы =)