Привет!
Когда спрашивают, чем современная IT-компания отличается от финтеха с точки зрения разработки, чаще всего на ум приходит стек. Оно и ясно, ведь финтех и банки — это процессинг, гора легаси, множество систем, которые обновляются не так быстро, как хотелось бы. И возникает ощущение, что именно из набора легаси и необходимости работать на тех версиях софта, которые вам показывал ещё преподаватель в институте, и состоит привычный для финтеха стек.
Как обычно, всё немного не так, как кажется на первый взгляд. Под катом мы расскажем о 6 самых распространенных заблуждениях, о том, как всё работает у нас в Альфе, и причём тут Alfa Battle.
На восьмёрке мы стали писать примерно лет 5 назад, это была первая версия нашего интернет-банка, собранного на микросервисной инфраструктуре. И сейчас это минимально используемая версия, обычные будни же — это 13 и 11.
В чем польза:
Чтобы разработчик не скучал в ожидании сборки проекта и мог заняться решением более интересных задач, для старта java-приложения мы используем jvm-параметры (например, *RAMPercentage), что позволяет быстро задавать размер памяти в процентах, отталкиваясь от памяти контейнера, и оптимизировать работу приложения в нем.
А ещё мы храним в распакованном виде JAR-архивы, чтобы закешировать часто используемые библиотеки, которые не применяются от сборки к сборке, и в целом ускорить запуск проекта. Раньше старт контейнера со Spring Boot занимал 40 секунд, теперь — 15. Сейчас думаем попробовать JEP 351 ZGC Uncommit Unused Memory (Java 13), чтобы ещё больше оптимизировать работу сервисов.
Подробнее о Java в Альфе мы будем рассказывать на стриме нашего онлайн-чемпионата Alfa Battle, он будет вот на этой странице 27 июня (суббота).
У нас Mesos Marathon и более 10 больших Mesos-кластеров под проекты банка, которых несколько сотен. И всё бы ничего, но современным требования разработки Mesos отвечает, прямо скажем, с трудом. Возможен ли переход в рамках банка на новый оркестратор?
Возможен. Сейчас у нас на этапе активного пилота Kubernetes, чтобы управлять стендами тестирования, масштабированием сервисов и сетевыми доступами более гибко. А ещё каждый разработчик в зависимости от собственного чувства прекрасного сможет создать свою среду тестирования со всеми зависимостями. А если к Kubernetes ещё и Istio добавить, то мы оперативно закрываем вопрос шифрования данных и аутентификации между сервисами, причем в рамках кластера.
Тут правильнее будет сказать, что в финтехе тоже есть легаси. Потому что финтех — это про деньги, есть множество больших и сильно связанных между собой кусков системы, которые должны работать, и работать стабильно. Пойти и переписать всё на проверенный свежак — это отличная идея, в принципе. Но для этого надо всё несколько раз проверить: все взаимозависимости, возможности масштабирования, отказоустойчивость, возможные проблемы проектирования. В общем, вы это всё и так знаете. Потому что если попытка перескочить на какую-то свежую цифру в версии софта вызовет какой-то общий сбой, это будет не очень хорошая история.
Поэтому частично монолитное легаси все еще с нами, но мы продолжаем расколупывать его на микросервисы. Понемногу, аккуратно и с напильником вместо перфоратора, но процесс идет. И опять же, это если говорить о «возрастных» и критичных проектах. Новые же проекты сразу пишутся на Java 11 и 13, Kotlin, SpringBoot 2, Kafka, Project Reactor / Spring WebFlux.
Если честно, не очень ясно, откуда в принципе взялся такой миф, но мы его часто слышим. Само собой, без корпоративной почты вряд ли обходится хоть одна большая компания. Нужны же, как минимум, общий календарь со слотами времени, списки контактов, и все это на приемлемом уровне безопасности. Поэтому да, у нас есть корпоративная почта, которая используется для сугубо официальных переписок, конфиденциальной информации и прочих околобюрократических штук.
Самый же рабочий с точки зрения активности канал в Альфа-Банке — это Slack. Причем используем там почти всё, что только дает делать сервис: напоминания, уведомления, привязки к тестовым средам, алерты от мониторинга и многое другое. Это реально удобно.
Без рассказов о вендорах и их попытках подсадить корпорации на себя, чтобы каждое изменение тех или иных функций было платным, не обходится почти ни один рассказ о корпорациях. Но это не значит, что мы используем только вендорские дорогостоящие системы мониторинга (хотя и их тоже).
Но ещё у нас есть Zabbix, например. Микросервисы же мониторятся с помощью Grafana, Micrometer и Prometheus. Последний, кстати, подкупил нас тем, что возможностей там уйма, а интеграция при этом довольно проста. Вообще, мониторинга много не бывает, и с помощью Prometheus мы мониторим почти всё, включая лаг синхронизации Kafka-кластеров через MirrorMaker.
Судя по ситуации на рынке, это сильно зависит от банка. Мы пошли по пути пайплайнов на Jenkins и Bamboo. Когда процесс доставки в достаточной мере автоматизирован с помощью CI/CD, то почти никогда не нужны дополнительные письма, согласования, заявки и прочее добро. То есть, процесс выглядит примерно так:
И всё. Затем мы поэтапно раскатываем новые фичи на большее количество пользователей. Исключение из такого правила составляет только процесс открытия новых функций разом на огромный сегмент клиентов, тут уже имеет смысл дополнительно обсудить план релиза с отделами нагрузочного тестирования и сопровождения систем.
Как мы уже писали, скоро пройдёт Alfa Battle, онлайн-чемпионат по прикладному программированию на Java от нас и наших партнеров — Билайн, X5 Retail Group и Jug.ru.
Если хотите присоединиться и попробовать свои силы — вот страница регистрации. Отбор ещё идёт, до 25 июня.
Если же хочется просто посмотреть, то 27 июня будет стрим, с 12.00 до 18.00.
Когда спрашивают, чем современная IT-компания отличается от финтеха с точки зрения разработки, чаще всего на ум приходит стек. Оно и ясно, ведь финтех и банки — это процессинг, гора легаси, множество систем, которые обновляются не так быстро, как хотелось бы. И возникает ощущение, что именно из набора легаси и необходимости работать на тех версиях софта, которые вам показывал ещё преподаватель в институте, и состоит привычный для финтеха стек.
Как обычно, всё немного не так, как кажется на первый взгляд. Под катом мы расскажем о 6 самых распространенных заблуждениях, о том, как всё работает у нас в Альфе, и причём тут Alfa Battle.
Миф #1. Банки используют только старые версии Java, 6–8
На восьмёрке мы стали писать примерно лет 5 назад, это была первая версия нашего интернет-банка, собранного на микросервисной инфраструктуре. И сейчас это минимально используемая версия, обычные будни же — это 13 и 11.
В чем польза:
- Получаем быстрый доступ к новым JEP и возможность использовать новые фичи сразу, без задержек при переходе на новую версию.
- Оптимизируем работы в docker-контейнере.
- Получаем более функциональные стримы с каждым релизом.
Чтобы разработчик не скучал в ожидании сборки проекта и мог заняться решением более интересных задач, для старта java-приложения мы используем jvm-параметры (например, *RAMPercentage), что позволяет быстро задавать размер памяти в процентах, отталкиваясь от памяти контейнера, и оптимизировать работу приложения в нем.
А ещё мы храним в распакованном виде JAR-архивы, чтобы закешировать часто используемые библиотеки, которые не применяются от сборки к сборке, и в целом ускорить запуск проекта. Раньше старт контейнера со Spring Boot занимал 40 секунд, теперь — 15. Сейчас думаем попробовать JEP 351 ZGC Uncommit Unused Memory (Java 13), чтобы ещё больше оптимизировать работу сервисов.
Подробнее о Java в Альфе мы будем рассказывать на стриме нашего онлайн-чемпионата Alfa Battle, он будет вот на этой странице 27 июня (суббота).
Миф #2. Оркестраторы помнят доллар по 30
У нас Mesos Marathon и более 10 больших Mesos-кластеров под проекты банка, которых несколько сотен. И всё бы ничего, но современным требования разработки Mesos отвечает, прямо скажем, с трудом. Возможен ли переход в рамках банка на новый оркестратор?
Возможен. Сейчас у нас на этапе активного пилота Kubernetes, чтобы управлять стендами тестирования, масштабированием сервисов и сетевыми доступами более гибко. А ещё каждый разработчик в зависимости от собственного чувства прекрасного сможет создать свою среду тестирования со всеми зависимостями. А если к Kubernetes ещё и Istio добавить, то мы оперативно закрываем вопрос шифрования данных и аутентификации между сервисами, причем в рамках кластера.
Миф #3. Финтех — это легаси
Тут правильнее будет сказать, что в финтехе тоже есть легаси. Потому что финтех — это про деньги, есть множество больших и сильно связанных между собой кусков системы, которые должны работать, и работать стабильно. Пойти и переписать всё на проверенный свежак — это отличная идея, в принципе. Но для этого надо всё несколько раз проверить: все взаимозависимости, возможности масштабирования, отказоустойчивость, возможные проблемы проектирования. В общем, вы это всё и так знаете. Потому что если попытка перескочить на какую-то свежую цифру в версии софта вызовет какой-то общий сбой, это будет не очень хорошая история.
Поэтому частично монолитное легаси все еще с нами, но мы продолжаем расколупывать его на микросервисы. Понемногу, аккуратно и с напильником вместо перфоратора, но процесс идет. И опять же, это если говорить о «возрастных» и критичных проектах. Новые же проекты сразу пишутся на Java 11 и 13, Kotlin, SpringBoot 2, Kafka, Project Reactor / Spring WebFlux.
Миф #4. Финтех — это корпоративная почта only и запрет других коммуникаций
Если честно, не очень ясно, откуда в принципе взялся такой миф, но мы его часто слышим. Само собой, без корпоративной почты вряд ли обходится хоть одна большая компания. Нужны же, как минимум, общий календарь со слотами времени, списки контактов, и все это на приемлемом уровне безопасности. Поэтому да, у нас есть корпоративная почта, которая используется для сугубо официальных переписок, конфиденциальной информации и прочих околобюрократических штук.
Самый же рабочий с точки зрения активности канал в Альфа-Банке — это Slack. Причем используем там почти всё, что только дает делать сервис: напоминания, уведомления, привязки к тестовым средам, алерты от мониторинга и многое другое. Это реально удобно.
Миф #5. Если мониторинг — то вендорский и дорогой
Без рассказов о вендорах и их попытках подсадить корпорации на себя, чтобы каждое изменение тех или иных функций было платным, не обходится почти ни один рассказ о корпорациях. Но это не значит, что мы используем только вендорские дорогостоящие системы мониторинга (хотя и их тоже).
Но ещё у нас есть Zabbix, например. Микросервисы же мониторятся с помощью Grafana, Micrometer и Prometheus. Последний, кстати, подкупил нас тем, что возможностей там уйма, а интеграция при этом довольно проста. Вообще, мониторинга много не бывает, и с помощью Prometheus мы мониторим почти всё, включая лаг синхронизации Kafka-кластеров через MirrorMaker.
Миф #6. Любая доставка на продакшн в банке — это бюрократический ад
Судя по ситуации на рынке, это сильно зависит от банка. Мы пошли по пути пайплайнов на Jenkins и Bamboo. Когда процесс доставки в достаточной мере автоматизирован с помощью CI/CD, то почти никогда не нужны дополнительные письма, согласования, заявки и прочее добро. То есть, процесс выглядит примерно так:
- Разработчик запускает процесс.
- Проходят автоматические тесты.
- Инженер саппорта одобряет раскатку на прод.
- Новая функция улетает на ограниченное количество пользователей.
И всё. Затем мы поэтапно раскатываем новые фичи на большее количество пользователей. Исключение из такого правила составляет только процесс открытия новых функций разом на огромный сегмент клиентов, тут уже имеет смысл дополнительно обсудить план релиза с отделами нагрузочного тестирования и сопровождения систем.
Alfa Battle
Как мы уже писали, скоро пройдёт Alfa Battle, онлайн-чемпионат по прикладному программированию на Java от нас и наших партнеров — Билайн, X5 Retail Group и Jug.ru.
Если хотите присоединиться и попробовать свои силы — вот страница регистрации. Отбор ещё идёт, до 25 июня.
Если же хочется просто посмотреть, то 27 июня будет стрим, с 12.00 до 18.00.
