Джефф Безос из Amazon известен своей служебной запиской, которая изменила Amazon и мир программного обеспечения1. По сути, в ней говорилось следующее:
Все команды будут предоставлять свои данные и функциональность через сервисные интерфейсы (т.е. API), и команды должны взаимодействовать друг с другом через эти интерфейсы.
Никакие другие формы межпроцессного взаимодействия не допускаются: ни прямое связывание, ни прямое чтение хранилища данных другой команды, ни модель общей памяти, ни какие бы то ни было бэкдоры. Единственное, что разрешено - это взаимодействие через вызовы сервисных интерфейсов по сети.
Неважно, какую технологию они используют. HTTP, Corba, Pub- sub, пользовательские протоколы - неважно. Безосу все равно.
Все без исключения интерфейсы сервисов должны быть с нуля спроектированы таким образом, чтобы их можно было использовать для внешних целей. Иными словами, команда должна планировать и проектировать так, чтобы иметь возможность открыть интерфейс для разработчиков во внешнем мире. Никаких исключений.
Тот, кто этого не сделает, будет уволен.
API упрощают интеграцию между приложениями, ограждая команды разработчиков от сложности различных уровней, что ускоряет выход на рынок и снижает вероятность возникновения новых проблем в существующих приложениях. Эти интерфейсы также позволяют легче заменять отдельные компоненты при изменении требований.
Однако, учитывая эти преимущества, компании склонны создавать слишком много API. Зачастую массовое распространение API столь же вредно, как и распространение веб-сервисов и даже интерфейсов "точка-точка" в унаследованных архитектурах. Сведите к минимуму количество API и оптимизируйте их использование. API - это абсолютный ключ к развязке, но ими нужно управлять2.
Представление и удобство использования API-интерфейсов имеют решающее значение для использования их преимуществ. Используйте платформу управления (часто называемую шлюзом) для создания и публикации API, внедрения политик использования, контроля доступа, измерения использования и производительности. Такая платформа также позволяет agile-подразделениям искать существующие API и использовать их повторно, а не создавать новые. Внедрите стандарты, рекомендации и таксономию, чтобы обеспечить последовательное создание и использование API.
Одна фармацевтическая компания, например, создала внутренний "рынок данных" для всех сотрудников с помощью API, чтобы упростить и стандартизировать доступ к основным информационным ресурсам, а не полагаться на собственные интерфейсы. Компания постепенно - в течение 18 месяцев - перевела наиболее ценные существующие потоки данных в структуру, основанную на API, и развернула платформу управления для предоставления API пользователям. Такая архитектура корпоративных данных позволила значительно ускорить разработку и внедрение инноваций, основанных на аналитике и искусственном интеллекте.
По их словам: Трансформация API
"[Сначала мы определили приоритетность наших API, структурировав] существующие сервисы в нашей корпоративной сервисной шине (ESB) по стандартным банковским доменам, таким как клиент и продукт. Мы также определили приоритетность некоторых небанковских
API как "общие" или "для взаимодействия с каналами", например, кампании, предложения и функции оптического распознавания символов (OCR).
Затем мы определили приоритетность сервисов, исходя из их актуальности для нашей трансформации - то есть когда нам нужно будет отсоединить каждую ИТ-платформу для модернизации, - а также уровня сложности. Основываясь на этих критериях, мы смогли лучше понять, каковы будут общие усилия по "API-зации" нашей ИТ-архитектуры. Затем мы приступили к описанию операционной модели и управления, а также к детализации таксономии API, стандартов и рекомендаций. Наконец, мы определились с технологическим решением для платформы управления API и другими соответствующими компонентами и приступили к первой пробной версии концепции.
Мы объяснили руководству важность и потенциал API как для технологий, так и для бизнеса и выделили на это значительную часть бюджета. Начального финансирования хватило, чтобы заложить технологическую основу, определить необходимые стандарты и политики и перевести все наши сервисы с устаревшего ESB на микросервисы, доступные через наши стандартные API. Сейчас у нас доступно около 800 микросервисов.
Эта основа позволила нам создать три agile-отряда, которые занимались исключительно созданием API в различных областях. Мы начали работу над API, проведя несколько информационных сессий по API в ИТ-отделе, а также распространили информацию среди наших коллег по бизнесу, чтобы помочь нашим сотрудникам понять возможности.
