Создание культуры и компании, ориентированной на API (API-first) включает множество этапов — от выработки дизайна и правил структуры и разработки API, до определения приоритетов и планирования правильного типа инфраструктуры для поддержки API. Однако самой важной частью этого пути является ментальный сдвиг, пишет на портале The New Stack Картик Кришнасвами, руководитель отдела маркетинга продуктов компании NGINX.

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

Учитывая, насколько API стали повсеместными и необходимыми, мы ожидаем, что в будущем от этого выиграют компании, которые используют API как основу своих продуктов или как ключевой элемент их выхода на рынок. Одни компании, очевидно, являются API-first, потому что сам API является их основным продуктом (Twilio, Stripe и Plaid — три популярных примера такой модели бизнеса). Другие организации также можно отнести к категории API-first, если их культура и этика требуют, чтобы все потреблялось и адресовалось через API (под это описание подходят Amazon, Google и Facebook).

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

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

Три волны API-экономики

В первой волне API-экономики мы наблюдали рост API как способа внедрения ключевых функций в приложения. Facebook, Twitter и Google Maps — все они продемонстрировали, как разработчики могут использовать огромные преимущества добавления функциональности в приложения за счет использования API-фидов.

Во второй волне мы увидели подъем компаний, использующих API как продукт, таких как Twilio и Stripe. Эти гиганты подтвердили возможность продажи критически важной услуги в виде API для встраивания в другие приложения и сервисы.

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

API открывают новые рынки, а также позволяют быстрее и экономичнее выходить на существующие. Они также позволяют лучше использовать технологии внутри компании. Это способствует развитию микросервисов и широкому — возможно, даже более радикальному — переходу от беспорядочных монолитов к лучшему масштабированию и более гибкому подходу «Работа, которая должна быть выполнена» (JTBD). Фреймворк JTBD обеспечивает более широкое владение сервисами внутри организаций. Сервисы могут располагать небольшими командами, которые воплощают концепцию «команды на две пиццы» как основной креативный механизм и делают выполненную работу многократно используемой для создания новых продуктов и возможностей.

Как перейти в категорию API-first

В реальности это путь, который требует обдумывания и проработки. Он включает множество этапов — от выработки дизайна и правил структуры и разработки API, до определения приоритетов и планирования правильного типа инфраструктуры для поддержки API. Однако самой важной частью этого пути является ментальный сдвиг. Компании категории API-first принимают этот ментальный сдвиг близко к сердцу, делая API своим основным продуктом. Все остальные продукты вытекают из API. Все, что раскрывает API, облегчает последующие приложения и варианты использования.

Этап 1: Видение и оценка

Шаг 1: Создание руководящих принципов для достижения идеального состояния API-first

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

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

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

Шаг 2: Визуализация цели

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

Шаг 3: Инвентаризация существующих API

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

Шаг 4: Определение требований к инфраструктуре и средствам совместной работы

На этом этапе вам нужно будет сотрудничать с командами DevOps и PlatformOps, чтобы понять, как будут использоваться API и какие инструменты они предпочитают.

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

Примерные требования к инфраструктуре:

  • API для клиентских финансовых транзакций может требовать SLA с низкой толерантностью и очень низкой задержкой, что может диктовать необходимость его поддержки в N+3 инстансах в различных дата-центрах по всему миру, чтобы перенести обработку API ближе к клиентским вызовам. Для такого сценария может потребоваться API-шлюз, оптимизированный для высокой производительности;
  • API, которые являются внутренними и требуют только согласованности (не низкой задержки), могут спокойно жить с менее строгими SLA на более старом, медленном оборудовании и в меньшем количестве дата-центров;
  • поскольку GraphQL предназначен для обработки многих типов запросов и часто взаимодействует с графовой базой данных, API GraphQL могут потребовать большей вычислительной мощности и большей пропускной способности каналов связи, чем более узкие API REST.

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

Подготовка к проектированию, созданию и внедрению API-First

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

Продолжение следует.