Сегодняшнее мероприятие ведет Владимир Силин, старший архитектор решений Software AG Россия и СНГ.
Он рассмотрит API как возможный инструмент цифровой трансформации бизнеса.
Software AG – это одна из старейших компаний, которая занималась исключительно разработкой программного обеспечения, она была образована в 1969 году, Основная цель этой компании – это разработка технологий для бизнеса. Компания интенсивно занимается расширением партнерской сети, работая с таким компаниями, как Dell, Microsoft, Amazon. Этот вендор занимает ведущее место в области Индустрии 4.0 и промышленном Интернете вещей. У Software AG уже более 10 000 заказчиков в более чем в 70 странах. Один из основных трендов, которым занимается вендор, это помощь заказчикам найти современный подход к интеграции.
Семейство продуктов, отвечающих за управление и работу с Интернетом вещей, это CUMULOCITY IoT. Основная интеграционная платформа, существующая в гибридном варианте и варианте развертывания в ЦОДе, и в облаке и обеспечивающая бесшовное взаимодействие двух разных платформ – WEBMETHODS и WEBMETHODS.IO. И того, что касается обработки больших объемов событийных данных, таких как APAMA, как ZEMENTIS, являющейся интерфейсом между средствами разработки правил ИИ и их внедрения в промышленную работу. TRENDMINER – это продукт, который активно используется для анализа процессов, особенно в химической отрасли.
Для большинства компаний характерны вызовы, которые состоят в том, что на рынке появляются новые продукты и услуги, некоторые из которых становятся прорывными для целых отраслей деятельности.
Для взаимодействия с клиентами возникают новые каналы, которые предлагают новые бизнес-возможности и ими необходимо уметь воспользоваться, поскольку они меняют поведение потребителей и покупатели хотят покупать по новым каналам. Если Вы не готовы к быстрому развертыванию или приспособлению к работе в новых каналах, то вы попадаете в ситуацию, когда ваши клиенты, которые хотели бы использовать мобильные каналы и приложения, социальные сети, а вы в них не присутствуете, то просто теряете их в пользу ваших конкурентов, которые вовсю используют эти новые каналы.
Компании все больше переносят свою инфраструктуру в облако. Считается, что облачные развертывания являются новой нормой, поскольку они позволяют преодолеть отсутствие гибкости, масштабируемости и в конце концов бюджета, которые характерны для компаний, управляемых информационными технологиями. Но облаками надо уметь пользоваться.
Еще одна тенденция, которая характерна для потребителей и партнеров, это получение информации в реальном режиме времени. Причем информация должна быть полная и непротиворечивая. И если ваши конкуренты смогут предоставить такой режим работы, а вы не сможете, то они станут забирать вашу клиентскую базу. И следует отметить, что современные бизнес-системы становятся все более и более гетерогенными. Они становятся все более распределенными между теми приложениями, которые работают в вашем центре обработки данных, которые работают в сетевых окружениях между поставщиками облачной инфраструктуры, здесь необходимо уметь собирать и уметь анализировать взаимодействие с данными, получаемыми по всем компонентам ваших корпоративных систем. И в результате получается достаточно сложная ситуация с интеграцией.
Поскольку системы в значительно степени, особенно унаследованные, являются сложными, а с другой стороны, системы становятся распределенными, но не решают проблему изолированности данных. Для того, чтобы реализовывать такие проекты, необходимы новые инвестиции, дорогостоящие экспертизы, интеграция. И в то же время накапливается объем невыполненных проектов ИТ. В частности, объясняется это тем, что не хватает инструментов и стандартов. И все это приводит к тому, что сама трансформация происходит медленно.
Анализируя эту причину, Software AG считает, что существующая проблема состоит в том, как согласовать возможности имеющихся данных и требуемой функциональности. Чтобы справиться с этими задачами, создать приложения для привлечения клиентов, сотрудников, необходимо использовать данные, которые уже у вас есть и находятся в вашем ведении.
В этом плане важным компонентом цифрового преобразования или цифровой трансформации являются API, поскольку они могут обеспечить доступ к данным и функциям в базовых приложениях, в базах данных. Они позволяют разработчикам создавать новые приложения и решения без необходимости знания внутренних деталей систем, к которым они подключаются. Тем самым обеспечивают возможность получения новых источников доходов, лучшего понимания состояния бизнеса с точки зрения того, каким образом вы можете обнаружить, например, нарушения в цепочке поставок, и тем самым сократить потери в этой цепочке, и соблюдать сроки доставок и пр. Чтобы позволить вам повысить операционную эффективность и автоматизировать процессы, которые связаны с обработкой или предоставлением необходимой информацией.
API облегчают взаимодействия, но они не обеспечивают взаимодействия разных корпоративных систем друг с другом. Ведь может оказаться, что API в разных источниках, имеют разные интерфейсы, как мы видим на этом слайде. У нас есть REST и SOAP интерфейсы, а таких самых разных их может быть много. Но для того, чтобы преодолеть различие в интерфейсах, моделях данных и шаблонах взаимодействия, обеспечить их синхронную и достойную работу, требуется использовать различные методы интеграции. Интеграция предполагает решение трех основных задач. Это обеспечение согласованности данных, автоматизация процессов для исключения ненужного взаимодействия и участия исполнителей, а также компоновка API, которая связана с разработкой приложений, использующих API интерфейсы, построенные на базе других систем.
Для успешной реализации и продвижения в области стратегии использования прикладных интерфейсов, нужно иметь четкие ответы на 5 вопросов:
1) С какой целью внедряются API и какие преимущества она даст для бизнеса вашей компании.
2) Кто является потребителем API. Это могут быть внутренние разработчики, особенно если компания имеет разветвленную региональную структуру, это могут быть и внешние потребители, например, бизнес-партнеры, поставщики или логистики и пр.
3) Где ваши пользователи могут найти и как воспользоваться API? Здесь речь идет о том, что было бы хорошо иметь возможность централизованного представления информации о этих API, о правилах их использования, авторизации и аутоинтефикации пользователей и условий применения.
4) Как оценить и то, какое влияние стратегия API окажет на архитектуру самого предприятия?
5) Как узнать, насколько успешна эта API инициатив. Для этого нужно API мониторить, мониторить те API, которые вы выдвигаете для общего применения.
Рассматривая болевые точки бизнеса, которые существуют или могут быть сформулированы таким образом, как это изображено на слайде слева, Software AG подготовила и активно внедряет у заказчиков следующие три основные продукта: WEBMETHODS API GATEWAY и WEBMETHODS MICROGATEWAY - это инструментарии для того, чтобы заниматься разработкой и публикацией API, оценивать и проводить мониторинг выполнения или использования данных API. И WEBMETHODS API PORTAL - это тот инструмент, с помощью которого решаются задачи ознакомления потенциальных пользователей с возможностями этого API, его тестирования, привлечения и развития сообщества разработчиков, поскольку на его базе можно проводить довольно популярные сейчас хакатоны по разработке каких-то конкретных решений по развитию той или иной инициативы в области API.
Платформа API Software AG не является чем-то совсем новым. Она развивается активно последние 5 лет. И за это время у Software AG появился богатый опыт или богатый перечень заказчиков в самых разных отраслях промышленности. Это и банки, и ретейл, и телеком и медиа, и транспорт, и производство. И это говорит о том, что каждой из этих отраслей платформы API от Software AG помогает решать вполне конкретные бизнес-задачи. И в чем их уникальность? Наверное, она может быть сформирована тремя основными моментами.
Прежде всего, это единая платформа API и ее интеграция. И более того, Gartner, оценивая возможности WEBMETHODS, сказал, что WEBMETHODS и API - это две стороны одной медали. Что, говоря об интеграции, нельзя не говорить об API, и, наоборот, говоря об API нельзя не говорить об интеграции.
И вторым важным моментом является защита и контроль доступа к API с помощью детальных конфигураций и политик, которые характерны для конкретных API. И управление полным жизненным циклом с момента появления их на свет и до вывода из эксплуатации. Архитектурно - это поддержка все более набирающих силу архитектур микросервисов и дополняющих эту архитектуру WEBMETHODS MICROGATEWAY.
Поскольку в принципе мы всегда находимся в поле внимания аналитической компании Forrester, которая, по сути, оценивает популярность того или иного продукта. Вот размер этого кружочка на слайде, определяет насколько популярен WEBMETHODS. Это определяется количеством внедрений тех или иных продуктов.
И с точки зрения управления жизненным циклом наша компания тоже находится в лидирующем квадранте Gartner. Так что, с этой точки зрения наши продукты также вполне достойно выглядят.
Архитектура
Как же на самом деле выглядит архитектура? Мы видим, что у нас уже есть очень много инвестиций, сделанных в локальные приложения, в стандартные приложения, типа ERP, в облачные приложения, которые существуют как бы сами по себе, иногда, правда, взаимодействуя с локальными.
И сейчас осуществляются мощные инвестиции в устройства. С другой стороны, эти инновации ожидаются бизнесом. Это прежде всего продвижение этих функционалов стандартных и локальных приложений в область взаимодействия с мобильными, с web-приложениями. Интеграция с Интернетом вещей, привлечение ИИ для того, чтобы оценивать события и данные, происходящие в правой стороне слайда, а также совершенствовать взаимодействия с бизнес-партнерами. И в этом плане Software AG говорит, что у нее достаточно уникальная архитектура, которая позволяет связать эти два мира. Мир существующих инвестиций и насущных инноваций с помощью того, что мы поддерживаем все правильные и архитектурные решения, обеспечивая и администрирование бизнес-партнеров, интегрируя и обеспечивая взаимосвязь различных компонентов по различным протоколам и поддерживая архитектуру микросервисов, ориентированную в первую очередь на обеспечение гибкости и масштабируемости сервисов. Администрирование API это как вершина этого стека, поскольку взаимодействие приложений, перечисленных в правой части, с инновационными направлениями будет выполняться через программный интерфейс, через API.
В этом плане архитектурно WEBMETHODS выглядит достаточно просто, но многоуровнево. С одной стороны, есть уровень интеграции, который обеспечивает взаимодействие с готовыми коннектерами, которые осуществляют обмен сообщениями, обмен документами business to business между унаследованными системами, базами данных, стандартными приложениями, развертываемыми как на предприятии, так и в облачных приложениях. А, учитывая то, что в каждой из этих видов источников информации или будучи их приемниками, имея свои специфики в плане протоколов, в плане представления форматов данных, необходимо это все нивелировать, вот для этого и используется уровень интеграции. Когда же мы начинаем переходить на уровень масштабируемости системы для повышения гибкости, мы переходим на слой мини- и микросервисов. Они доказали свою применимость, и именно этот уровень реализует масштабируемость, повышает гибкость и устойчивость всей системы.
Ну, и для организации связи с внешним миром появляется еще один слой, который называется API, в нашем случае это главные шлюзы. Но при этом следует отметить, что технология шлюзования существует в двух видах. На уровне микросервисов необходимо также уметь обеспечивать безопасность, надежность, маршрутизацию и прочие реквизиты. И для этого, при упрощении взаимодействия микросервисов, служат микрошлюзы, это в технике сейчас называется «обслуживание трафика Восток-Запад», т.е. взаимодействие микросервисов друг с другом. В то же время главный шлюз обеспечивает уже взаимодействие с внешними системами. Или взаимодействие «трафик Север-Юг». Такой сейчас существует взгляд на архитектуру.
Говоря о том, как эволюционировала архитектура сервисов, следует отметить, что развитие идет в сторону повышения динамичности и гибкости данных сервисов. И переход на микросервисы этому очень способствует, поскольку микросервисы объединяются в контейнеры, которые могут развертываться по необходимости и перемещаться между ЦОДами и облаками. Но только необходимо отметить, что эксплуатационная сложность и стоимость этого решения возрастает. И еще больше она возрастает, когда появляются сети сервисов. Эти Service Mesh, достаточно современная «штука». Потому что сервисные сети решают важную задачу.
Садясь как дополнительный proxy к конкретному микросервису, они обеспечивают решения таких задач, как обнаружение служб, мониторинг показателей, как отказоустойчивость, т.е. возможность перехода и перезапуска микросервисов в том или ином контейнере. При этом на сетевом уровне все это выглядит вполне прилично, при этом не нужно в каждый микросервис встраивать код, который бы выполнял эту работу. Но этого оказывается мало. Но микросервисы не дают представления о том, что же происходит на уровне приложения. И владельцам приложения хотелось бы увидеть, как используется их решение. Это позволило бы поставщикам быстрее создавать приложение на основе микросервисов и легко их менять, особо не влезая в микросервисы. И позволить управлять приложениями, особенно в облачной архитектуре.
Software AG объявила в октябре 2019 года о выпуске нового продукта, который называется WEBMETHODS APPMESH, он решает задачи, добавляя в контекст приложения решение таких важных задач, как интеллектуальная маршрутизация, защита данных между сервисами, обеспечение необходимой видимости с точки зрения того, каким образом мы могли бы понять, кто конкретно использует наши решения, как выполнять персонализацию. Имеется ввиду персонализация приложения, т.е. какому пользователю должны быть видны какие данные, и какие задачи он может выполнять, используя свои полномочия. Все это переносится на уровень сети приложений.
Обзор компонентов API платформы
Теперь перейдем к обзору компонентов API платформы, которую предлагает Software AG. По сути - это три больших компонента.
Это портал, используемый для внешних пользователей, чтобы обеспечить им доступ и ознакомление с возможностями того или иного API. Это и средство, с помощью которого разработчики API получают обратную связь о том, что за API они разработали, какие ошибки и какие пожелания со стороны потребителей возникают. Это та самая основа взаимодействия потребителей и поставщиков.
Шлюз API Gateway - это основной исполнительный механизм. Его основной задачей является защита API от всего незарегистрированного, и особенно от злонамеренных атак. Это мониторинг, отслеживание и использование API. И это продвижение API между этапами жизненного цикла.
API Catalog, который известен, как CentraSite. Его назначение заключается в определении, описании API, выявлении их взаимозависимостей. Характерно, что все эти компоненты доступны и в режиме облака, и режиме гибрида.
Начнем со шлюза WEBMETHODS API GATEWAY. Он обеспечивает защиту API и может быть развернут и в зеленой зоне, и в DMZ. У него есть современный web-интерфейс, который является не более, чем примером реализации тех внутренних API, на которых построен сам шлюз. Т.е. если по какой-то причине вам не хватает того функционала, который есть на картинке, вы всегда можете его дополнить, вызывая те или другие внутренние API, которые хорошо документированы и являются неотъемлемой частью самого продукта.
WEBMETHODS MICROGATEWAY это новый компонент, который появился сравнительно недавно. И смысл его назначения – управлять доступом к микросервису. И в этом случае он может выполнять все те политики, которые мы можем применять в обычном GATEWAY к конкретным сервисам. Мы эти политики можем импортировать при запуске этого MICROGATEWAY. И они будут характерны только для него, но можем задавать их и автономно.
При развертывании в DMZ весьма популярной является реализация глобальных политик защиты от угроз. И этих политик достаточно много: фильтры, размеры сообщений, фильтры по авторизации и другие. Все эти фильтры настраиваются самим администратором самого шлюза.
Примеры тех политик, которые могут быть реализованы в GATEWAY, приведены на слайде. Их восемь: 1) защита от угроз, 2) определение транспорта, 3) идентификация и права доступа на конкретный API, 4) возможность трансформации для обработки входящих запросов, 5) возможности мониторинга трафика, 6) маршрутизация (получив запрос, шлюз имеет возможность выполнить маршрутизацию напрямую, или может выполнить маршрутизацию исходя из значений заголовков или даже текста того сообщения, которое он получил), 7) обработка ответов, 8) обработка ошибок, которые возникают при выполнение этих сервисов.
В части безопасности добавить нечего. Он обеспечивает все то, что может позволить … и то, что может позволить SOAP. Весьма развитые, на мой взгляд, политики.
Портал WEBMETHODS API PORTAL - это средство взаимодействия и сосуществования поставщиков API и потребителей API, поскольку в данном случае это место, где эти две категории людей начинают взаимодействовать друг с другом. Очень важно, что портал является многоарендным. Т.е. на одном экземпляре, одном инстансе портала можно развернуть несколько арендаторов. И эти несколько арендаторов могут быть как разными функциональными подразделениями, так и разными как бы порталами, предназначенными для разных этапов жизненного цикла конкретного API. Например, арендатор-разработчик и арендатор-тестировщик могут иметь свои составы API со своими правилами и политиками.