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

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