Для индустрии прикладных программных интерфейсов (API) ключ к тому, чтобы идти в ногу с тенденциями, не жертвуя основами, — это подход, ориентированный на разработчиков, пишет на портале The New Stack Стив Родда, генеральный директор компании Ambassador.
Каждый год примерно в это время снова стартует непрерывный поток статей о трендах будущего года. Иногда, читая их, я получаю хорошие идеи — новые способы собрать воедино нити, чтобы сплести содержательную историю о том, где мы были и куда идем.
В этом году меня поразило то, насколько знакомыми кажутся списки так называемых трендов. Вот примерная выборка:
- Повышение эффективности — главная цель, независимо от ситуации в экономике.
- Организации, которые отдают приоритет сотрудничеству, добиваются лучших результатов. (Мы постоянно говорим об этом, но делаем ли мы это на самом деле?)
- Чтобы не отставать от угроз безопасности, требуются усердие и постоянная адаптация.
- Новые технологии (привет, искусственный интеллект) грозят нарушить статус-кво, и командам необходимо продуманно подходить к их использованию.
Дело в том, что основы бизнеса не меняются с течением времени, потому что это основы. Эффективность, адаптация, совместная работа и безопасность остаются неизменными, касается это API или нет. Конкретные способы достижения этих целей будут меняться с течением времени, но преемственность поразительна. Это может заставить вас сказать себе (как и мне в свое время): «В чем тогда смысл?».
В конце концов, по определению, безумие — это делать одно и то же снова и снова, ожидая другого результата. Мы действительно не можем продолжать делать все те же несколько вещей, о которых говорилось выше. Это уже не поможет.
Но мы можем и должны изменить свое мышление в плане подхода к этим постоянным вещам. Каждый год дает нам новую возможность добиться новых успехов, особенно если у нас есть новая перспектива. Какой образ мышления изменит нашу способность успешно продвигаться по этим постоянным темам? Ориентированный в первую очередь на разработчиков! Позвольте мне объяснить это на нескольких примерах.
Развенчание мифа об API-менеджменте
Мы все слышали предсказания о том, что мы уйдем от монолитного универсального метода управления API.
Вот суровая правда: вы не можете управлять качеством и согласованностью API, не разрабатывая их. Проанализируйте все вышеперечисленные «тенденции», и вы поймете: ни одна компания, занимающаяся API, не сможет удержаться на плаву без хороших разработчиков, пишущих качественный код для API. Из чего следует вывод? Разработчиков нельзя игнорировать в программе API, которая надеется на успех.
Так почему же мы ставим так много препятствий на пути разработчиков? Отчасти ответ заключается в разрастании.
Распространение распространения
Индустрия API растет быстрее, чем когда-либо, даже если основы бизнеса не претерпевают значительных изменений. Согласно отчету apidays «2024 API State of the Market Report», 71% интернет-трафика сегодня составляют вызовы API. Gartner прогнозирует 30%-ный рост использования API к 2026 г., обусловленный ИИ и большими языковыми моделями (LLM), а в отчете Postman «2024 State of the API Report» говорится о 73%-ном росте API-трафика, связанного с ИИ.
Этот рост — отличная новость для многих из нас, работающих в индустрии API. С другой стороны, это крайняя степень расширения сферы охвата API.
По данным F5, в мире активно около 200 млн. API, и, по прогнозам, к 2030 г. их число вырастет до 1,7 млрд. Многие из них не поддерживаются, плохо индексируются, небезопасны и непоследовательно документированы, но они все равно существуют, и если они глубоко внедрены в ваши зависимости, вы можете даже не подозревать, что используете их.
API должны быть на 100% надежными, чтобы их можно было использовать в производственных приложениях. Многие компании не в состоянии обеспечить такой уровень надежности при нынешних масштабах разрастания API, не говоря уже о том, что их число продолжает расти. Это не упрек в адрес людей — это упрек в адрес наших процессов.
API-менеджмент — это подход «сверху вниз», работающий на основе единых цели и процесса управления проектом. Чтобы охватить весь объем, часто приходится тратить бóльшую часть ресурсов на программное управление и почти ничего не остается на разработку, и именно в этом заключается недостаток подхода, ориентированного на управление.
Разработчикам нужна поддержка, которая не будет им мешать
Альтернатива подходу «сверху вниз» предполагает смещение приоритетов и сосредоточение на том, где API создаются и используются — на разработчиках.
Профессиональные разработчики расскажут вам, как им нравится находиться в «зоне», испытывая состояние потока, в котором они исключительно продуктивны и полны энергии. Это чувство знакомо многим из нас, будь то решение головоломок, игры или даже написание кода.
Ни один ребенок не подсаживается на написание кода, потому что мечтает однажды использовать agile-методологию, и ни один разработчик не остается вовлеченным в работу, потому что ему нравятся долгие процессы рассмотрения дизайна. Но нужно ли нам все это на самом деле?
Я бы не рекомендовал отрывать ваши команды разработчиков от работы и говорить им, чтобы они развлекались. Однако, если вы сможете четко определить приоритеты, разработчики API смогут быстро воплощать идеи в код и сокращать объем работ, предоставляя решения с минимальными затратами.
При этом подходы «продукт на первом месте», «дизайн на первом месте», «API на первом месте» и «все, что в тренде» не подойдут. Они создают слишком много слоев между фундаментальными бизнес-целями и разработчиками, которые их реализуют. В центре решения должны быть разработчики.
Заложите безопасность и стандарты с самого начала
Потребность в повышении безопасности API — еще одна постоянная тенденция, требующая нового подхода. API становятся все более важными во всех отраслях, особенно в таких высокорегулируемых, как здравоохранение, финансы и коммунальное хозяйство. Беспокоиться о безопасности и соответствии требованиям должны не только разработчики, работающие непосредственно в этих отраслях, — эти компании широко используют сторонние API, поэтому всем производителям API необходимо следовать единой практике.
Согласно отчету Akamai «2024 State of the Internet Report», от 30 до 40% кибератак используют API для достижения своей цели. В упомянутом выше отчете apidays говорится, что 95% компаний пытаются справиться с рисками безопасности API.
Одной из самых больших проблем безопасности является несогласованность. Я уверен, что команды разработчиков, даже те, в которых нет специалистов по безопасности, могут найти способы улучшить согласованность кода.
Платформенный инжиниринг — это подход, который может помочь организациям встать на правильный путь, облегчив разработчикам создание согласованного кода и поддержание стандартов. При правильном подходе это не просто философия: платформы предоставляют разработчикам такие удобные ресурсы, как многократно используемые блоки кода, автоматизированные механизмы управления, общие библиотеки и легко воспроизводимые среды разработки. Разработчики могут следовать лучшим практикам безопасности и соответствия стандартам без лишней работы.
Поддержка разработчиков с помощью избранных ИИ-инструментов
Согласно отчету apidays, 13% поставщиков API-инструментов уже интегрируют ИИ. Например, написание спецификаций может быть утомительным и отнимать много времени, но использование ИИ позволяет быстрее получить согласованные результаты и упрощает их проверку и обмен. Правильные инструменты также могут помочь вам сгенерировать шаблонный код из этих спецификаций, созданных ИИ, что позволит вашим разработчикам быстрее приступить к настройке и отладке.
Именно таких улучшений я жду от ИИ в ближайшей перспективе. Компании, производящие инструменты, реагируют на то, как уже работают разработчики, и используют ИИ, чтобы лучше удовлетворить их потребности. В результате у разработчиков появляется больше времени и энергии, которые они могут потратить на работу, в которой они преуспели: написание кода API. Это не революция, это эволюция — и в этом ее смысл.
Теперь давайте разберемся, почему все эти тенденции имеют значение.
Ориентация на разработчиков эффективна для современных архитектур
Одна из значимых тенденций в области API наблюдается уже несколько лет. Компании отказываются от подходов, основанных на жизненном цикле продукта и ориентированных на большие монолитные службы API-менеджмента.
К 2030 г., по прогнозам F5, будет насчитываться 2 млрд. API со сроком жизни менее года. Архитектуры микросервисов регулярно используют десятки небольших API с минимальной зависимостью, поэтому их можно заменять по мере необходимости. Развитие бессерверной архитектуры, рынок которой, по прогнозам, к 2029 г. вырастет до 44,7 млрд. долл., также предполагает увеличение инвестиций в API с коротким циклом разработки и сроком жизни.
Современные API — это не обязательно долговечные, полнофункциональные продукты, да и не должны быть таковыми. Если вы проводите несколько кросс-функциональных agile-спринтов для разработки API, который будет использоваться менее года, вы тратите ресурсы на создание системы, которая, вероятно, будет чрезмерно специфицирована и раздута.
Альтернатива — использовать инструменты и процессы, ориентированные на единицу работы разработчика API, которой является одна конечная точка. Независимо от масштаба и продолжительности жизни API, он будет состоять из конечных точек, и каждая из них должна быть написана разработчиком, по одной за раз. Это еще один способ, с помощью которого возвращение к основам может помочь вам адаптироваться к новым тенденциям.
Отбросьте излишества управления жизненным циклом продукта и предоставьте разработчикам инструменты, поддерживающие то, как они предпочитают работать. Разработчики будут проводить больше времени в состоянии потока, работая над целенаправленным, высококачественным кодом, а вы сэкономите время и деньги — ценность, которая переживет любые тенденции.
Сотрудничество ускоряется, когда оно ориентировано на разработчиков
Вашим разработчикам по-прежнему необходимо работать в командах и с командами. Это требование никуда не денется, но не нужно, чтобы совместная работа была неудобной и медленной.
Лучшая модель совместной работы начинается с того, как ваши разработчики работают вместе, а затем на этой основе выстраиваются инструменты и процессы. Например, разработчики должны иметь возможность самостоятельно запускать среды, похожие на продакшн, для отладки в реальных условиях. Разработчикам, особенно если они работают в контейнерной или бессерверной архитектуре, необходимо знать, что они создают приложение в новейшей среде разработки, чтобы их код был работоспособен в продакшн. Они не хотят просить команду DevOps создавать для них новую среду разработки каждый раз, когда что-то меняется. Команда DevOps тоже этого не хочет, как и вы.
Спросите своих разработчиков, как они хотели бы сотрудничать. В каких ключевых областях им нужна поддержка? Подстройте свои процессы и инструменты под эти потребности. Создание спецификаций с помощью чата, быстрое моделирование API и эфемерные среды — вот некоторые из функций, которые ваша команда сочла бы эффективными для упрощения сотрудничества между разработчиками.
Лучшее решение для вашей организации начнется с понимания того, как работают ваши разработчики. Отказавшись от фокуса на жизненном цикле продукта, они смогут создавать быстрее и лучше с меньшими накладными расходами.
API-перспективы 2025 года
Технологии продолжают развиваться, и через несколько лет наши методы использования ИИ могут выглядеть совершенно иначе. Бессерверная архитектура — это горячий тренд, но в конечном итоге ее обгонит что-то другое. Киберпреступники, несомненно, будут продолжать удивлять нас новыми атаками. Тенденции меняются, но основополагающие принципы, такие как эффективность, потребность в сотрудничестве, ценность согласованности и необходимость адаптации, всегда будут определять бизнес-решения.
Для индустрии API ключ к тому, чтобы идти в ногу с тенденциями, не жертвуя основами, — это подход, ориентированный на разработчиков. Разработчики всегда будут создавать основную ценность ваших API. Их рабочий процесс будет меняться по мере изменения потребностей отрасли, но это не повод для паники.
Воспринимайте новые тенденции как вариации на тему фундаментальных принципов, и путь вперед станет очевидным. Поставьте производительность разработчиков на первое место, и ваши разработчики будут создавать лучшие API.
