API в современных ИТ-инфраструктурах — это способ программного взаимодействия с системой. С помощью API можно управлять различными системами и их компонентами: например в случае с виртуальной инфраструктурой возможно управление виртуальными машинами, сетями, ресурсами хранилищ и другими компонентами. При этом существуют два разных подхода к организации API: единый интерфейс, объединяющий все компоненты под одной системой управления, и подход с разрозненными API для каждого компонента.
Выбор между этими методами напрямую зависит от масштаба и сложности инфраструктуры. В небольших системах с ограниченным числом компонентов разрозненные API могут быть приемлемы. Однако с ростом масштаба и сложности инфраструктуры преимущества единого API становятся всё более очевидными, но если к этому моменту уже используется устаревший подход с дискретным API, то практика показывает, что на этом этапе замена уже маловероятна, так как она обусловлена большими трудозатратами.
Управление компонентами инфраструктуры
Проблема дискретности в классическом подходе
В классической модели все компоненты инфраструктуры связываются друг с другом через собственные API. Это создает ситуацию, когда даже для выполнения простой задачи требуется взаимодействие с несколькими компонентами. Например, увеличение размера диска виртуальной машины предполагает сначала изменение конфигурации в слое хранения, а затем последующую синхронизацию этих изменений с гипервизором.
Такие операции не являются атомарными — для их выполнения требуется несколько шагов. Даже если все компоненты объединены в одну инфраструктуру, фактически их управление осуществляется раздельно, через несколько точек входа.
Проблема согласованности данных
Основная сложность дискретного подхода заключается не только в разрозненности интерфейсов управления, но и в том, что каждый компонент оперирует своими объектами, которые зачастую не синхронизированы между собой. Например, объекты в гипервизоре могут не иметь прямой связи с объектами в системе хранения, что приводит к несогласованности данных и требует дополнительных усилий для поддержания их консистентности. В результате вместо целостной инфраструктуры формируется совокупность изолированных подсистем, каждая из которых требует отдельного подхода к управлению.
В корпоративных средах этот подход создает риски. При выполнении комплексных операций существует вероятность, что изменения будут применены только в части компонентов, что приведет к нарушению консистентности элементов инфраструктуры.
Единый API предлагает управление всеми компонентами инфраструктуры. А отсутствие консистентности искусственно создает сложности в настройке и мониторинге, а также нарушает связи между объектами. Администраторы могут управлять виртуальными машинами, хранилищами и сетевыми ресурсами через единую точку входа, не вникая в детали взаимодействия этих объектов на уровне отдельных систем.
Такой подход особенно полезен в корпоративных системах, где количество компонентов велико и постоянно растет. Ручное управление каждым из них в таких условиях становится неэффективным и подверженным ошибкам.
Интеграция сервисов
Сложности интеграции в разрозненных системах
Интеграция разнородных систем в рамках одной инфраструктуры — задача, требующая согласования множества API. Каждый компонент имеет свои уникальные интерфейсы и объектные модели, что значительно усложняет их взаимодействие. Например, изменение конфигурации сети может потребовать ручного обновления настроек в нескольких зависимых системах.
А когда инфраструктура расширяется и начинает взаимодействовать с множеством внешних сервисов, удобная и стабильная интеграция становится необходимой. Если в небольшой виртуальной среде без особых внешних взаимодействий еще можно вручную управлять компонентами, то в инфраструктуре корпоративного уровня такой подход уже неприемлем. В таких случаях API используются не только для автоматизации, но и для интеграции с другими информационными системами.
Пример автоматизации с ESM-системами
Рассмотрим практический пример: клиент запрашивает тестовую среду для пилотного запуска продукта. В идеальном сценарии система должна автоматически создать виртуальный дата-центр (VDC), добавить пользователя, назначить ему необходимые права.
В системах с единым API, таких, как ESM (Enterprise Service Management), взаимодействие происходит на уровне высокоуровневых команд. Один API-запрос может запустить цепочку связанных процессов: создать VDC, настроить пользователя, назначить права — и всё это без необходимости явного управления каждым шагом. Консистентность поддерживается автоматически, а конечный результат предсказуем.
В противоположность этому, в системах с дискретными API каждый шаг требует отдельного взаимодействия с разными интерфейсами. Создание VDC, настройка пользователя, назначение прав — каждая операция выполняется изолированно. Это требует дополнительной логики для обеспечения согласованности между этими компонентами. Более того, поскольку запросы, как правило, асинхронные, требуется дополнительный механизм отслеживания их выполнения, что еще больше усложняет процесс.
Проблема консистентности данных
Важно понимать разницу между постоянной и событийной консистентностью. В системах с постоянной консистентностью (характерной для единого API) данные всегда находятся в согласованном состоянии. В системах с событийной консистентностью согласованность достигается только периодически, после выполнения определенных операций синхронизации.
Проблема систем с событийной или отсутствующей консистентностью в том, что они требуют дополнительных усилий для поддержания связности данных. Если, например, вы создали VDC, но не синхронизировали его с системой управления пользователями, это может привести к ошибкам доступа и другим непредвиденным проблемам.
Масштабирование и развитие корпоративных систем
Проблема взаимодействия при росте числа компонентов
Корпоративная ИТ-инфраструктура редко остается статичной — количество модулей постоянно растет, и каждый новый компонент необходимо интегрировать в существующую систему. В среде с разрозненными API у каждого модуля «свой язык»: чтобы они могли взаимодействовать, каждый из них должен понимать API всех остальных.
Математически это создает проблему N×N взаимодействий, где N — количество модулей. С увеличением числа компонентов сложность их взаимодействия растет квадратично. Если в системе 5 модулей, то потенциально существует 20 различных взаимодействий между ними. Если количество модулей увеличивается до 10, число потенциальных взаимодействий возрастает до 90.
Адаптация и масштабирование через единый подход
Даже если количество компонентов остается неизменным, со временем возникает необходимость вносить изменения в существующие модули — для обновления функциональности, исправления ошибок или оптимизации производительности. Эти изменения неизбежно затрагивают API и требует синхронного обновления всех связанных модулей. В крупных корпоративных системах такие изменения становятся сложной и рискованной задачей, требующей координации между разными командами разработчиков.
С единым API архитектура взаимодействия существенно упрощается. Модулям больше не нужно «учить языки» друг друга — они взаимодействуют через общий интерфейс, который автоматически преобразует данные и поддерживает их консистентность. Это снижает сложность с N×N до 2×N, где каждый модуль взаимодействует только с единым API, а не со всеми остальными модулями.
В гиперконвергентной платформе vStack единый API реализуется на базе JSON-RPC, что обеспечивает унифицированный способ взаимодействия со всеми компонентами инфраструктуры. Это значительно упрощает автоматизацию типовых операций и избавляет администраторов от необходимости координировать взаимодействие между различными подсистемами.
Заключение
Для компаний, управляющих корпоративной инфраструктурой, внедрение единого API — это не просто технологическое удобство, а способ снизить операционные затраты, уменьшить количество ошибок и ускорить внедрение новой функциональности.