Кенн Хасси, вице-президент по инжинирингу Ambassador Labs, приводит на портале The New Stack ряд ключевых выводов относительно будущего API, сделанных по следам конференции Nordic APIs Platform Summit.

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

Я имел удовольствие присутствовать на недавнем саммите Nordic APIs Platform Summit в Стокгольме, и мне стало ясно, что, хотя преимущества API неоспоримы, связанные с ними проблемы вполне реальны. Я хотел бы поделиться несколькими ключевыми выводами в надежде, что наше коллективное внимание приведет к решениям.

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

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

Вы, наверное, догадываетесь, что будет дальше, потому что все мы знаем, что океан вскипятить невозможно. Возникающее напряжение из-за разницы между тем, что обещают, и тем, что на самом деле предоставляется, ощутимо. Разработчики все громче заявляют о разрыве между этими обещаниями и реальностью. Но это не значит, что мы должны отбросить все эти усилия; нам нужен сдвиг в мышлении. Мы стоим на пороге нового рубежа, который требует чего-то иного, чего-то более тонкого.

Это новое мышление, о котором много говорилось на саммите, — переход к APIOps и использование композитных платформ, которые не стремятся делать все. Вместо этого платформы должны сосредоточиться на качественном выполнении ключевых задач.

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

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

2. Мы все еще говорим об опыте разработчиков

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

Чтобы осуществить это на практике, такие вещи, как версионирование API и управление жизненным циклом (SDLC), должны быть заложены со «дня 1», а не прикручены позже. Последовательная практика тщательного тестирования и обеспечения безопасности должна быть простой и доступной, а не громоздкой и запутанной. А документация, которой часто пренебрегают, должна быть первоклассной с самого начала.

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

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

Мы должны найти способы минимизировать «налог», налагаемый различными этапами рабочего процесса разработки, что особенно сложно в современных микросервисах и нативных облачных средах. Правильное сочетание платформенного подхода и опыта разработчиков может сделать это.

На конференции были упомянуты некоторые инструменты, предлагающие решения для улучшения работы разработчиков:

  • Такие инструменты, как Specmatic, позволяют тестировать соответствие, совместимость и отклонения на этапе проектирования, решая проблемы на ранней стадии.
  • Такие языки, как TypeSpec, поднимают документацию API до статуса первоклассной, облегчая разработчикам поддержание последовательности и ясности.
  • Конечно, я не могу не упомянуть инструменты типа Blackbird как бесценные в оптимизации внутренних и внешних циклов разработчика.

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

3. Что не требует больших усилий: мы должны правильно организовать безопасность

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

И, конечно, нельзя забывать о популярном подходе «нулевого доверия», который основан на принципе рассмотрения пользователей, систем и сетевого трафика как принципиально недоверенных, даже если они находятся внутри периметра безопасности, защищаемого брандмауэром. Или же многие стремятся сдвинуть безопасность «влево» (shift left«), чтобы она стала более приоритетной на ранних этапах SDLC.

Что бы вы ни делали для обеспечения приоритетности безопасности, ее правильное обеспечение — это одно из самых легких достижений, за которые разработчики могут ухватиться, но многие из нас все еще не справляются с этой задачей. А с ростом числа взломов и злоумышленников (по данным Salt Security, только за последние шесть месяцев рост составил 400%) мы больше не можем позволить себе игнорировать усиление мер безопасности.

4. Будущее искусственно и небезопасно

ИИ, что неудивительно, был главной темой на саммите, как и на всех конференциях, панелях и в статьях за последний год. Что бы ни говорили в отрасли об API, ИИ влияет на все — от того, как мы создаем API, до того, как с ними взаимодействуют наши потребители. Задача разработчиков API заключается не только в том, чтобы использовать ИИ, но и в том, чтобы создавать API и платформы, способные адаптироваться к тому, как другие используют ИИ в своих системах.

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

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

Новый рубеж многообещающ, если вы вооружены правильными инструментами, подходами и мышлением.