golang

Как мы создавали PaaS-платформу App.Farm — цифровое сердце РСХБ

  • вторник, 2 июля 2024 г. в 00:00:12
https://habr.com/ru/companies/rshb/articles/825816/

Привет, Хабр! Меня зовут Константин Белкин, я 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.

Пишите в комментариях, если остались вопросы.