Продукты

Зачем они нужны и какие функции они выполняют.

Всем привет! Меня зовут Антон, я инженер команды, отвечающей за развитие централизованныхIT-сервисов, которыми пользуются продуктовые команды вX5RetailGroup.

В этой статье я расскажу осистемах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использоватьданный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.

Что такое системы API Management

Определение

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

С другой стороны, API Management - это набор инструментов и сервисов, которые позволяют разработчикам и компаниям создавать, анализировать, применять и масштабировать интерфейсы API в безопасных средах.

В данных вариантах определения понятия "API Management" мы видим, что это процессы и системы позволяющие публиковать внутренние API сервисов, прописывать им определенные политики обработки запросов и ответов, контролировать доступ и анализировать статистику использования и производительности. Также рядом могут располагаться несколько подсистем, которые организуют выполнение необязательных функций, но интересных с точки зрения других подразделений, например монетизация API.

Зачем еще один огород городить?

Необходимость этого класса систем возникла в связи с увеличением количества сервисов, которые могут предоставлять свое API как конечный продукт для других сервисов. Ничего не напоминает? Правильно - микросервисная архитектура. Для организации это возможность ускорения "цифровизации". Владельцы продукта публикуют API, документацию к ней и прочие документы типа: планов развития, лимиты и т.д. Также всем хочется контролировать качество работы API, а это уже анализ производительности, статистика использования, проведение все возможных маркетинговых исследований и простой мониторинг. Для коллег из информационной безопасности будет интересно осуществлять наблюдение за использованием API в части контроля доступа: авторизация, аутентификация, аудит, проверка по черным/белым спискам IP. Для аналитиков и тестировщиков возможно будет интересна функциональность проверки корректности запросов, проверка корректности JSON или динамическое изменение запросов, для DevOps инженеров возможность установки rate limit, чтобы не было DoS конечного сервиса, настройка кэша и возможность оптимизации сервиса под микросервисную архитектуру: Service Discovery, Load Balancing, Blue/Green или Canary deploy.

Архитектура сервиса

В архитектуру сервиса API Management обычно входят (см. рис. 1):

1. Management Core: ядро системы, которое отвечает за формирование политик, планов, работу точками входа и выхода, настроек API Gateways и API, настройку CORS, Failover, Healthcheck, формирование запросов на отображение статистики использования API и логов.

2. Web/Development Portal: отвечает за UI, отображение настроек, статистики использования API, healthcheck и логов, а также позволяет общаться разработчикам, администраторам и владельцам API.

3. API Gateways: шлюзы или прокси, они отвечают за обработку запросов от клиентов сервиса согласно установленных настроек и политик, ведение логов запросов и ответов, а также запуск healthcheck по Backend API.

4. Backend API: отвечает за обработку запросов согласно бизнес-логике конечного сервиса.

5. Databases: в части сервиса API Management, хранят данные по настройке API, API Gateways, логи запросов клиентов и ответы backend, healthcheck, данные мониторинга практически всех компонентов API Management.

Плюсы и минусы систем API Management

У данных систем есть несколько преимуществ:

• Абстракция: система упрощает сложность сервисов под ним и предоставляет клиентам единый опыт.

• Аутентификация:система позволяет пройти аутентификацию, в том числе и через сторонние службы, например Keycloak.

• Управление трафиком: система регулирует входящий и исходящий трафик API.

• Мониторинг API: система может помочь в мониторинге запросов/ответов клиента.

• Преобразования: система позволяет преобразовать запросы/ответы API.

К минусам можно отнести:

• Увеличение Latency: шлюзу необходимо время для обработки запросов/ответов согласно настроенным политикам.

• TCO: Совокупная стоимость владения для всей цепочки поставки ценности, естественно будет больше, чем просто установить nginx и выставить его наружу.

APIGateways

API Gateways работают как единая точка входа в ЦОД (центр обработки данных), группу распределенных служб или сервисов (см. рис. 2). Также API Gateways могут использоваться для связи между двумя продуктами/сервисами, развернутыми в одном ЦОД. API Gateways принимают вызовы от клиентов, обрабатывают их согласно политикам/правилам и направляют их в соответствующие сервисы. Чтобы API Gateways могли максимально быстро обрабатывать запросы от клиентов их делают максимально легковесными, с использованием асинхронных фреймворков. API Gateways, как правило, работают только на седьмом уровне (L7) модели OSI.

ТипыAPI Gateways

С точки зрения расположения есть два места установки API Gateways:

• Local API Gatewaysработают как шлюз для сервисов внутри организации.

• DMZ API Gatewaysработают как шлюз для внешних потребителей и клиентов сервисов.

Для одного сервиса возможно использование обоих типов шлюзов, когда сервисом пользуются как внутренние потребители, так и внешние клиенты. В остальных случаях использование обоих типов шлюзов зачастую не целесообразно. Это связанно с основным минусом шлюзов - добавлением задержек при обработке запросов и ответов.

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

Централизованный сервис Gravitee

В X5 Retail Group в свое время выбрали для использования систему APIM Gravitee (https://www.gravitee.io). Основной сценарий использования нашими командами публикация API в локальной сети и в DMZ.

Немного цифр об этом сервисе на текущий момент:

• 23 продуктивных команд зарегистрировано

• 69 API Gateways для обслуживания запросов

• 400 Гб логов за сутки

• 350 RPS в среднем по больнице за сутки

• 30 000 000+ запросов обрабатывается за сутки

Функциональность

Рассмотрим базовую функциональность, предоставленную системой APIM Gravitee.

1. Identity provider: Аутентификация внешних пользователей можешь осуществляться на основе следующих систем и сервисов:

1. MongoDB (по умолчанию для новых пользователей, которые приглашаются);

2. In-memory (по умолчанию для пользователя admin);

3. LDAP / Active Directory;

4. OpenID Connect IdP (Azure AD, Google);

2. Fetchers: стянуть настройки для новой версии API и документацию можно через:

2. File (Swagger, OpenAPI);

3. HTTP;

4. GIT;

3. Policies: политики предназначены для изменения поведения, обрабатываемых шлюзом запросов и ответов. Каждый запрос и ответ обрабатывается согласно настроенной цепочке политик. Политики можно рассматривать как прокси-контроллер, гарантирующий выполнение данного бизнес-правила во время обработки. Примеры политик:

3. API Key - политика авторизации с использованием API-ключа;

4. Rate-limiting - политика ограничения скорости или квот для предотвращения флудинга backend;

5. Transform Headers/Transform Query Parameters - политика преобразований параметров заголовка или запроса;

6. etc.

Политик обработки запросов в Gravitee Gateway более 30 штук и с каждой версией их число увеличивается. Так же можно сделать свои политики. Но стоит учитывать, что чем больше политик "навешано", тем медленнее будет обрабатываться запрос и тем больше ресурсов будет использовано.

4. Reporters: сборщики логов используются экземпляром шлюза для сообщения о событиях. Типы сборщиков логов:

4. Reporter file;

5. Elasticsearch;

6. Accesslog;

Типы событий, которые можно собрать:

4. Метрики запроса/ответа например, время ответа, длина содержимого, api-ключ;

5. Мониторинг метрик например, процессора, использования кучи, кол-во открытых файлов и т.д.;

6. Показатели проверки работоспособности например, состояние, код ответа;

5. Repositories: репозиторий - это подключаемый компонент хранилища для настройки API, конфигураций политик, аналитики, аудита и так далее. Можно использовать следующие репозитории:

5. MongoDB (по умолчанию);

6. Redis;

7. Elasticsearch;

8. PostgreSQL (коннектор через JDBC и надо использовать другой дистрибутив);

6. Resources: ресурсы, которые можно использовать при работе:

6. OAuth2 (подключение к OAuth2 как источнику данных для аутентификации);

7. Cache (создание локального кэша на шлюзе);

8. LDAP (подключение к LDAP как источнику данных для аутентификации);

7. Services: сервисы, которые может предоставлять сам шлюз:

7. Sync (Синхронизация состояния шлюза с конфигурацией из репозитория управления);

8. local-registry (Локальный реестр используется для загрузки API в формате json из файловой системы. Таким образом, вам не нужно настраивать свой API с помощью веб-консоли или rest API (но вам нужно знать и понимать формат json API, чтобы он работал.));

9. health-check (Сервис для проверки состояния других сервисов);

10. monitor (Сервис извлекает метрики, такие как метрики os / process / jvm, и отправляет их в базовую службу отчетов);

8. Notifiers: сервис нотификаций используется для отправки уведомлений. В настоящее время единственным доступным каналом является электронная почта, но в ближайшее время запланированы другие, включая Slack.

8. Email;

9. Alerts: оповещение используется для отправки триггеров или событий в механизм оповещений, которые могут быть обработаны для отправки уведомления с помощью настроенного плагина Notifier.

9. Vertx;

А так как система с открытыми исходниками:https://github.com/gravitee-io, то при знании Java, можно написать свои собственные плагины и использовать как вздумается.

Настройки API

Настройка нового API проходит несколько этапов:

1. Создание API

2. Настройка планов

3. Привязываем API к шлюзам

Создание API

На странице создания API можно выбрать, как и из чего создать скелет нового API

Вариантов немного, но выбор есть:

1. Вручную накликал и можно работать!

2. Импортировать из swagger файла.

3. Импортировать из Gitа/URLа.

Рассмотрим ручной вариант настройки, выбираем "->"

Ручное создание API проходит 5 шагов

На первом шаге указываем имя API, версию, описание и уникальный путь, по которому это API будет доступно.

Второй шаг может быть в двух модификациях:

В Simple mode указываем только адрес нашего backend api, например:https://msk-dpro-sre000.x5.ru:8443/testbackend/

В Advanced mode необходимо указатьадрес нашего backend api, используемые tenant и sharding tags.

tenant- область выделенная в Elasticsearch для логов запросов и событий.

sharding tags- теги, согласно которым связываются API и Gateways

На третьем шаге можно указать Plan

Plan - это указание ограничений, которые будут влиять на обработку запросов, проходящих через данный Gateway.

Name -имяплана

Security type -типплана: Keyless(public), API Key, JWT, OAuth2

Description - просто описание плана и его особенностей

Rate limit - ограничение кол-ва запросов в секунду/минуту

Quota -ограничение кол-ва запросов в час/день/неделя/месяц

Path authorization - черный и белый список путей и методов к ним

Данный пункт можно пропустить и заполнить уже в созданном API.

На четвертом шаге можно загрузить файл документации по API

Поддерживается формат swagger.json

Данный пункт можно пропустить и заполнить уже в созданном API.

На пятом шаге мы проверяем все что заполнили

И выбираем либо "Создать API без установки на шлюз", либо "Создать и запустить API"

Нажимаем CREATE и получаем частично настроенный API для работы.

Настройки планов

План предоставляет собой уровень обслуживания и доступа между API и приложениями. У одного API может быть несколько планов, но только один без ключевой - "keyless". План определяет ограничения доступа, режимы проверки подписи и другие настройки для адаптации к конкретному приложению.

Основные настройки:

1. Планы привязываются к конкретному шлюзу или группе шлюзов через Tags (см. рис. 3)

2. В плане указывается какой тип Аутентификации будет использован (см. рис. 4)

3. Можно сразу указать Rate и Quota лимиты и определить список разрешенных путей для запроса (см. рис. 5)

4. В последней вкладке можно указать политики, которые будут отрабатывать на начальном этапе обработки запросов (см. рис. 6)

Заключение

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

TL;DR

В этой статье попробуем разобраться нужно ли инженеру продуктовое мышление (и в каких случаях), какие плюсы (и минусы) это даёт, и возможно ли совместить в одном человеке два разных (часто противоречащих) образа мышления. Ведь разные образы мышления ведут в разным приоритетам, а как следствие и разным действиям.

Intro

Привет! Меня зовут Ил. И я работаю в стартапе. Нас около 20 человек половина команды (русскоязычная) занимается технологиями, вторая половина (англоязычная) занимается бизнесом. Официальный язык общения английский. Мы (как продукт, бизнес и команда) быстро растём, итерируемся, меняемся и развиваемся. Поэтому для нас критически важно чтобы было отличное взаимопонимание между бизнесом и технологиями. Обычно в компаниях эту функцию выполняют продуктовые менеджеры или аналитики. И у нас они тоже есть. Даже двое. Но каждый из них работает над продуктовыми задачами только 50% времени, совмещая эту роль с другими ролями. Поэтому суммируя, можно сказать что у нас в команде один Product Manager. А скорость изменений такая, что в полной мере формализовать, описать и декомпозировать задачи у PM-команды времени физически не хватает. Поэтому большинство задач у нас описываются достаточно высокоуровнево с акцентом на что хотим получить после того как задача будет выполнена. Процесс декомпозиции задачи, поиск возможных путей решения, выбор оптимального способа и более детальная проработка задачи (в том числе с точки зрения требований и продукта) обычно делегируется инженерам.

Погружаемся

Я бльшую часть времени занимаюсь бэкендом, но как часто бывает в стартапах по факту занимаюсь очень разными задачами. Несколько примеров задач из реальной жизни (которые инженеры обычно не решают):

• Сделать research по barcodes (штрих-коды на товарах). Понять какие для них есть международные стандарты, как они различаются в раличных странах, какой у них формат, как их валидировать и прочее;

• Создать план тестирования и/или миграции для большой фичи меняющей поведение в критически важном месте системы;

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

• Поискать готовые 3rd party решения для той или иной задачи и оценить что в данный момент эффектнее взять один из них или написать самим.

В какой-то момент я внезапно осознал, что непосредственно инженерными задачами я занимаюсь не более 50-60% времени. А иногда и того меньше. Вторая половина моего времени уходит на другие активности:

• звонки, обсуждения, обмен знаниями о продукте;

• интервью кандидатов, участие в hiring-процессах;

• изучение PRD (по русски ТЗ), поиск в нём "багов" заложенных ещё на уровне описания идеи и логики, выявление слабых мест, поиск мест которые можно сделать лучше, проще или оптимальнее, оценка времени необходимого на разработку;

• эксперименты, проверка гипотез (продуктовых), POCи (proof-of-concepts);

• написание спецификаций, инструкций и других документов для фрилансеров (часть задач мы аутсорсим) и коллег;

• координация с другими командами и членами команд;

• выявление слабых мест в процессах, и улучшение процессов;

• поиск готовых решений для не mission critical задач (чтобы не изобретать велосипед) и анализ как прагматичнее поступить в конкретном случае запилить своё решение или взять готовое;

• smoke-тестирование;

• работа с продуктовыми метриками в Amplitude;

• генерация кастомных отчётов.

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

• понять чего хочет бизнес;

• понять чего хочет бизнес на самом деле (обычно 20-50% требований меняется в процессе обсуждения, ещё до начала реализации);

• уточнить неочевидные детали, краевые случаи;

• проанализировать и найти оптимальное техническое решение.

При этом крайне желательно донести до всей команды особенности выбранного в итоге решения, в том числе его ограничения и недостатки. Потому что выбранный вариант решения задачи это почти всегда trade off (причём достаточно жёсткий): между скоростью разработки, качеством, масштабируемостью и расширяемостью.

Все перечисленные факторы приводят к тому что становится критически важно мыслить не только инженерными ценностями (должно работать быстро, стабильно, безопасно) но и продуктовыми (с вероятностью 80% через несколько месяцев мы удалим этот код или полностью его перепишем). Если не подходить в ежедневной работе с подобной точки зрения, удовлетворённость от работы очень сильно снижается.

Ещё одна важная культурная деталь нашей команды достаточно плоская структура и то, что каждый инженер лично отвечает за свою задачу, от момента её придумывания до user adoption. И написание кода это лишь один из этапов. Лично отвечает не значит что если что-то пойдёт не так, то человека уволят или лишат премии. Нет. Это значит что нужно будет вернуться назад и переделать. И прагматичное, рациональное, продуктовое мышления уменьшает кол-во таких итераций-переделок кардинально.

+/-

У такого режима работы определённо есть как плюсы, так и минусы. Попробуем в них разобраться.

Разберём плюсы. Почему это круто:

1. Ты намного лучше понимаешь приоритеты, чётко знаешь что важно, а что второстепенно (в мире стартапов "второстепенно" и "не важно" по сути синонимы). Следовательно, понимаешь каким частям кода следует уделять больше внимание, а в каких в данный момент можно на*****кодить

2. Ты начнёшь понимать мотивы продуктовых решений, почему решили сделать так, а не иначе. Соответственно ты будешь в курсе дальнейших планов на проект/фичу. Это поможет выстроить более адекватную архитектуру

3. Тебе будут чаще давать более глубокие, сложные, интересные задачи. Ты получишь больше свободы. И больше ответсвенности

4. Это интересно. Понимать продуктовые метрики и особенности поведения пользователей это увлекательно. И это затягивает

5. Когда начнёшь думать не только о коде, но и о продукте, у тебя постепенно начнёт меняться мышление. Ты заметишь, что тебе станет проще коммуницировать с коллегами, которые занимаются продуктовым менеджментом, проектным менеджментом, аналитикой. Тебе будет проще их понимать. А им тебя. Работа станет менее стрессовой и более продуктивной

6. Качество твоих фич и решений будет увеличиваться. Как следствие, качество всего продукта тоже будет расти. Вместе с продуктом, твоя ценность в команде тоже будет становится всё больше

7. Тебе откроются новые возможности это может стать первым шагом к своему стартапу, или крутой карьере в FAANG, или повышению на текущем месте, или удачному exit-у (если у тебя есть опционы)

Почему это не круто:

1. Частые смены контекста вредят здоровью. Они не только значительно повышают уровень стресса, но и могут пагубно влиять на мозг. Многочисленные исследования подтверждают это злоупотребление многозадачностью может привести в снижению общего IQ и негативным изменениям в мозге на физическом уровне, таким как уменьшение плотности нейронов (1, 2). А тебе придётся менять контекст очень часто. Твои дни станут более рваными. Ты будешь заниматься несколькими задачами одновременно и минимум 10/20/30 разными задачами в течении дня. Ты скорее всего станешь более нервным и раздражительным. У тебя могут начаться головные боли, даже если раньше ты был им не подвержен

2. Тебе придётся делать то, что раньше ты скорее всего никогда не делал, потому что это делали за тебя твои коллеги. Например: работать с системами продуктовой аналитики, системами для рекламы, маркетинга, сервисами для мокапов, прототипирования, дизайна. Тебе придётся разбираться с множеством смежных областей и инструментов в этих областаях. Быть проактивным. Пушить других людей, если они не реагируют вовремя (в том числе твоих менеджеров). Назначать встречи/звонки. И это не вместо кодинга, а вместе с кодингом

3. Ты начнёшь замечать конфликты в своём мышлении, а возможно и в решениях. За хорошее решение принятое тобой как инженером, твой внутренний PM может на тебя косо посмотреть или даже обидеться (привет, биполярочка!)

4. Определённости и чётких ответов в твоей жизни станет ещё меньше, чем сейчас

Интегрируем

Вот мы и подходим к тому, с чего начали в заголовке статьи.

Термин Product Engineer пока ещё не очень популярен, но я думаю что в скором времени его популярность будет расти. Возможно для этой роли придумают другие названия, но суть не поменяется.

Драйверов развития этой роли несколько:

1. Новым IT-компаниям становится сложнее найти своё место на рынке, юникорны появляются всё реже. При этом зарплаты инженеров продолжают расти, как и общие затраты на команды. Ведь с насыщением и усложнением индустрии растёт и количество человеко-часов которые нужно инвестировать чтобы построить успешную высокотехнологичную компанию. В таких условиях продуктовые инженеры могут оказаться редкими покемонами, которых хочет к себе в команду любой стартап. Ведь один человек способен закрыть сразу две позиции (а как бонус ещё и меньше overheadа на коммуникацию)

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

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

• Сисадмин/программист DevOps;

• Программист/бизнесмен Product Manager;

• Рекламщик/веб-мастер SEO-шник.

Достаточно отважен и хабр храбр?

Успей запрыгнуть в поезд! Но помни тормозов у этого поезда, похоже, нет.