Інтеграційні платформи (iPaaS): у чому фішка

Привіт, мене звуть Ярослав, і в цій статті я розповім про Integration Platforms (iPaaS), що використовують у різних проектах у компанії SoftServe і робочих практиках System Integration Engineer.

Дефініції та історична довідка

Що ж таке Data integration? Основна функція Data integration ― маршрутизація даних з розрізнених джерел (баз даних, систем, мобільних/веб-застосунків через API тощо) в єдину систему/платформу в межах організації або організацій. Наступне завдання — узгодження різних типів даних з єдиним форматом, що використовуватимуть під час будь-яких маніпуляцій, трансформацій або синхронізації.

Інтеграційний напрям виник унаслідок різкого збільшення протягом останніх 10 років кількості різноманітних систем, що застосовують усередині організацій (Human Capital Management, Portals, Apps тощо), та, відповідно, потреби у швидкій синхронізації даних між цими системами. До певного часу інтеграційну функцію виконувало ESB, основною метою якого було, по суті, забезпечити транзакційний контроль, перетворення даних і маніпуляції з ними. Згодом інтеграційні завдання стали складнішими й комплекснішими, а отже, вони потребують окремих підходів, специфічних навичок і тулсету.

До ESBПісля ESB

Від ESB до iPaaS

Згодом підхід ESB еволюціонував, і почали з’являтися так звані iPaaS-рішення. Беручи на себе основні функції low-level-девелопменту і спростивши або навіть цілком перебравши на себе підходи до security, data encryption/decryption, data transformation, deployment-процедури, інтеграційні платформи дали змогу розробникам інвестувати суттєво більше часу саме в інженерний підхід.

Основні відмінності між ESB та iPaaS

Загалом підхід ESB виник унаслідок потреби в керуванні даними в локальних або застарілих legacy-системах. Історично ESB-патерн виник ще задовго до хмарних систем/інтеграцій, він підходить для координації та роботи з даними, але, на мій погляд, цьому підходу бракує гнучкості.

Інтеграційні платформи (iPaaS) створено для підтримання хмарних рішень/систем. Теоретично iPaaS можуть зменшити або усунути потребу в локальних серверах чи апаратному забезпеченні, також iPaaS розроблено для керування інтеграцією з хмарних застосунків.

Масштабованість (Scalability)

ESB-підхід можна використовувати для вертикального масштабування в наявному архітектурному рішенні. Зокрема, iPaaS більше підходить для горизонтального масштабування (наприклад, додавання до наявного середовища нових підсистем/систем або компонент).

Наступна і, на мій погляд, основна відмінність — Multitenancy-підхід. Тут саме iPaaS має очевидну перевагу, адже є змога надавати доступ у реальному часі до даних, що зберігають у різних системах або застосунках. ESB-підхід менш адаптований до виконання завдань такої складності.

Окрім ESB-підходу, інтеграційні платформи зробили величезний крок щодо підтримки мікросервісної архітектури. Наприклад, більшість платформ (Dell Boomi, MuleSoft тощо) містять і підтримують:

  • API Management;
  • Discoverability;
  • Serialization;
  • Dynamic Process Routing;
  • Support for Docker;
  • Support for External Load Balancers;
  • Support for Custom Authentication;
  • Support for industry protocols for inter-process communication;
  • Platform APIs.

Також однією з основних переваг інтеграційних платформ є використання так званих InBox Connectors ― готових рішень для забезпечення зв’язку/з’єднання з різноманітними системами. Наприклад, якщо розглядати таку платформу як Dell Boomi, можна побачити, що вони покрили своїми «конекторами» більшість відомих і можливих платформ.

Завдяки Data Mapping інтеграційні платформи також дають змогу швидко трансформувати дані з одного формату в інший (можна опрацьовувати відповідну структуру даних через профайли).

Dell Boomi Data Mapping

MuleSoft DataWeave

Підсумовуючи все зазначене вище, скажу таке: інтеграційні платформи створили низку можливостей, за допомогою яких можна побудувати доволі комплексні рішення з мінімальними часовими затратами. Це дуже актуально, враховуючи складність інтеграційних завдань, з якими ми починаємо стикатися на практиці. Для прикладу, одним з найбільших проектів, в якому мені доводилося працювати, була побудова системи, що синхронізувала дані між enterprise-системою (величезною мережею супермаркетів у США) та чотирма різними HCM-системами. У такому разі синхронізація відбувалася за допомогою eventdriven near-realtime-підходу, тобто інтеграційне рішення реагувало на події в різних системах, що в результаті тригерили інтеграцію і синхронізували дані.

Огляд найліпших інтеграційних платформ

Більшість наявних тепер інтеграційних платформ підтримують ключові інтеграційні й комунікаційні патерни, зокрема application-to-application, publisher-subscriber, real-time and event-driven web services, streaming, batch, ETL.

Однією з перших на ринку з’явилася Informatica, що й досі лишається однією з найстабільніших платформ. Першість зробила її лідером, однак щодо гнучкості, підходів до розробки й інтерфейсу, на мій погляд, наступні два інструменти цікавіші.

На другому місці за популярністю, згідно з Gartner Magic Quadrant for Enterprise Integration Platform as a Service, — платформа Dell Boomi.

Dell Boomi дає змогу побудувати складне інтеграційне рішення за порівняно короткий проміжок часу. Наприклад, я прораховував часові затрати на мінімальний проект, що з’єднував SuccessFactors і HCM-систему одного з клієнтів (ураховуючи тестування, моніторинг, деплоймент-процедуру). Затрати на ESB-based-прототип, написаний на Java + Deployment, займав приблизно в 10 разів більше часу й утричі більше ресурсів, ніж такий самий прототип, побудований за допомогою Dell Boomi iPaaS-рішення. Звичайно, використання платформ, попри переваги у швидкості розробки, має й певні негативні наслідки, зокрема під час розробки доведеться враховувати наявні дефекти платформ, downtime й оновлення. Однак сукупні переваги все ж суттєво більші.

Ще одна популярна платформа, з якою мені доводилося працювати в межах низки проектів, ― MuleSoft. Її основна перевага — доволі звичне для Java-розробника середовище, а також можливість працювати з інтеграційними рішеннями на нижчому рівні.

З чого розпочинати роботу з інтеграційними платформами

Відверто кажучи, для мене як для Java-розробника перейти від класичної розробки до інтеграційних рішень було досить важким кроком. Спочатку ресурсів, які розкривали б усі можливості платформ, було не так уже й багато, а ті, що мені вдалося знайти, були не з дешевих. Та завдяки менеджменту компанії я таки дістав змогу поспілкуватися з розробниками з Dell й набути відповідні знання і сертифікації.

Наступна проблема — те, що функція System Integration Engineer порівняно нішева й не дуже поширена на українському ринку розробників. Як наслідок ― відсутність у більшості компаній кар’єрного зростання спеціалістів цього напряму; труднощі з пошуком кваліфікованих спеціалістів на ринку й навчальних рішень для них. Попри те, що використання iPaaS-рішень доволі популярна практика в США та, наприклад, Австралії, знайти розробників на ринку України досить важке й комплексне завдання, яке ми з колегами розв’язали за допомогою побудови різноманітних курсів у SoftServe ІТ Academy, ramp-up-програм у межах компанії. Сукупно це все перетворилося на цілу окрему гілку в компанії зі своїми підрівнями й кар’єрним зростанням у System Integration Engineer.

Якщо взяти позицію Intermediate System Integration Engineer у компанії, базовий технічний стек потрібних знань матиме приблизно такий вигляд:

  • базові знання Java/.NET/Python;
  • базові знання JavaScript/Groovy;
  • розуміння структури REST/SOAP Web Services;
  • базові знання DB Desing/Quering;
  • базові знання Security Principals (Security Mechanisms, Authentication Types, Characteristics of Application Security);
  • Cloud Services (Compute Engines, Monitoring Services, Load Balancing, Auto Scaling тощо);
  • Data Interchange Formats (JSON/XMLStructure, Parsers, XSLT);
  • IntegrationPlatform (Proficient knowledge of Integration Platform configuration management principles, working with Batch and Near Real time data processing, design complex processes including, working with licenses, complex data mapping, base introduction into Integration Platforms sripting. This capability level also includes proficient
  • knowledge of implementing web services connectors using REST or SOAP principles, connecting and working with DBdata. Error and Exception handling. Working with revisions);
  • сертифікації (тут залежить від конкретно вибраної платформи).

Найвища кар’єрна ланка ― Expert System Integration Engineer ― архітектурна позиція, що передбачає поглиблені знання у переліченому вище стеку й експертні/поглиблені знання в кількох інтеграційних платформах.

Якщо вас цікавить напрям системних інтеграцій і ви вирішили копнути глибше, нижче пропоную кілька корисних посилань.

Інформація про платформи:

Огляд патернів і підходів до розробки:

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn

Схожі статті




18 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Чисто с функциональной точки зрения я бы не стал так разделять ESB и IPAAS, ибо с хорошим ESB можно делать интеграции любой сложности вне зависимости от того, интегрируемся мы с легаси говном или модными облаками. Тот же Mule, например, предлагает как облачное решение, так и обычное on-prem, причем в облако можно деплоить прямо из IDE в CloudHub в один клик и в on-prem в два. Да и вообще его можно запускать где угодно, хоть на Raspberry PI
blogs.mulesoft.com/...​mule-4-on-a-raspberry-pi
Вообще IPAAS не является панацеей и является скорее данью моде — да, много плюсов, особенно горизонтальное масшатибирование,но в итоге цена возростает непропорционально так как дерут за все,впаивают ограничения (всего 10 приложений на 1 vCore у Mulesoft), чарджат за коннекторы (Dell Boomi) и т.д. Поэтому к вопросу выбора типа интеграционной платформы нужно подходить взвешенно. Иногда проще и дешевле развернуть on-prem или использовать гибридные решения:
www.ms3-inc.com/...​t/cloudhub-vs-on-premise
Мы как раз собираемся мигрировать из on-prem в Azure в скором будущем — в итоге должно получится дешевле, чем on-prem или в CloudHub и без потерь в фунциональности.

Затрати на ESB-based-прототип, написаний на Java + Deployment, займав приблизно в 10 разів більше часу й утричі більше ресурсів, ніж такий самий прототип, побудований за допомогою Dell Boomi iPaaS-рішення.

помню, Ruby on Rails в свое время так активно рекламировали :)

атрати на ESB-based-прототип, написаний на Java + Deployment, займав приблизно в 10 разів більше часу й утричі більше ресурсів, ніж такий самий прототип, побудований за допомогою Dell Boomi iPaaS-рішення.

Є таке ж порівняння з Kafka? Як на мене Kafka найкращий вибір для ESB з однієї причини — open source з усіма плюшками — багато матеріалу на будьяку тему, коммюніті, перевірене часом в багатьох глобальних компаніях (Linkedin,Netflix,..), можна спробувати розібратись в проблемі самостійно, а не заводити тікет для вендора з 10мб архівом логів (як правило того що треба там небуде ) і т,д

мне кроме озвученных вопросов интересно как этот IPaaS решит следующие 3 задачи

— есть 2 систем и 100 разных дешбордов, что сорсятся из агрегируют данных из этих двух систем, надо строить в реал тайме, что может предложить этот iPaaS?
— есть 100 к IOT датчиков, из которых надо получать данных для какой-то системы в реальном времени и применить к входному потоку данных ETL — что в этом случае могут предложить данные платформы интеграции?
— есть необходимость посадить 30 девелоперов ментейнить ETL, что бы все они могли их безопасно вести паралелльно разработку диплоить в прод с полной автоматизацией процесса и автоматическими проверками(тесты, билд гейты и тому подонбное) и не мешать друг другу

как будут решатся данные задачи?

Стосовно перших двох запитань — якщо розглядати, наприклад Dell Boomi,думаю, що проблем з реалізацією поставлених задач не буде жодних, все буде залежати від ціни яку доведеться заплатити за додаткові фічі/ліцензії і т.д. Я, на жаль, не можу розповісти докладно про проекти і клієнтів з якими доводилось працювати, у зв’язку з NDA, але ось тут є непогана стаття на цю тему: resources.boomi.com/...​gs-depends-on-integration
Стосовно третього запитання, так, підхід до розробки (та і загалом SDLC ) дещо відрізняється від класичного. Але такі речі як,наприклад, «Component Locking», автоматизація процесу деплойменту, version control, моніторинг в своїй інтерпретації теж присутні.

Понятно, спасибо. было бы интересно почитать какие-то технические статьи на просторах интернета или презентации даже, а не маркетинговые записки от продажников Dell.А именно как решались конкретные задачи — я им больше доверяю.Эта статья типичный маркетинговый bullshit к сожалению.

«Component Locking»

Если я вас правильно понял, то это достаточно устаревший от отживший подход. применлся в корпоративном софте в 00х в том числе для ETL и всяких SOAP ESB платформ. Основная причина — медленно, без надлежавшей автоматизации и не скейлится. Если там применяют таких подходы, то впринципе понятно положение дел с организацией процесса разработки — быстрее в 5 раз сделай что-то со старту, но больше 1-2 х девелоперов в этом вариться не смогут.

Стосовно технічних аспектів і більш глибшого аналізу конкретних платформ, я планую, як тільки буде ще кілька вільних годин часу, розписати більш докладніше. Стосовно «Component Locking» це — як приклад, підходів до реалізації паралельної розробки/мультитаскінгу є багато. Якщо, наприклад, розглядати MuleSoft, сам процес і підхід до розробки там відбуватиметься значно звичніше/ближче до класичного.

как будут решатся данные задачи?

Треба брати платформу Blynk :). В нас це все є.
Архітектурно все порішали дуже просто — моноліт.

Крутая платформа, молодцы. А как CEP сценарии сделать у вас или ввести новую фичу которой нужна телеметрия с девайсов за последний год?

А как CEP сценарии сделать у вас

Якщо CEP це event processing, то у нас є рул енджін, аналог node-red.

ввести новую фичу которой нужна телеметрия с девайсов за последний год

Ну в нас вже є розділ аналітики де можна багато чого собі сконфігурувати з різних блоків.

Якщо CEP це event processing, то у нас є рул енджін, аналог node-red.

Окно можно сделать за 8 часов по объединённым сообщениям из нескольких девайсов и по нему кверить? Примеры — storm, flink, spark cep.

Ну в нас вже є розділ аналітики де можна багато чого собі сконфігурувати з різних блоків.

Это здорово, но я так и не понял если я год проработал в проде и хочу аналитику по телеметрии за последний год новую сделать — мне достаточно будет будет переклнфигурировать блоки и у меня будут новые дешборды по историческим данным за последний год?

Окно можно сделать за 8 часов по объединённым сообщениям из нескольких девайсов и по нему кверить?

Так. Це і є наша аналітика. Поки що ми під кожного клієнта формуємо конкретні квері, які потрібні конкретно цьому клієнту. Квері білдер це дуже складна задача і ми від нього відмовились.

мне достаточно будет будет переклнфигурировать блоки и у меня будут новые дешборды по историческим данным за последний год?

Так.

Так. Це і є наша аналітика. Поки що ми під кожного клієнта формуємо конкретні квері, які потрібні конкретно цьому клієнту. Квері білдер це дуже складна задача і ми від нього відмовились.

а где телеметрию храните и за счет чего можете в скейл, какие SLA обещаете?

а где телеметрию храните

Клікхаус. В основному через компресію.

за счет чего можете в скейл

За рахунок вертикального масштабування. На 5$ сервері можна хедлити під 100к девайсів. Дял супер великих проектів теж є рішення, але поки таких не заходило.

какие SLA обещаете

99.9%. Взагалі за минулий рік в нас був 100% аптайм, якщо говрити про паблік клауд.

Привіт, стосовно Kafka — в більшості, так, я з Вами погоджусь,
Apache Kafka, доволі непогано справляється з поставленими задачами і достатньо гнучка для реалізації горизонтального масштабування. Але якщо мова заходить за налаштування, адміністрування та підтримку імплементованих рішень, тут в iPaaS є певні переваги. Згоден також, що ціна iPaaS платформ явно вища за open source рішення. Але стосовно якості та швидкості імплементації я все ж таки, наразі, бачу перевагу на боці інтеграційних платформ.

Але якщо мова заходить за налаштування, адміністрування та підтримку імплементованих рішень, тут в iPaaS є певні переваги.

Kafka есть тоже fully managed в облаке разных вендоров — HD Insights, MSK. Более того интегрируеться нативно в их cloud инфраструктуру и куда более devops friendly в этом случае.
Дополнительно ничего не надо лицензировать — просто платишь в облаке за hardware.

Как же все любят картинки из интро к Zato.

На первой картинке из бардака делают упорядоченный бардак.

Підписатись на коментарі