Спонсируемый Когда ваше приложение работает без сбоев, пользователь испытывает гармонию API. Под капотом современных приложений инженеры спроектировали и реализовали десятки API, которые взаимодействуют друг с другом.
Эти API-интерфейсы масштабируются вверх и вниз, запрашивают информацию и, когда они работают должным образом, предоставляют пользователю то, что выглядит как молниеносное и интуитивно понятное приложение. Рассмотрим такое популярное приложение, как Lyft. В симпатичном пользовательском интерфейсе Lyft объединяет многочисленные API-соединения: для оплаты, для геолокации, для голосовых вызовов, для изображений. Lyft также включает в себя «Concierge API», который позволяет разработчикам других приложений создавать кнопку для вызова Lyft в свои собственные приложения.
По правде говоря, API уже давно играют решающую роль в доставке приложений. От результатов футбольных матчей до данных о статусе полетов и аналитики угроз или показателей использования памяти экземпляров AWS – большинство команд приложений полагаются на сторонние или обслуживаемые внутри компании API, чтобы современные приложения сияли. Разница в степени. За последние несколько лет API-интерфейсы перешли из части проектирования приложений в почти все элементы дизайна приложений. API-интерфейсы контролируют все аспекты, от корзины покупок до управления трафиком Восток-Запад в центре обработки данных. В этом отношении мы вышли на новую территорию с API.
С появлением Kubernetes, контейнеров и микросервисов ориентация современных архитектур приложений изменилась. В Kubernetes и микросервисах разделенные функции взаимодействуют друг с другом через API. (Kubernetes построен как механизм оркестровки, ориентированный на API.) В этой новой сфере разработка и управление API становятся критически важными. Ваши API – это ваши микросервисы, ваши приложения. Ваш подход к разработке и управлению API так же важен, как и подходы к данным, конфиденциальности, вычислениям и сетям, и также имеет решающее значение для успеха любой из этих областей.
Разработка интерфейса API 2.0: четыре принципа
Это создает как проблемы, так и возможности – то, что мы называем путешествием к API Experience 2.0. Все мы знаем термины UX, DX и CX. Пришло время узнать и дать определение другому термину – API Experience или APIX. В будущем, поскольку команды разработчиков будут тратить так много времени на работу с API и вокруг них, то, как они будут использовать эти API, станет ключевым требованием и критерием оценки для команд DevOps и GitOps. APIX также напрямую влияет на пользователей, как внутренних, так и внешних. Когда APIX не очень хорош, пользователи будут испытывать отнюдь не идеальное взаимодействие с пользователем и приложением.
APIX 2.0 начинается с размышлений о том, что можно улучшить в архитектуре, реализации и управлении API. Ядром этого пути является преобразование управления API (APIM) и модернизация шлюзов API, чтобы идти в ногу с появляющимися и развивающимися архитектурами приложений. Это должно быть сделано с точки зрения пользователей, как для конечных пользователей, так и для пользователей-разработчиков. Все API-интерфейсы в какой-то степени скрывают сложность бизнеса и берут на себя то, что было бы сложно построить и облегчить использование. Задача состоит в том, чтобы API были единообразно и надежно разработаны, просты в использовании и производительны.
Принцип 1. Создайте единый интерфейс на основе четких рекомендаций.
Каждому предприятию, создающему и использующему API в любом масштабе, следует подумать о создании рекомендаций по проектированию API и контрольного списка для оценки API. Это позволяет вашей команде стандартизировать дизайн и рассмотрение API для принятия и использования. В эпоху распределенных команд, управляемых микросервисами, многочисленные владельцы сервисов несут ответственность за разработку и обслуживание своих API. Применение общих правил, касающихся стандартов и политик API, повышает эффективность планирования и проектирования, разработки, тестирования, развертывания и вывода API из эксплуатации. Это можно свести к довольно простым вопросам, например: хорошо ли задокументирован API? Есть ли у него особая политика безопасности? Какая емкость API? Есть ли у API явный владелец? Можете ли вы управлять использованием API с помощью обычных инструментов управления API или шлюзов?
Наличие этих принципов снижает сложность, которая ранее сопровождала управление жизненными циклами API. Управление жизненными циклами API – сложная задача, поскольку аспекты управления, налагаемые системами безопасности и корпоративными архитекторами, обычно не рассматриваются разработчиками. Это управление жизненным циклом API влечет за собой сотрудничество между разработчиками и потребителями, поскольку итерации API-интерфейсов управляются по версиям и упаковываются в несколько продуктов для распространения. Слишком часто компании пытаются приспособить инструменты APIM к разнообразным API, эффективно «закрепляя» управление API. Это создает сложности, крайние случаи и проблемы. Фактически, обратное предпочтительнее, когда API разработан или переработан в соответствии с рекомендациями. Это даст лучшие результаты в APIX.
Поскольку API-интерфейсы используются в мобильных, облачных и локальных приложениях, шлюзы API могут служить центральной точкой, где руководители организаций и заинтересованные стороны применяют передовые методы и средства управления или обеспечивают применение правильных политик к каждому набору API-интерфейсов.
Этот переход к APIX 2.0 не обязательно требует от вашей организации переноса устаревших приложений в облако. Например, вместо того, чтобы отключать или перестраивать базовую устаревшую базовую систему, банк может разрабатывать API-интерфейсы, которые позволяют современным приложениям получать доступ к его данным. В Сингапуре компания «Делойт» работала с Ассоциацией банков и денежно-кредитным управлением над выявлением и сопоставлением 5636 системных и бизнес-процессов, общих для компаний, предоставляющих финансовые услуги, с набором из 411 API. Эти API-интерфейсы помогают ускорить разработку решений, начиная от торгового финансирования на основе блокчейна и заканчивая розничной торговлей в виртуальной реальности.
Все это значительно улучшается, когда организация создает четкие руководящие принципы для разработки и утверждения API.
Принцип 2: формализовать владение сервисом
Помимо команды разработчиков программного обеспечения, любая часть организации может публиковать собственные API-интерфейсы или использовать сторонние API-интерфейсы. Следовательно, инвентаризация используемых API-интерфейсов является важным первым шагом на пути к созданию адекватных элементов управления API, которыми можно централизованно управлять и даже автоматизировать.
Инструменты APIM могут сделать API более доступными для обнаружения за счет включения перечня служб или каталога служб. Когда тысячи API-интерфейсов работают одновременно, очень сложно отследить, сколько существует сервисов и что они делают. Другими словами, ключевым фактором согласованности APIX 2.0 является каталог услуг. Запись о владении сервисом в каталоге также обеспечивает наглядность для управления жизненным циклом API, поскольку API-интерфейсы управляются распределенным образом.
В каталоге должна быть определена команда или владелец для каждой услуги или группы услуг. Без установления владения сервисом управление жизненным циклом API невозможно. Разные API-интерфейсы можно оставить работать без присмотра в течение многих лет; остается активным, но забытым. Заброшенный, но активный API представляет собой серьезную угрозу безопасности; Например, API-интерфейсы все чаще становятся объектами атак злоумышленников для атак на финансовые учреждения.
Интеграция концепции каталога сервисов в инструмент APIM позволяет предприятию получить полную картину того, как сервисы работают и кто их использует, а также принимать более разумные решения о том, какие API оставить, а какие сократить. Например, вероятно, бесполезно запускать службу, которая принимает всего 10 запросов в день. Вместо этого вы можете решить объединить API из разных направлений бизнеса (LOB) или бизнес-единиц (BU) в качестве продукта. Но без явного владения API эти соображения отнимают много времени и болезненны.
Итог – API без владельца может быть хуже, чем без API.
Принцип 3: проектирование с учетом экономии от масштаба, экономии от объема или того и другого.
Другими ключевыми факторами в разговоре об APIX 2.0 являются экономия от масштаба и экономия от масштаба. Такие компании, как Netflix, могут быть узко ориентированы на потоковую передачу, но масштабы их работы астрономические. Такие компании должны иметь возможность предоставлять API и услуги в большом масштабе. Они выигрывают от более низкой средней стоимости управления жизненным циклом увеличивающегося объема услуг.
С другой стороны, банкам обычно необходимо сосредоточиться на большей экономии за счет увеличения объема поддержки своих многочисленных продуктов и бизнес-единиц. Эти компании отдают предпочтение функциональности, а не масштабируемости. Они выигрывают от более низких средних затрат, когда затраты распределяются на более широкий спектр услуг. Организации, занимающиеся оптимизацией APIX и предоставлением возможностей API 2.0 премиум-класса, должны понимать, к какой экономии дизайна они стремятся в каждом API, и учитывать это при принятии решений по объединению, масштабированию, защите внутренних API или привлечению внешних API.
Другими словами, знайте, для какой экономики вы строите или пытаетесь подражать, и используйте это, чтобы направлять свой дизайн и выбор API.
Принцип 4. Упростите управление
Чтобы предоставить APIX 2.0, ИТ-директора также должны иметь дело с тиранией сложности в сегодняшних средах приложений. Шлюзы API предназначены для преодоления этой сложности. Шлюз должен управлять сторонними API, API из микросервисов и слабо доступными API, скрытыми внутри монолитов.
Хотя API-интерфейсы упрощают создание микросервисов и управление ими, традиционные решения APIM не предназначены для обработки контейнерных, облачных и мультиоблачных сред. Сложные API-интерфейсы часто требуют взаимодействия между несколькими приложениями и службами со сложной бизнес-логикой. Эта сложность и цепочка вложенных зависимых взаимодействий увеличивает риски безопасности и раскрытие конфиденциальных данных.
По этой причине модуль управления API контроллера NGINX имеет инновационную архитектуру, которая снижает сложность. Разделив плоскость данных (NGINX Plus) и плоскость управления (модуль управления API), трафик времени выполнения API изолирован от трафика APIM, чтобы обеспечить более детерминированную и эффективную обработку.
Например, после развертывания NGINX в качестве шлюза API CapitalOne смогла списать три коммерческих шлюза и по-прежнему обрабатывать 12 миллиардов запросов в день с задержками всего в 10 миллисекунд.
Заключение: вы уже на пути к отличному APIX
Сказал вы это или нет, скорее всего, вы и ваша команда уже на пути к созданию APIX 2.0. Это естественный результат внедрения и развития APIM и шлюзов API. Эффективное управление APIM и шлюзом помогает предприятиям интегрировать внутренние системы и устранять разрозненность, способствовать сотрудничеству между разработчиками и функциональными группами и подключать микросервисы. APIM может отображать владение ключами и свойства безопасности API. Благодаря эффективному развертыванию APIM и шлюзов на основе созданных вами руководств вы и ваша команда можете обеспечить единообразное взаимодействие на протяжении всего жизненного цикла ваших приложений, размещенных в любом месте. Вы можете сделать это независимо от того, являются ли они облачным проектом или устаревшими приложениями, работающими в локальных центрах обработки данных.
Тем не менее, отличного APIX просто не бывает. Это должно быть сознательное усилие, которое должно быть тщательно направлено и управляемо. Мы надеемся, что четыре принципа, которые я изложил здесь, с помощью ряда ключевых экспертов по API в F5, могут дать вам прочную основу для создания лучшего опыта работы с API для вашего разработчика, клиентов, партнеров и пользователей. Теперь API-интерфейсы – это дороги и мосты, которые делают возможными современные архитектуры приложений. Поддержка и построение этой инфраструктуры виртуального API будет играть большую роль в определении успеха ваших приложений – и, в более широком смысле, успеха вашей компании.
При поддержке NGINX (часть F5)
