Ambassador Labs спонсировал этот пост. Insight Partners является инвестором в Ambassador Labs и TNS.
Все знакомы с этим неудобным ощущением, которое вы испытываете, когда вы новый разработчик, присоединяющийся к новой команде, открывая внутренний портал API и обнаружив… 57 API-интерфейс с именем пользователя-API? Э -э -э -э -э -э -э. У некоторых есть связанные документы. Некоторые этого не делают. Один указывает на устаревший кластер. Половина из них зарегистрирована, другая половина прячется в тени. Другой не был тронут еще до пандемии. (Прошло уже пять лет?) Какие из них вы должны использовать?
Или, может быть, вы технический лидер, которого спрашивают: «Сколько API используются или в производстве? Сколько усыновлены?» А потом вы смущенно смотрите на своих инженерных менеджеров, надеясь, что у кого -то будет готов, когда реальность такова вы … просто. Не. Знать.
Добро пожаловать в скрытую человеческую стоимость разрастания API. Это не только код. Это о культуре.
Разрастание — это племенное знание, оружие
По мере того, как команды разработчиков растут и отправляются постоянно, API размножаются. Вы получаете сильную команду, которая идет туда, где все постоянно взламывают свой список дел, и давление, чтобы быть быстрым и продуктивным. Результатом является множество API, не обязательно организованных, стандартизированных или даже документированных для различных команд разработчиков.
Без сильного управления или инструментов документация выходит устаревшая, владение становится нечетким, а новые разработчики остаются в разочаровывающей игре археологии API. Это не только замедляет время вашего разработчика (что в нашем недавнем исследовании опроса, как правило, является проблемой для 43% технических лидеров), но и делает плохой опыт разработчика для всех.
И мы даже не добрались до худшей части … что большинство ответов не живут в каком -то обнаруженном каталоге для видимости, а в чьей -то голове. Обычно эта честь падает с инженером, который был там дольше всего, или который только что писал первую версию этой платежной службы три года назад. Это большой риск, если этот человек уйдет.
Это не устойчиво. Он сжигает ваших разработчиков, замедляет адаптацию и делает сотрудничество по перекрестной команде кошмаром. Кроме того, он превращает то, что должно быть стратегическим преимуществом (ваши так называемые многоразовые API, если вы даже можете найти их) в источник технического долга и трения команды. Хуже того, когда вы бросаете ИИ в микс, API собираются умножить еще больше, потому что ИИ будет писать их.
Разрастание API — это перетаскивание на скорости разработчика (и моральный дух)
Он начинается с малого: несколько дублированных услуг, некоторые непоследовательные соглашения об именах, горстка команд, бросающих свои собственные версии того же API, потому что они не могли найти оригинал (или не доверяли ему).
Но со временем воздействие становится ясным:
- Новым инженерам требуются недели, чтобы нарастать.
- Неизвестное воздействие данных, если конфиденциальные данные непреднамеренно просочились через забытые или недооцененные API.
- Циклы тестирования и развертывания медленно до ползания, хотя 59% лидеров технологий сообщают о необходимости ускорения — тонна.
- Изменения становятся рискованными, потому что никто не знает, кому что владеет.
- Полезение выгорания, потому что каждое исправление похоже на пожарную дрель.
Короче говоря: разрастание API — это не просто проблема системы. Это проблема людей. И это питает вашу производительность живой и препятствует предсказуемости, счастье и скорости вашей организации.
В недавней группе технологических лидеров, обсуждающих показатели производительности разработчика, участник дискуссии Мэри Мур-Симмонс из Keebo AI поделилась этим важным кусочком, поезжав домой: «Я получаю этот отслеживающий разработчик счастье и удовлетворение может показаться нематериальным, но это важно для долгосрочного успеха. Команды, которые постоянно находятся в режиме кризиса, не могут отражать, учиться или расти».
И не выполнение проблемы с разрастанием API будет постоянно держать ваших разработчиков в кризисном режиме.
Прекратите лечить симптомы. Исправить корневую культуру.
Вы не можете исправить разрастание API, отправив электронное письмо команде «Пожалуйста, напишите лучшие документы» или раскрутив еще одну электронную таблицу для отслеживания услуг. Вам нужен культурный сдвиг — и инструмент, который его поддерживает. Инструменты, которые могут оптимизировать этот культурный сдвиг, включают те, которые:
- Помочь вам открыть и документировать, что уже есть: Ищите инструменты разработки API, которые отображают ваш внутренний ландшафт API, чтобы вы не теряли отслеживания того, что у вас есть в среде разработчика. Видимость является ключом, не только для ваших разработчиков, но и для вашего технического лидера, который должен быть в состоянии быстро ответить на вопросы, такие как «Сколько существует API и сколько они нам стоят?»
- Стандартизировать автоматически: Вам необходимо генерировать согласованные, совместимые спецификации API, и именно здесь вы можете опираться на A-A-A-A-A-Advisted Spec, чтобы гарантировать, что стандартизация является главным приоритетом.
- Легко включить параллельное развитие: Например, найдите инструменты, которые предлагают размещенные, производственные среды, которые позволяют командам фронта и бэкэнд строить и тестировать, не наступая друг на друга.
Заглядывая в будущее: будущее разрастания и MCP
Стоит также отметить, что наряду с ростом ИИ команды начинают принимать новые рамки, такие как протокол контекста модели (MCP), чтобы обеспечить соблюдение согласованности не только в коде, но и в мышлении, стоящих за вашими API (культурной стороной), и облегчить контекстные взаимодействия с большими языковыми моделями (LLMS). MCPS предоставит командам общую модель того, как структурированы отношения и конечные точки, и уменьшит бремя уникальных API для каждой услуги, чтобы напрямую взаимодействовать с LLM.
Думайте о MCPS как общие чертежи о том, как команды разрабатывают, определяют и развивают интеграцию. Вместо того, чтобы все раскрывали его своим собственным взглядом на пользовательский сервис или биллинг-API, MCPS обеспечивает повторно используемые, согласованные структуры. Результат, связанный с разрастанием? Меньше избыточных средств, лучшие встроенные и API, которые масштабируются с вашей организацией, а не против нее.
В конце концов, эта новая технология также поможет решить большую проблему разрастания API, но в то же время вы все равно можете сосредоточиться на культурных изменениях, которые помогут вашей команде разработчика взлететь.
Изменение культуры начинается с видимости
Многие инженерные лидеры будут утверждать, что разрастание API не является культурной проблемой; Фактически, наш недавний опрос показал, что лидеры считают опыт разработчиков как наименьшие из их насущных проблем, и только 15% ссылаются на это как проблему. Но это потому, что они не чувствуют, что разработчики чувствуют, что тратят бесчисленные часы, пытаясь найти вещи.
Тем не менее, многие не понимают, что когда вы не понимаете это правильно, остальные 85% общих проблем (безопасность, обслуживание и перерасходы затрат) становятся еще хуже. Отказ от разрастания API, и это влияние, которое он оказывает на опыт ваших разработчиков, — это, в конечном итоге, культурная проблема, которая ухудшает остальные ваши проблемы, стоят вам больше денег, времени и подсчета голов.
На самом деле, 48% организаций борются с разрастанием API, согласно прослеживаемому отчету. И я бы поспорил, что еще больше борется с этим, не осознавая, что их проблема.
Слушай, ты не можешь исправить то, что не видите. И сейчас многие инженерные лидеры летают слепы, когда дело доходит до разрастания API — выплачивая цену за риски безопасности, пропущенные сроки и отток разработчиков. Первый шаг не просто технический. Это человек.
Дайте вашей команде инструменты и подходы к сотрудничеству, видимость, чтобы избежать дублирования и окружающей среды для быстрого движения, без сжигания.
Ambassador Labs является лидером опыта нативного разработчика Cloud. Самолет управления разработчиком компании для Kubernetes объединяет инфраструктуру разработки, развертывания и производства для разработчиков и организаций по всему миру, чтобы они могли кодировать, отправлять и запускать приложения быстрее и проще, чем когда -либо. Insight Partners является инвестором в посол и TNS. Узнайте больше последних из Ambassador Labs Trending Stories YouTube.com/thenewstack Tech, быстро движется, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Лори Маршалл является аналитическим программным обеспечением и ИТ -специалистом с опытом разработки программного обеспечения, разработки баз данных, обучения базы данных, бизнес -анализа и обслуживания владельца продукта. В настоящее время выступая в качестве вице -президента Product Ambassador Labs, она закончила … Подробнее от Лори Маршалл
