Как мы создавали 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;
Генератор докерфайлов;
Адаптеры интеграций;
Инструментарий деплоя на платформу.
Для удобства работы с приложениями и сервисами, размещенными в 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;
Интеграция с Каталогом по LADP;
Гибкая консоль администрирования и мощный 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.
Пишите в комментариях, если остались вопросы.
Habrahabr.ru прочитано 1670 раз
