API-интерфейсы соединяют приложения - и замедляют их работу

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

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

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

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

Этот беспорядок API-интерфейсов - лишь еще один фактор, усложняющий сегодняшнюю современную ИТ-среду. Кроме того, сами API-интерфейсы могут сильно различаться по надежности и зрелости. Однако не отказывайтесь от фактического управления ими. Есть способ сделать это.

Как избежать разрастания API

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

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

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

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

Сценарии Selenium, которые умело складываются в Milestones, позволяют AppNeta видеть, когда действие пользователя завершено. Это означает, что вы можете видеть детали синхронизации для любой последовательности действий, даже в одностраничном приложении. Таким образом, наши пользователи видят, где именно возникает проблема:в рабочем процессе, при загрузке ресурсов или на нескольких страницах.