Привет! Меня зовут Александр Камчатнов, я — технический архитектор Интеграционной платформы Лемана Тех. Сегодня я расскажу, как мы ее создали и как развиваем. Не буду объяснять, что такое REST, Kafka, какие бывают контракты и типы взаимодействий — предполагаю, что читатель и так знаком с предметной областью. Вместо этого я сфокусируюсь на том, как мы строим интеграционную платформу, помогаем командам сфокусироваться на бизнесе, а компании — не упасть в микросервисный ад.
Исторически в Лемана Тех была (и остается) очень сильная архитектурная и интеграционная команда. Это позволило нам провозгласить движение в сторону композитной архитектуры если не до того, как это стало трендом, то как минимум на очень ранних этапах жизни концепции.
В контексте статьи важно, что композитная архитектура делает акцент на API-first подходе. Иными словами, провозглашает ценность хорошо спроектированных интерфейсов взаимодействия между сервисами и проектирование от интерфейса к коду — это требует определенных процессов и технологий, возложенных на интеграционную платформу.
В нашей компании одним из краеугольных принципов развития продуктов, является “You Build It, You Run It”, руководствуясь им, мы пришли к следующей важной парадигме: интеграционная платформа — это не централизованная ESB с командой разработки интеграций и не суповой набор из библиотек-адаптеров, а полноценный SaaS со своими правилами, технологиями, командой поддержки и много-много чем еще. То есть мы не проектируем ни за кого API и не реализуем за команды интеграционные потоки, мы предоставляем инструментарий и лучшие практики для этого.
Более того, наша интеграционная платформа — не просто внедренная система класса API Management и не Swagger UI, встроенный в систему ведения документации. Это стратегическое направление, вокруг которого мы строим множество процессов проектирования, разработки и поддержки цифровых продуктов.
Наша платформа стоит на трех китах:
Методология;
Этап разработки;
Этап выполнения.
Если взглянуть на это с другой стороны, платформа реализует два верхнеуровневых паттерна — основные направления нашей деятельности:
API Платформа предоставляет методологию и инструментарий для создания, публикации, поиска и рантайма API. Включает в себя Developers Portal, Kong API Gateway, Kafka и RabbitMQ, который мы считаем legacy, но выключить полностью не можем.
Платформа приложений позволяет реализовать интеграционные шаблоны с помощью low-code инструментария, деплоить их в отказоустойчивом режиме со встроенными мониторингом, трейсингом и разными другими плюшками из коробки и без погружения разработчика в DevOps машинерию.
Звучит немного запутанно из-за обилия слова «платформа», но таково историческое наследие, еще не подвергшееся ребрендингу.
Чтобы было проще понять: слева на картинке каталог API, а справа — low-code студия, где из этих API (а также других коннекторов и блоков) можно собирать интеграционные сценарии, например ACL (Anti-corruption layer) или BFF (Backend-for-frontend).
Как же все это работает? А вот как.
Начнем с методологии
На нулевом шаге мы как центр компетенции формулируем и поддерживаем в актуальном состоянии стандарты интеграций, которым команды обязаны следовать. Если не вдаваться в детали, то это:
Стандарты:
обязательность публикации API на API Платформе;
разрешенные технологии (REST через Kong API Gateway и Kafka);
форматы описания API (OpenAPI для Kong и AsyncAPI для Kafka);
однозначное владение API и привязка API к бизнес-сущностями;
правила именования объектов, топиков, полей и т. д.;
правила вложенности объектов, пагинации, использования типов;
рекомендуемые паттерны, особые случаи, и т. д.
Гайды:
по работе с инструментарием (портал, low-code платформа);
по процессам согласований;
по применению методологию API-first в повседневной жизни разработчика или аналитика.
Лучшие практики:
паттерны работы с Kafka;
правила работы с кодами ошибок в REST;
рецепты и готовые шаблоны для оркестратора на Platformeco.
Почему это важно? Да потому, что одно дело — опубликовать на гейтвее эндпоинт, а совсем другое — масштабировать подход на большую компанию и дать продуктовым командам кубики (API), из которых они могут собирать новые процессы. Мы стараемся, чтобы команды проектировали API не по наитию и не по случайным статьям из интернета, а опираясь на свои бизнес-сущности. Чтобы они учитывали владение данными, заранее продумывали, как будут подключаться новые потребители и расширяться набор данных. Как ни странно, но это только самая верхушка айсберга из вопросов, которые команды оставляют без ответа, и на которые отвечаем мы.
Для Лемана Тех стандарты интеграции — одна из основ проектирования, позволяющая компании выстраивать процессы владения и обмена данными.
Разработка и проектирование
На основе наших стандартов продуктовые команды сами проектируют контракты API и публикуют их на Developers Portal, где те проходят обязательный этап согласования.
За основу мы взяли REST подход и взаимодействия между продуктами строим вокруг хорошо определённых ресурсов, избегая сильной связности продуктов по сущностям, которыми они оперируют.
В ходе согласования архитектор и представитель API платформы проверяют контракт на соответствие правилам. Очевидно, что мы не следим за наличием тех или иных обязательных полей или следованию naming conventions — за это отвечает линтер от Spectral с нашими внутренними правилами. Согласующих интересует принадлежность сущностей в API цифровому продукту, связь с моделями из дата-каталога, непересекающиеся сущности, данные, которые будут доступны во внешней сети и т. д. В общем, все, что может повлиять на зависимость между продуктами, масштабируемость и безопасность.
Надо также понимать, что согласование — не столько формальная процедура прохождения «вахтера», сколько помощь командам в проектировании их сервисов. То есть с погружением в предметную область, рекомендациями и сессиями совместного дизайна. Конечно, это довольно затратное по времени мероприятие, но, по опыту, аналитики, которые 1-2 раза опубликовали свои контракты совместно с нами, в следующие разы справляются намного быстрее и с минимальной помощью.
Когда контракт согласован и опубликован, он становится доступен как в поиске на портале, так и на API Gateway. Пользователь при этом получает возможность работать с несколькими средами, мигрировать API между ними, настраивать простейшие политики трансформации и роутинга, а также включать/выключать конкретные роуты. При этом мы сознательно сильно ограничиваем возможность кастомизации политик на API Gateway, полагая, что это ведет к «размазыванию» бизнес-логики и пересечению зон ответственности.
Примерно такая же функциональность доступна для асинхронных API на Kafka — с той лишь разницей, что пользователь оперирует не роутами, а топиками. Политики же относятся не к роутингу, а к партициям и аналогичным деталям, связанным с особенностями транспорта. В остальном UX очень схожий, а нашей конечной целью является унификация пользовательского пути для любых видов API.
На этапе имплементации API пользователь может написать микросервис на одном из языков из техрадара компании или воспользоваться нашей Платформой приложений, основанной на продукте компании Platformeco. Не секрет, что этот продукт зародился внутри нашей команды, развился и выделился в независимого вендора. Мы продолжаем использовать и предлагать Platformeco как инструмент лучшего выбора для работы с интеграционными задачами, реализующими такие паттерны, как:
агрегация;
API mashup;
обогащение запросов;
ACL (Anti-corruption Layer) вокруг устаревших монолитных или коробочных решений, а также
BFF (backend-for-frontend) для формирования experience API, существующих с одной единственной целью — предоставить выразительный API для фронтальных приложений.
Очевидно, что подобные сценарии сборки процесса из существующих API требуют хорошего каталога, который мы также предоставляем на портале разработчика. Там хранятся все версии API с контрактами, связями с дата-каталогом, историей изменений, привязкам к командам и ответственным, эндпоинтами тестовых и продакшн сред, описаниями, а также заявленными нефункциональными характеристиками — SLO (время ответа по 95 и 99 перцентилю и доступность в «девятках»).
Мы осознанно приняли решение отказаться от решений зарубежных вендоров (опять же, до того как это стало трендом) и развивать свой портал разработчика — для того, чтобы иметь максимальную гибкость в автоматизации процессов управления интеграциями, каталогизацией, согласования, в синхронизации с учетными системами согласований компании и подключения дополнительных медиаторов. Имея за плечами опыт работы с крупнейшими игроками рынка (Google Apigee, IBM API Connect) и open source проектами (типа Gravitee), мы поняли, что проще написать самим, чем пытаться кастомизировать процессы тяжеловесных коробок или open source полуфабрикатов.
Runtime
Как я уже говорил, принцип “You Build It, You Run It” обязывает нас быть ответственными за собственные решения в продакшене. Поэтому команда сама отвечает за работоспособность всего рантайма, через который работают цифровые продукты. Сейчас в продакшене:
Я не буду вдаваться в детали, потому что каждая из них достойна отдельной полноценной статьи — особенно те, что касаются рантаймов оркестраторов, подсистем для сбора и хранения метрик с трейсами и мощнейшей CI/CD машинерии. Могу лишь сказать, что совокупно этот слой обслуживает подавляющее большинство бизнес-потоков, и привести некоторые цифры:
Работая с такими цифрами и понимая уровень критичности, мы создали команду поддержки с ночными дежурствами, мониторингами и алертами, а также выстроили процессы реагирования и поддержки — от чат-бота, которому можно сообщить о проблеме и эскалировать в случае кризиса, до передачи сложных случаев на третью линию и дальнейшего расследования с последующими фиксами.
При этом мы видим огромную ценность хорошо выстроенного, отказоустойчивого интеграционного слоя далеко за пределами просто интеграции — и выстраиваем процессы со смежными командами для получения максимального «выхлопа» от дополнительных слоев между системами. Например:
В 2024 году совместно с централизованной командой Observabiltiy на основе данных с Kong API Gateway запустили процесс контроля SLO, в котором считаются метрики выполнения командами обязательств по доступности и отзывчивости API. Мы запустили этот процесс, чтобы стимулировать команды улучшать качество сервиса и повышать ответственность через механизмы заявления SLO и сопоставление с реальными SLI.
Мы храним и предоставляем пользователям детальную информацию по выполнению запросов через Kong API Gateway — инструмент номер один для SDM/SRE продуктов при расследовании или онлайн-разборе сложных инцидентов.
С помощью богатой встроенной функциональности Platformeco по телеметрии команды могут самостоятельно настраивать алерты по метрикам и разбирать проблемы по трейсам.
По данным с портала мы строим карту интеграций и зависимостей между цифровыми продуктами, которую потом используют архитекторы и аналитики для анализа взаимного влияния продуктов и понимания связи между ними.
Мы планируем тесную интеграцию с Платформой данных — чтобы автоматически поставлять туда качественные данные в каноническом формате с минимальными усилиями для продуктовых команд, тем самым упростить и удешевить создание аналитических отчетов и витрин.
Запуск в ближайшее время портала открытых API Лемана Тех для партнеров и мерчантов маркетплейса предоставит удобную и актуальную информацию о доступных функциям коллегам из компаний-контрагентов.
Напоследок
Надеюсь, прочитавшие и осознавшие этот лонгрид составили для себя некоторое представление о том, почему Лемана Тех и наша команда инвестируют немалые усилия в создание Интеграционной платформы — и чем мы отличаемся от классической ESB.
Со стороны может показаться, что у нас все готово и можно спокойно пить чай, поглядывая на то, как зеленеют графики в графане, и ругаться на тех, кто нарушает стандарты компании — это не наш путь. Наши амбиции выше, а цели на ближайшее время лежат в плоскости интеграции в глобальный процесс создания ценности — от проектирования до сбора данных для продуктового анализа. Наша мотивация — быть не просто еще одним вахтером quality gate, а приносить ощутимую пользу продуктовым командам через процессы проектирования, повышение технологической культуры, удобные инструменты и данные, которые есть у интеграционной платформы. Но об этом — в следующий раз.