Ориентироваться в какофонии маркетинговой шумихи, чтобы определить, что действительно важно для разработчиков, бывает непросто. Недавно компания Ambassador Labs собрала группу экспертов в области разработки API, чтобы обсудить основные тенденции, которые сформировали ландшафт API в последние месяцы, попытаться разобраться, на что действительно стоит обратить внимание, а что является просто фоновым шумом. Лори Маршалл, вице-президент по продуктам Ambassador Labs, представляет на портале The New Stack содержание этой дискуссии.

Великое разукрупнение не получило всеобщего признания

Несмотря на шумиху, поднятую в отрасли за последние шесть месяцев такими отраслевыми экспертами, как Gartner, Kong и др., теория «великого разукрупнения» («great unbundling») API-менеджмента остается спорной темой. Эта идея сосредоточена на переходе от монолитных полнофункциональных инструментов к лучшим нишевым решениям. Некоторые из участвовавших в дискуссии экспертов считают, что это скорее реакционная позиция, объясняя это тем, что большинство предприятий, с которыми они работали, не хотели тратить время, ресурсы и бюджет на интеграцию различных инструментов управления API в свои конвейеры доставки.

«Многие мои клиенты очень расстроены, потому что на самом деле нет простого способа объединить все эти инструменты, так что это не так просто, как некоторые думают», — поделился Джеймс Хиггинботэм, консультант по API в Launch Any.

Однако другой участник дискуссии, Кит Кейси из компании Pangea, расценил разукрупнение как признание того, что уже много лет происходит за кулисами — просто теперь уже открыто. Он отметил, что, хотя многие компании заявляют о стандартизации одного набора инструментов, на самом деле, например, в разных организациях развертываются микрошлюзы.

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

ИИ — обоюдоострый меч в безопасности API

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

«Если мы думаем: „О, никто никогда не сделает этого с нашим API“, нам нужно вернуться назад и пересмотреть свои предположения. Мы должны допускать, что кто-то сделает это с нашим API, но понимать, что этот кто-то может быть не человеком», — поделился Кейси.

Дэн Барахона, основатель APIsec University, обратил внимание на постоянно углубляющуюся связь между API и ИИ, а также на то, как эта связь повлияет на безопасность API. Сегодня существует серьезная обеспокоенность по поводу возможности использования ИИ в качестве вектора атак, а осуществлять чрезвычайно сложные атаки становится все проще. С другой стороны, существует огромный потенциал для использования ИИ в целях защиты и безопасности.

«Мы должны задаться вопросом, как мы можем использовать ИИ для защиты и как мы можем быть проактивными в защите от атак ИИ. Мы должны оценивать обе стороны монеты безопасности. Все специалисты по API должны задать себе вопрос: „Как мы можем внедрить ИИ в наши инструменты безопасности?“» — сказал Барахона.

Технологические руководители должны исходить из того, что их разработчики уже активно используют ИИ в качестве инструмента для исследования и тестирования, и это использование будет только расти по мере совершенствования технологии. Уже сейчас разработайте политику и лучшие практики в области ИИ и наймите разработчиков, которые хорошо понимают, как максимально использовать возможности инструментов ИИ, понимая при этом, что ни один инструмент пока не может заменить сильного разработчика, посоветовал Барахона.

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

От центра передового опыта к центру поддержки

Несмотря на то что платформенный инжиниринг захватывает весь мир, нам нужно сбавить обороты и сначала разобраться с основами. Иногда проблемы с командой платформенных разработчиков или центром передового опыта (CoE) заключаются в том, что они занимаются чем-то абстрактным, а не являются важной частью решения ваших проблем DevOps. Участники дискуссии согласились с тем, что необходимо переключить внимание с темы «Как мне управлять этой платформой?» на тему «Как мне помочь людям быть продуктивными?».

«Отступим немного назад и скажем, что, если отвлечься от шума, связанного с платформенным инжинирингом, то прежде чем говорить о платформе, нам нужно сделать много в области автоматизации для наших разработчиков, — сказал Хиггинботэм. — Давайте сместим акцент в разговоре на поддержку API и рассмотрим центры поддержки (C4E)».

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

«CoE сосредоточены на идее создания возможностей для разработчиков API, команд, предоставляющих услуги, и потребителей одновременно, и не так сосредоточены на реализации и предоставлении кода для API», — отметил Хиггинботэм. Например, API, созданный одной командой, могут использовать 150 различных команд в организации, а это значит, что без эффективной платформенной команды вам придется каждый раз вести один и тот же разговор с этими 150 заинтересованными сторонами.

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

Итак, вывод таков: да, платформенный инжиниринг приобретает все большее значение в разработке API, поскольку мы фокусируемся, прежде всего, на обеспечении возможностей доставки и поддержке разработчиков. Платформенная стратегия и CoE должны работать вместе для достижения настоящего успеха в области API.

В заключение

Эти концепции не новы, но от того, какой подход к этим тенденциям применят руководители в области разработки API, будет зависеть, смогут ли их разработчики положительно отреагировать на них.