Обновления продуктов Технологии

PaaS-платформа App.Farm. Как продукт помогает развивать высококритичные системы Россельхозбанка

760
PaaS-платформа App.Farm. Как продукт помогает развивать высококритичные системы Россельхозбанка

Константин Белкин

Teamlead SRE в РСХБ‑Интех

App.Farm — PaaS‑платформа, которая разрабатывается собственными силами и поддерживается в Россельхозбанке с сентября 2020 года. Основная цель внедрения данного продукта — формирование условий для импортозамещения высококритичных информационных систем РСХБ, стимулирование развития собственной разработки. Мы стремимся к минимизации зависимости банка от вендорных решений и их аутсорсинговой поддержки, развитию внутренних компетенций по обслуживанию и поддержке ПО, а также созданию всех необходимых условий для внутренних разработчиков банка.

PaaS‑платформа App.Farm также преследует регуляторную цель — переход на импортозамещеные решения и открытое ПО и отказ от проприетарных решений, которые были внедрены в банке в прошлых десятилетиях.

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

App.Farm построен на принципах и методологиях GitOps и IaC. Они, в свою очередь, преследуют принцип — все есть код (Everything as Code) EaC. На текущий момент в App.Farm развернуто более 60 систем/сервисов банка, которые ежедневно генерируют поток не менее 50 миллионов сообщений и запросов в день. Для централизованной работы с нашим решением был адаптирован 21 вендорский продукт и проведено 290 внешних интеграций для 30 внешних потребителей.

Вы могли слышать про App.Farm на различных конференциях, видеть упоминания в статьях на Хабре или СМИ, но как таковой цельной презентации мы еще не делали. Пришло время рассказать, что такое App.Farm, и поделиться планами на будущее. Решение очень масштабное, поэтому в этой статье я представлю общие моменты, особенности и компоненты платформы. В будущем мы разберем каждый из них подробнее.

Итак, поехали.

История, цели и задачи

Работа над решением началась в 2020 году. Цели были поставлены глобальные, но реализуемые, хоть и работы предстояло немало. Нужно было централизовать разработку информационных систем для РСХБ из так называемого «зоопарка» из вендоров и разрозненных систем и улучшить внутренние процессы.

  • Снижение Time-to-market выпуска версий за счет постепенного перехода к модели PaaS (Platform as a Service).
    • В этой модели вся деятельность по организации разработки продукта предоставляется «как услуга»: инструменты работы с исходным кодом и релизами, процессы сборки и проверки кода, процессы развертывания ПО, сбор и просмотр телеметрии, аутентификация / авторизация в приложениях, интеграция разных протоколов взаимодействия, БД, очереди, кэши и т.д.
  • Увеличение пропускной способности и возможности масштабирования при возрастающей нагрузке на Интеграционную подсистему. 
  • Избавление от привязки к вендору и снижение затрат за счёт уменьшения стоимости владения решением.
    • На старом интеграционном решении помимо высокой стоимости непосредственно лицензий существовали еще ежегодные отчисления на поддержку решения вендору. 
  • Стандартизация процессов разработки в рамках всего банка и консолидация разработки в единой среде.
    • Проработка и внедрение правил для стандартизации: процессов внутренней разработки, соглашений по написанию исходного кода в зависимости от стека, подходов для работы с телеметрией бизнес-приложений, эксплуатации и сопровождения бизнес-приложений, создания и сопровождения интеграционных взаимодействий.

По итогу нам нужно было представить готовый инструментарий, позволяющий:

  • Хранить и совместно использовать исходный код;
  • Проверять исходный код на качество и уязвимости;
  • Собирать, публиковать и использовать артефакты;
  • Разворачивать в различных средах готовые бизнес-приложения;
  • Устанавливать интеграционные взаимодействия по различным протоколам.

Немаловажным аспектом работы была и есть автоматизация. Одна из главных целей — минимизация человеческого фактора и бюрократии в процессах, что как раз благодаря автоматизации и решается. А это значит, предстояло сделать:

  • Готовые согласованные сетевые схемы;
  • Автоматическое открытие сетевых доступов;
  • Работа с информационной безопасностью в автоматизированном режиме;
  • Автоматизированный процесс согласования интеграционных потоков;
  • Автоматизированная сборка и доставка бизнес-приложений до продуктива;
  • Автоматизированное развертывание приложений.

Мы взялись за работу с нуля в сентябре 2020 года. И в первоначальной версии продукта была поддержка следующего набора инструментов:

  • Gitlab и базовые CI/CD процессы для основных популярных языков разработки (Java, Kotlin, JS) построенные на Gitlab CI;
  • Ресурсные аллокации CPU и RAM;
  • Описание Систем и Сервисов as Code;
  • Поддержка развертывания Deployment;
  • Хранение в единой системе хранения логов и метрик;
  • Поддержка типовых интеграций HTTP-to-HTTP и MQ.

В июне 2021 года App.Farm уже была выведена в промышленную эксплуатацию. Вторая половина 2021 года ознаменовалась глобальными обновлениями и доработками платформы. Мы успели внедрить и запустить кучу полезных и необходимых вещей: 

  • Появилась поддержка: .NET Core, проектов с использованием Lerna, деплоя проектов, собранных вне платформы, интеграционных (e2e) тестов, встроенная в конвейер CI/CD, сложных (с трансформацией) и композитных адаптеров в платформе, поддержка доставки (CDL) произвольных типов standalone-артефактов.
  • Выход CI/CD в промышленную эксплуатацию.
  • Анонсирование overlay подсетей через BGP.
  • Контроль ресурсной квоты подразделения в платформе.
  • Пользовательские (кастомные) дашборды в подсистеме мониторинга.
  • Kafka as a Service
  • Autoscailing

В 2022 году к этому списку добавились: редактирование сущностей платформы на портале, обратная связь от конвейера CI/CD о развертывании сущностей платформы и введение в эксплуатацию функционала распределенной трассировки. Ключевым нововведением этого года стала работа над собственным решением DisasterRecovery для улучшения катастрофоустойчивости банка.

Компоненты платформы и архитектура

App.Farm — это платформа, состоящая из различных инфраструктурных компонентов, работающих вместе. Эти компоненты инкапсулированы в платформу и являются ее неотъемлемыми частями. Т.е. App.Farm не предоставляет Kubernetes или другие компоненты в состав платформы как сервис. Вместо этого есть API самой платформы, за которым могут скрываться различные компоненты. Мы их можем менять на любые другие без необходимости уведомлять, договариваться и мигрировать системы, которые стали от этого зависеть напрямую.

App.Farm построена на следующем стеке открытых решений:

  • Kubernetes;
  • Gitlab;
  • OpenSearch;
  • Grafana;
  • Jaeger;
  • Istio;
  • VictoriaMetrics;
  • и других открытых продуктах.

А также на инструментах собственной разработки:

  • Россыпь платформенных операторов Kubernetes;
  • Генератор докерфайлов;
  • Адаптеры интеграций;
  • Инструментарий деплоя на платформу.

Для удобства работы с приложениями и сервисами, размещенными в App.Farm, разработан информационный портал управления сущностями платформы. Он используется разработчиками, архитекторами, тестировщиками, ИТ-менеджерами и инженерами систем банка для получения актуальной информации в разрезе различных контуров разработки банка, о полном состоянии своих сервисов и приложений, размещенных на платформе.

Среда исполнения приложений платформы App.Farm, использующая под капотом Kubernetes, позволяет разворачивать сервисы и информационные системы, а также создавать интеграционные связи между сервисами. Решение построено на базе комплекса из более чем 30 open source компонентов, а также технологий: Java, Go, Python, .net (C#), Kotlin, JavaScript, TypeScript, NodeJS, React, Angular, OCI-Image.

Используемый в платформе конвейер разработки CI/CD регламентирует единые стандарты кода и архитектуру разработки для всех разрабатываемых и внедряемых решений, что позволяет в значительной степени уменьшить сроки поставки до продуктива, повысить качество и безопасность информационных систем банка. За счет единого подхода и стандартов разработки и архитектуры в платформе App.Farm поддерживается единый SLA на все размещенные информационные системы. Систему могут иметь свой SLA, но мы предлагаем качественный SLA одного слоя в объеме 99.85%. Кроме того, платформа задает единый подход и стандарты к разработке и архитектуре для всего банка, предоставляя единую службу сопровождения (SRE).

Для поддержания работы платформы у нас есть обширная документация по возможностям, где очень подробно описаны требования и рекомендации для разработчиков. Кроме того, мы регулярно проводим обучение и митапы, чтобы облегчить коллегам работу в App.Farm, открыли чат с техподдержкой, анонсами и отдельный канал для публикации обновлений платформы.

Основные компоненты

Среда исполнения: Kubernetes + Istio 

Kubernetes — это внутренний инфраструктурный компонент платформы, используемый в качестве среды исполнения приложений. У пользователей отсутствует прямой доступ в Kubernetes, размещать в нем приложения и управлять ими может только платформа. Пользователь может не знать ничего о существовании Kubernetes, он взаимодействует с ним через инструменты платформы (например, «Портал»).

Istio — это Service Mesh для Kubernetes, реализуемый на базе паттерна Sidecar, то есть перед каждым сервисом в Kubernetes запускается небольшой прокси-сервис, который пропускает через себя весь входящий и исходящий трафик. Это позволяет нам выполнять с ним любые манипуляции — инспектировать, контролировать, шифровать, дополнять или урезать, авторизовывать, журналировать и так далее.

Service Mesh управляет трафиком между сервисами, диагностирует ошибки. Он предназначен для решения задач через контроль над взаимодействием сервисов друг с другом. В частности: динамическое обнаружение сервисов, маршрутизация и управление трафиком, шифрование, аутентификация и авторизация, сбор метрик и мониторинг, трейсинг http, управление исходящим трафиком (istio‑egressgateway). Service Mesh очень полезен при большом количестве сервисов и наличии каскадных коммуникаций между ними. Также за счет istio‑egressgateway‑контроллеров упрощается управление исходящим трафиком за счет применения политик сетевого доступа к внешним ресурсам.

Kubernetes и Istio вместе предоставляют огромное количество возможностей, которые не нужно реализовывать приложениям самостоятельно, такие как: 

  • Запуск и управление контейнерами, оркестрация;
  • Изоляция приложений и управление вычислительными ресурсами;
  • Обнаружение сервисов;
  • Балансировка трафика;
  • Масштабирование приложений;
  • Различные стратегии обновления и отката.

А также предоставляют такие возможности как:

  • Интроспекция трафика и контроль сетевых взаимодействий;
  • Двухстороннее шифрование графика;
  • Сервисная сетка – возможность получать информацию о всех приложениях и их взаимодействиях;
  • Интеграция с другими инфраструктурами компонентами: трассировка, логирование, мониторинг;
  • Аутентификация и авторизация сервисов.

Мониторинг: VictoriaMetrics + Grafana

У нас в платформе стек мониторинга представляет собой:

  • В качестве БД – Victoria Metrics (Cluster);
  • В качестве коллектора – VMAgent;
  • В качестве средства отображения: Grafana.

Для пользователей есть прямой доступ только к Grafana, позволяющий смотреть показатели своих приложений и создавать дашборды. При этом дашборды деплоятся в виде кода из git-репозиториев проектов.

Изначально в платформе для мониторинга использовался Prometheus. Но, ввиду развития платформы, появился ряд проблем с высоким потреблением ресурсов, низкой производительностью и отсутствием мультиарендности. Нам удалось произвести бесшовный для пользователей переход на другой стек мониторинга, заменив Prometheus на VictoriaMetrics.

Журналирование: Vector + OpenSearch + Kibana

В платформе для журналирования используются следующие компоненты: 

  • OpenSearch — в качестве БД;
  • vector — в качестве коллектора журналов;
  • Kibana — в качестве средства отображения данных.

На текущий момент есть ряд проблем с производительностью и потреблением ресурсов в стеке логирования. Часть из них решилась заменой коллектора: fluentd на vector. По лицензионным причинам также пришлось заменить ElasticSearch на OpenSearch. Для пользователей эти изменения произошли незаметно, потому что пользователи имеют прямой доступ только к Kibana чтобы запрашивать и просматривать логи своих приложений и интеграции.

Распределенная трассировка: Istio + Jaeger + Clickhouse

В App.Farm для трассировки используются следующие компоненты:

  • Jaeger — в качестве системы распределенной трассировки, включающий: jaeger-collector — для сбора трейсов и размещения их в БД; jaeger-query — предоставляет API для работы с трейсами; jaeger-ui — WEB-интерфейс для анализа трейсов, доработанный нами, чтобы пользователи могли авторизовываться под своими учетными данными и могли видеть трейсы только своих приложений (к которым у них есть доступ);
  • Clickhouse — в качестве БД для хранения трейсов, позволяющий выполнять SQL запросы и строить аналитические запросы для анализа трейсов. В качестве WEB UI для просмотра используется Grafana;
  • Istio — в качестве Service Mesh, благодаря которому спаны формируются и отправляются в коллектор автоматически из sidecar, без необходимости создавать спаны в пользовательских приложениях.

Изначально в платформе в качестве хранилища трейсов использовался OpenSearch. Но, ввиду развития платформы, появился ряд проблем с высоким потреблением ресурсов, низкой производительностью и отсутствием возможности делать гибкие аналитические запросы над данными. Нам удалось произвести бесшовный для пользователей переход на другое хранилище трейсов, заменив OpenSearch на Clickhouse.

Авторизация: KeyCloak + Istio + PostgreSQL 

Обычно для реализации аутентификации и авторизации требуется система, позволяющая управлять учетными данными и доступами. Кроме того, такая система должна поддерживать популярные стандарты аутентификации и авторизации. Есть несколько систем, обеспечивающих такую функциональность, например: Keycloak, Ory, Okta и ZITADEL.

Но в условиях банка требуются дополнительные возможности: интеграция с единым каталогом по LDAP, открытый исходный код решения, Self-Hosted инсталляция и большое и активное community. С учетом этих условий мы выбрали Keycloak как наиболее подходящий нам вариант, который уже, по сути, является стандартом для решения таких задач и имеет широкое применение в сообществе. 

В платформе в качестве системы аутентификации и авторизации используется Keycloak, который в числе прочих обладает следующими возможностями:

  • Поддержка Single-Sign On;
  • Поддержка OpenID Connect, OAuth 2.0, SAML 2.0;
  • Интеграция с Каталогом по LDAP;
  • Гибкая консоль администрирования и мощный REST-API.

В качестве БД Keycloak использует Postgres, который является инфраструктурным компонентом и развернут внутри App.Farm. Istio используется в качестве Service Mesh, благодаря которому на уровне sidecar можно настроить аутентификацию и RBAC-авторизацию с помощью конфигурации. Без необходимости реализовывать в коде пользовательских приложений проверку JWT-токенов и контроль доступа.

Разработка ПО: Gitlab + Nexus + PostgreSQL + Minio

В платформе для разработки ПО используются следующие компоненты:

  • Gitlab — в качестве системы для разработки ПО, включающей хранилище кода, управление доступами, работу с задачами, инструмент для ревью кода, интеграцию с CI и т.д. Для своей работы использует БД: PostgreSQL — для хранения данных; Minio — для хранения объектов; Redis — для кэширования и хранения очереди заданий.
  • Gitlab CI — в качестве инструмента CI;
  • Nexus — в качестве хранилища артефактов.

Интеграция: Istio + Calico + Kafka + Active MQ Artemis

Обычно в крупных организациях существует множество бизнес-систем, которые требуется интегрировать между собой. Одним из популярных способов решения этой задачи является интеграционная шина, по которой все взаимодействуют. В платформе App.Farm мы поддержали обратную совместимость с интеграционной шиной, которая существовала до появления платформы. Также были поддержаны дополнительные способы интеграции, такие как: HTTP(S) 1.1 / 2, gRPС, Kafka и ActiveMQ Artemis.

Для наблюдаемости и контроля взаимодействий в App.Farm используются:

  • Calico — инструмент для контроля сетевых взаимодействий;
  • Istio — Service Mesh, который благодаря sidecar, может шифровать HTTP-трафик посредством mTLS, за счет этого пользовательские приложения взаимодействуют по HTTP, хотя на самом деле это будет HTTPS; а также благодаря Envoy-фильтрам позволяет инспектировать и журналировать HTTP-трафик.

Особенности платформы

Open Source технологии 

Платформа полностью построена на технологиях с открытым исходным кодом и свободной лицензией, позволяющей использовать такие технологии в коммерческом ПО. Преимущества: бесплатно, публичный код, понятно, что происходит, безопасно (открытый код можно проверить), нет блокировки на поставщике ПО (вендоре), мы можем вносить изменения в код, а также тренд на использование открытого ПО.

Так как платформа построена на открытых технологиях, то и продукты, запускаемые в платформе, преимущественно должны быть opensource. Это касается как самих бизнес-приложений, так и используемых инфраструктурных компонент для его работы. Поэтому при онбординге новых продуктов в App.Farm мы отдаем предпочтение системам с открытым кодом и opensource-инфраструктурой.

Multitenancy

Multitenancy (мультиарендность) — элемент архитектуры ПО, при котором единый экземпляр приложения обслуживает множество организаций, подразделений или команд. В App.Farm большая часть инфраструктуры, которая обслуживает платформу и предоставляется пользователям, является мультиарендной.

Преимущественно для инкапсуляции в платформу мы выбираем мультиарендные приложения, это нас приводит к тому, что:

  • Мы экономим вычислительные ресурсы: в реалиях банка довольно сложно оперативно масштабировать вычислительные ресурсы, для их получения нужно предоставить весомые обоснования, смоделировать сайзинг, а также ожидать долгое время на согласование и поставку; 
  • Проще обслуживать и сопровождать один общий экземпляр приложения, чем множество экземпляров под каждое подразделение или команду;
  • Переиспользование общей конфигурации и данных;
  • Возможность интеграции тенантов между собой.

Ниже представлен перечень мультиарендной инфраструктуры App.Farm, обслуживающей все подразделения РСХБ-Интех. Это приложения, позволяющие настроить изоляцию отдельных групп-потребителей на уровне одного экземпляра, а также предоставляющие гибкую ролевую модель для настройки доступов:

  • Keycloak (рилмы/клиенты);
  • Gitlab (группы/проекты);
  • Nexus (репозитории/каталоги);
  • Sonarqube (проекты);
  • ActiveMQ Artemis (адреса/очереди);
  • Kubernetes (неймспейсы);
  • Стек логирования (индексы);
  • Стек мониторинга (индексы).

GitOps + IaC + Flow

GitOps — это методология разработки ПО, в основе которой лежит правило, что «все есть код». Это означает, что при развертывании приложений не используется никаких ручных действий по настройке или конфигурированию, все должно описываться декларативно в виде кода под управлением системы контроля версий и применяться с помощью инструментов CI/CD. 

Мы придерживаемся такого подхода не только для пользовательских приложений, но и для разработки самой платформы, в том числе ее инфраструктурных компонентов (IaC — infrastructure as code).

В платформе App.Farm как код поставляются:

  • Исходный код приложений;
  • Конфигурация приложения (переменные окружения, вычислительные ресурсы, метаданные, информация о масштабировании, способ обновления и многое другое). Исключением являются секреты (логины/ пароли/ключи и т.д.) — они хранятся в специальном хранилище секретов Vault, а в исходном коде на них необходимо ссылаться;
  • Документация;
  • Дополнительная конфигурация в виде файлов, необходимая приложениям (например, XML-схемы);
  • Дашборды мониторинга;
  • Зависимости от других сервисов (runtime-связи);
  • Информация об использовании баз данных;
  • Роли, правила доступа к эндпоинтам;
  • Брокеры и топики Kafka;
  • Используемый приложением CI/CD Flow.

Платформа предоставляет готовые наборы CI/CD. Мы их называем CI/CD Flow. Они подключаются пользователями в свой репозиторий парой строк словно плагин.

Полный Flow обычно состоит из следующих этапов:

  • Проверка проекта на соответствие требованиям платформы;
  • Сборка артефакта и контейнера по исходному коду;
  • Проверка исходного кода на соответствие общепринятым в сообществах стандартам: поиск ошибок или «плохого» кода;
  • Запуск тестов и формирование отчета о результатах тестирования и уровень покрытия кода тестами;
  • Проверки безопасности исходного кода, зависимостей и контейнера;
  • Публикация собранного контейнера и/или артефакта в реестр артефактов;
  • Развертывание приложения в одном из окружений платформы.

С недавнего времени мы стали поддерживать специализированный OCI-Flow, который позволяет запускать готовые контейнеры приложений на платформе. То есть мы готовы поддержать любое приложение, упакованное в образ и предоставленное нам вендором или разработчиком, сформированное по нашим правилам и стандартам.

При онбординге новых продуктов в платформу App.Farm мы отдаем предпочтения тем разработкам, которые используют поддерживаемые в App.Farm технологии. Если потенциальный продукт использует неподдерживаемую нами технологию, то предварительно мы выполняем оценку и планирование этой технологии, а только после этого разработчик сможет продолжить онбординг продукта.

Мы предлагаем переходить на App.Farm CI/CD и готовые flow без необходимости их модификации под специфику подрядчика, подразделения или команды, которая там сложилась за время работы. То есть желательно укладывать приложения в универсальные тиражируемые flow, правила для которых сформировало мировое сообщество, а не отдельная команда.

Декларативность

Под декларативностью мы понимаем описание конечного результата в виде заданной спецификации, то есть мы описываем результат, а не шаги по его по получению. В качестве примера приведем декларативное описание сервиса на платформе:

В платформе существуют спецификации для декларативного описания различных сущностей: Подразделения и их Ресурс-пулы, Система, Сервис, Связь, Доступ к базе данных, Kafka-кластеры и Kafka-топики, Очереди Artemis, и т.д. — это API платформы. Все эти сущности декларируются в git-репозиториях, имеют историю и контроль доступа — можно узнать состояние на любой момент времени. С помощью CI/CD выполняется приведение состояния в кластере к декларируемому в спецификации.

Таким образом, в платформе недоступна модификация сущностей платформы, либо из низкоуровневых составляющих, средствами пользовательских приложений. Например, сервисов / подов, сетевых доступов, ролей и разрешений. Кроме того, недоступно исполнение произвольного кода, так как код должен предварительно собираться и проверяться в контуре разработки, а затем переиспользоваться в продуктиве. При онбординге нужно обращать внимание на совместимость потенциальных систем с таким декларативным подходом к разработке.

Механизмы интеграции

Интеграция на платформе является одной из основных функциональных возможностей App.Farm. 

Интеграция, простыми словами, — это способ взаимодействия приложений или систем между собой. Зачастую системы, которые разворачиваются в App.Farm требуют для своей работы взаимодействия с: 

  • Другими бизнес-системами в платформе и в контуре банка;
  • Инфраструктурами компонентами платформы;
  • Инфраструктурами компонентами банка (например, базы данных);
  • Сервисами, расположенными в сети Интернет.

В App.Farm поддерживаются следующие способы интеграции:

  • Межсервисная интеграция внутри одной системы, размещенной в App.Farm: HTTPS (HTTP/1.1, HTTP/2, gRPC, WebSocket) и Kafka;
  • Межсистемная интеграция, в случае нахождения обеих систем в App.Farm: HTTPS (HTTP/1.1, HTTP/2, gRPC, WebSocket) и Kafka;
  • Интеграция с сервисами в интернете: HTTPS (HTTP/1.1, HTTP/2, gRPC, WebSocket).

Что касается способов интеграции, то это: 

  • Интеграция с корпоративными инфраструктурными сервисами, находящимся вне App.Farm: HTTPS (HTTP/1.1, HTTP/2, gRPC, WebSocket); SMTP; SMB;
  • Интеграция с бизнес-системами, находящимися вне App.Farm: HTTPS (HTTP/1.1, HTTP/2, gRPC, WebSocket), Kafka и Интеграционная шина (На базе ActiveMQ Artemis)

Особенностью интеграционного взаимодействия в App.Farm является запрет по умолчанию на все сетевые взаимодействия, даже внутри одной системы. Проще говоря, вы из своего сервиса никуда не сможете обратиться. Чтобы открыть сетевой доступ, разработчику необходимо задекларировать в своем проекте интеграционную связь (link), в которой указать, куда он хочет обращаться и по какому протоколу.

Благодаря интеграционным связям (link) платформа знает полный граф зависимостей систем и сервисов. Это информация публичная и отображается на Портале управления платформой. Кроме того, механизм связей позволяет владельцам систем знать, кто зависит от их сервисов и кто их использует. При желании владельцы систем могут запретить устанавливать связи к их системам, предоставляя такое разрешение после согласования.

Аутентификация и авторизация

В платформе App.Farm для аутентификации и авторизации пользователей и приложений используется единый SSO-провайдер, построенный на базе Keycloak, я рассказывал об этом ранее. Преимущественно в качестве стандарта аутентификации используется OIDC. Платформенная система авторизации служит для авторизации разработчиков, их приложений, а также пользователей их приложений. В том числе на базе платформенной системы авторизации построена система РСХБ ID.

Система авторизации App.Farm интегрирована с корпоративным каталогом по протоколу LDAP, в котором хранится информация о пользователях и группах. App.Farm постоянно синхронизуется с каталогом, благодаря чему имеет актуальную доменную информацию.

При онбординге новых продуктов необходимо обращать внимание на несколько моментов, связанных с аутентификаций и авторизацией. В приоритете продукты:

  • использующие OIDC-авторизацию, которые могут переиспользовать нашу платформенную авторизацию;
  • использующие инфраструктуру, которая может быть интегрирована с нашей платформенной авторизацией по OIDC;
  • готовые переиспользовать платформенные механизмы управления ролями и доступа к эндпоинтам. Стоит избегать системы, использующие неподдерживаемые в платформе методы и протоколы авторизации.

Формат поставки приложений

Многие продукты для РСХБ по-прежнему разрабатывают подрядчики. При этом разрабатываемые ими продукты могут по-разному лицензироваться и предоставляться клиенту. Например, мы сталкивались со следующими форматами поставки: исходный код продукта, собранный бинарный артефакт, Docker-образ.

В зависимости от формата поставки, платформа App.Farm может иметь ту или иную свободу действий при работе с таким продуктом. Например, когда подрядчик поставляет исходный код, платформа его может:

  • Полностью проанализировать на уязвимости;
  • Проанализировать качество кода;
  • Применить тиражируемые flow для сборки и запуска;
  • Гарантировать, качество работы собранного приложения, т.к. оно собирается платформой;
  • Возможность дорабатывать продукт самостоятельно (если позволяет лицензия), например, экстренно исправить ошибку, пока это не сделал подрядчик.

При онбординге новых продуктов в App.Farm мы отдаем предпочтение продуктам, поставляемым в виде исходного кода, а также лицензиям, позволяющим работать с таким исходным кодом и вносить в него изменения. В случае, если поставка исходного кода невозможна, следующим по приоритету идет поставка в виде бинарного артефакта. Например, для Java приложений это может быть набор jar-файлов. Если же и бинарный артефакт не поставляется подрядчиком, то остается вариант в виде поставки OCI-образа, но с соблюдением наших требований по формированию и правилам подготовки и работы образа/приложения.

Итоги, возможности и планы на будущее

С внедрением App.Farm стек разработки и поддержки стал более строгим, теперь нет зоопарка технологий. Автоматизация и переход всего банка на единые подходы CI/CD дали возможность сделать кросс-функциональные команды, которые знают, что, перейдя из одной команды в другую можно просто начать писать код.

Уменьшен кост разработки ПО за счет снижения порога входа в технологический стек разработки. На текущий момент в системе: 2300 пользователей (CI/CD), 197 систем, 3300 интеграционных потоков. PaaS-платформа App.Farm обеспечивает 6.5 млн событий в час и более, а также поддерживает более 12 вариантов\типов интеграций. Отсутствует Vendor Lock-in. Внешние подрядчики не принимают участие в разработке.

Сейчас благодаря универсальности и удобству платформы в App.Farm:

  • обслуживается 612 микросервисов, 50 внутренних и 147 внешних систем;
  • обрабатывается 2296 связей и 2800 интеграционных запросов в секунду.

Кроме того, для централизованной работы с решением к App.Farm был адаптирован 21 вендорский продукт и проведено 290 внешних интеграций через OpenAPI функциональность для 30 потребителей.

В ближайшем будущем у нас в планах внедрение:

  • S3 as a Service;
  • Redis as a Serviсe;
  • PostgreSQL as a Service;
  • Развитие возможностей деплоймента на платформе: поддержка Stateful-приложений, App Review, Canary / Blue-Green Deployment.

Дополнительную информацию о продукте также можно узнать, посмотреть материалы нашего вебинара «Платформы для быстрой разработки, тестирования и развертывания ПО».

Похожие записи

R-Style Softlab вывела на рынок коннектор «Цифровой профиль организации» на российском стеке технологий

Новости компании Обновления продуктов Технологии

R-Style Softlab, компания-разработчик ПО для финансовой сферы и системный интегратор, входящий в группу Россельхозбанка, вывела на рынок модуль для взаимодействия с ГИС (коннектор) «Цифровой профиль организации», реализованный на российском технологическом стеке. Модуль RS-Connect «Цифровой профиль организации» — готовое решение для быстрого получения информации об организациях (юридических лицах, индивидуальных предпринимателях), содержащейся в информационных системах государственных органов. […]

207

Автоматизация банка: процессы, технологии, импортозамещение

Обновления продуктов Технологии Тренды

Автоматизация банковской системы — это внедрение информационных технологий, которые позволяют минимально задействовать человека в банковских процессах. Компьютерные программы умеют выполнять многие рутинные задачи, которые раньше делали люди — например, проверять кредитную историю, рассчитывать проценты по вкладам и кредитам, составлять документы, общаться с клиентами.  Ключевым инструментом для перехода к полной цифровизации становятся автоматизированные банковские системы (АБС) […]

356

Поставки российского инфраструктурного оборудования в «РСХБ – Управление Активами»

Новости компании Обновления продуктов

В рамках сотрудничества  были поставлены программно-аппаратные комплексы российского вендора НОРСИ-ТРАНС,  внесенные в реестр промышленной продукции  Минпромторга России. Компания «НОРСИ-ТРАНС» —  российский разработчик и производитель серверного оборудования, систем хранения данных на различных платформах, телекоммуникационного оборудования и вычислительных платформ, входит в число вендоров партнерского хаба R-Style Softlab. Компания специализируется на разработке и выпуске серверного оборудования, высокоплотных систем […]

960