DOU Labs: як в ELEKS створили інтеграційну платформу для підприємств, або Автоматизовуємо великий бізнес

У рубриці DOU Labsми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на editors@dou.ua.

Привіт, мене звати Дмитро, я Integration Architect у компанії ELEKS. У цій статті розповім про архітектурний підхід, який ми використовуємо для інтегрування систем, цифрування й автоматизування бізнес-процесів на великих підприємствах.

Ідея

Основна мета, яка привела до створення архітектурного шаблону, — це автоматизування бізнес-процесів і/або публікування API для великих підприємств. Тут слово «великих» приховує за собою значну кількість ІТ-систем, котрі забезпечують роботу цих підприємств.

Перша проблема, з якою ми стикаємося в таких завданнях, — системи використовують різні (іноді пропрієтарні) протоколи для інтегрування. З низкою «закритих» систем можна інтегруватися тільки на рівні даних.

Друга проблема — це безпека: різноманітні способи автентифікування й авторизування, безпека сховищ даних користувачів і їхніх ролей, груп та політик безпеки тощо.

Та останнє, але часто вирішальне — сукупна вартість володіння продуктом (total cost of ownership (TCO)).

Для розуміння нашого підходу наведу приклад бізнесового процесу, який є на будь-якому підприємстві, але зазвичай не є автоматизованим — процес звільнення працівника. Йому потрібно взяти обхідний лист, фізично обійти відповідальних працівників та одержати підтвердження як підпис. Між підписами можуть бути залежності: «Я не поставлю свого підпису, якщо ті троє цього не зроблять...» Процес супроводжується закриттям облікових записів у різних ІТ-системах. І наприкінці цього процесу головна людина — бухгалтер — видає йому трудову книжку.

Запитайте себе: чому цей та інші процеси на підприємствах не автоматизовано? Великі підприємства — це купа маленьких систем, а іноді Excel-файлів, які зінтегровано між собою через людей і папірці. Перше, що пропонують для автоматизування й інтегрування, — поставити та налаштувати систему планування ресурсів підприємства (ERP), яка має поглинути всі системи. Для підприємства це значна зміна процесів та ІТ-архітектури. Та це все виходить дуже дорого.

Ми хочемо показати, що сьогодні існує багато систем з відкритим кодом, які можуть задовольнити всі інтеграційні потреби підприємств.

Команда, яка працювала над проектом

Вирішення

Отже, вирішення було описано ще в межах сервісно-орієнтованої архітектури (SOA): «Архітектурний шаблон програмного забезпечення, модульний підхід до розробки програмного забезпечення, який ґрунтується на використанні розподілених, слабко пов’язаних замінних компонентів, які оснащено стандартизованими інтерфейсами для взаємодії за стандартизованими протоколами».

Доповнено основними ідеями мікросервісної архітектури:

• Незалежне масштабування (IHMO — це основний бонус мікросервісів).
• Незалежна розробка й незалежне розгортання.
• Невелика кодова база зменшує кількість конфліктів і дає змогу швидко залучати нових розробників.
• Простота замінювання однієї реалізації сервісу іншою.

І, звичайно, розвиток хмарних вирішень вимагає від нас гнучкості в реалізації (гнучкості в архітектурі?).

Критика

Головним пунктом критики сервісно-орієнтованої й мікросервісноїархітектур є: «витрати (latency) в разі передання мережею та перетворення форматів».

Ми апріорі перебуваємо в ситуації, коли маємо багато систем, і всі дані й бізнесові функції рознесено, і вони доступні переважно в мережі. Тому нам не уникнути ні передавання даних мережею, ні форматів. І ця ситуація ідеальна для створення сервісно-орієнтованої чи мікросервісної архітектури. Щодо форматів, то JSON/Swagger (OpenAPI) витісняє SOAP/WSDL через їхню надлишковість і складність. Чи не ефективніше використовувати рідні протоколи без посередників?

В одному з проектів, бізнесовий успіх якого був сумнівний, потрібно було зберегти фотографії клієнта, проте сховища для таких документів не було. Знайшлося файлове сховище, доступне за протоколом NFS.Зробили REST-сервіс, який реагує на GET/PUT/DELETE-запити й здійснює відповідні операції з файлами через NFS. Бізнесова ідея виявилася успішною, проте сервіс роботи з файлами став «тісним місцем» у процесі. Але після того як ми позбулися NFS у ланцюжку викликів, перемістивши сервіс на машину з файловим сховищем, сервіс запрацював у десятки разів швидше, а максимальна кількість одночасних запитів збільшилася в тисячі разів.

Реалізація

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

Компоненти платформи

Ця платформа є архітектурним шаблоном для проектів, компоненти якого можна розгорнути як у хмарах (публічних або приватних), так і на звичайних віртуальних чи локальних машинах.

У колонці «імплементування» розміщено одне з найкращих, на наш погляд, вирішень із відкритим кодом (open-source). Будь-який компонент можна замінити іншим вирішенням, яке, можливо, є в клієнта. Для реалізації шаблону ми використовували перевірені open-source вирішення, щоб мінімізувати первісну вартість проекту. Оскільки нашою метою є будь-яка хмарна платформа, то для контейнерування ми вибираємо docker, а для оркестрування контейнерів kubernetesяк лідерів у своїй сфері.

Розгортання й запуск

Без можливості запуску представлена вище схема залишається лише схемою. Тому публікуємо демонстраційни коддля розгортання інфраструктури й деякої кількості компонентів. На цей час опубліковано конфігурації з підтримуванням Amazon Web Services (AWS). Проте з мінімальними змінами таку саму або схожу інфраструктуру ви зможете підняти в іншій хмарі.

Infrastructure as a Code — це основний підхід для справді швидкого впровадження проекту й розвитку сервісно-орієнтованої чи мікросервісної архітектур. На цей час ми обрали Terraform.

Terraform — уможливлює представити хмарну інфраструктуру як мінімалістський код з підтримуванням основних хмарних провайдерів. Це дає змогу розгортати потрібну інфраструктуру з мінімальними витратами в будь-яких хмарах, зокрема й приватних (on-premises), що ґрунтуються, наприклад, на OpenStack.

Самоконфігуровані docker-контейнери. Ідея полягає в тому, що базовий контейнер містить усе, крім останнього шару з конфігураціями й артефактами розробки. Отож цей контейнер можна опублікувати й в загальнодоступному dockerhub-репозиторії, оскільки він не містить приватної інформації. Останній шар з артефактами контейнер забирає сам з під’єднаного диска (volume) під час запуску. Це дає економію на розгортанні docker-сховища й під час розробки на збиранні docker-контейнерів. Звісно, ближче до розгортання рішення у продакшені з’явиться приватний репозиторій, але починати розробку можна й без нього.

Що дає ця платформа

Не руйнуючи поточних систем і процесів, ми наповнюємо інфраструктуру потрібними компонентами для забезпечення сервісної архітектури, інтегрування даних та автоматизування бізнес-процесів з мінімальними інвестиціями для впровадження й розвитку нової інфраструктури, а також володіння нею.

Як же бути з наведеним вище для прикладу NFS-протоколом? Адже такі ситуації обов’язково виникнуть, якщо ми не вносимо змін до поточної інфраструктури клієнта.

Підприємства не хочуть уносити великих змін до інфраструктури. Часто це пов’язано з великими витратами або теоретичними втратами. Здається, найкраща стратегія тут — Least effort & Maximum effect. Спочатку інтеграційну платформу можна позиціювати як надбудову над поточною архітектурою — фасад, який приховує реальні системи й протоколи всередині підприємства. Як тільки ми під’єднуємо до фасаду нові системи, можемо моніторити швидкість роботи й навантаження на сервіси, а потім оцінювати вартість і планувати внесення змін до конкретних сервісів та, можливо, інфраструктури підприємства.

Скільки коштує сама платформа

Ми принципово використовуємо продукти з відкритим кодом з ліцензією Apache 2.0 або схожою на неї. Саме це дає змогу запустити проект із мінімальними витратами. По суті, клієнт платить тільки за хостинг потрібних компонентів у хмарі.

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

Як оцінити обсяг робіт щодо впровадження сервісної архітектури

Обсяг робіт на великих підприємствах може виявитися неосяжним, повне збирання вимог буде довгим, а результат проведеного аналізу неточним. Крім того, під час проведення повного аналізу інфраструктура в замовника може змінюватися.

Однак конкретні deliverables можна оцінити. Наприклад:

• Первинний аналіз поточної архітектури й дизайн нової: десять-п’ятнадцять днів. Охоплює схему й компоненти високорівневої архітектури, мета — унесення змін до архітектури та кількох проміжних варіантів.
• Складання базових правил для розвитку інтеграційної архітектури: п’ять-десять днів.
• Розгортання платформи для інтеграції сервісів. За наявності хмарної передплати й узгодженої конфігурації розгортання забирає кілька годин. Імовірні доробляння, конфігурація, налаштування VPN... — це окремо.
• Під’єднання кожної нової системи: від двох до п’ятнадцяти днів. П’ятнадцять днів — якщо щось нестандартне, для чого немає конекторів.
• Публікування проксі-сервісу: від одного до трьох днів. Охоплює API-дизайн і мінімум інтеграційної логіки. У разі усталеного процесу — найчастіше один день і менше.
• Імплементування комплексного сервісу: від трьох до п’яти днів. Працюють із кількома джерелами даних.
• Імплементування нового сервісу: від трьох до п’яти днів. Сюди потрапляють сервіси, для яких ще не існує бек-енд системи, але є всі ресурси для імплементування.
• Розробка процесного сервісу (бізнесового процесу): Десять днів — тридцять кроків процесу.
• Розробка CI/CD-процедур для кожного виду сервісу: від трьох до п’яти днів.

Усі зазначені оцінки можуть мати безліч залежностей і їх наведено для прикладу. Але ми впроваджуємо не просто технологію, а й процес/культуру її розвитку, тож оцінки із часом стають точнішими.

Скільки сервісів потрібно реалізувати

Як вибрати правильну грануляцію сервісу? Які вхідні й вихідні параметри мають бути в сервісі? Створювати два методи create + update або один register? Наскільки «мікро» мають бути сервіси?..

80% успіху розробки сервісу залежить саме від правильного API. Успіх я б вимірював тривалістю існування API без унесення змін.

Усі сервіси має бути написано так, щоб їх було зручно викликати клієнтській стороні. Уявіть, що ви віддаєте в руки користувачеві API, а не призначений для користувача інтерфейс, — це змусить вас думати не тільки про зручність використання, а й про безпеку сервісів. Кількість сервісів я б співвідносив з кількістю понять, якими орудує клієнт. Наприклад, якщо це клієнт банку, то сервісами будуть: кредити, депозити, картки, рахунки, валюти, курси тощо. У межах конкретного завдання кількість сервісів буде остаточною, навіть якщо з’явиться кілька додаткових.

Чого не варто робити в сервісах

Найбільше зло — транзакційність. Не поєднуйте все в одну велику транзакцію.

Наведу приклад. Сьогодні широко поширена операція миттєвого переказу з картки на картку між різними банками. Ця операція складається з трьох основних: негативне блокування коштів на картковому рахункові відправника, позитивне блокування коштів на картковому рахункові одержувача й банківський переказ. Миттєвості переказу досягнуто завдяки коротким першій і другій операціям, які виконуються, поки ви перебуваєте в браузері або мобільному застосунку, а остання операція відбувається за якийсь час протягом кількох днів. Якщо остання операція з якихось причин не пройшла, то гроші на картку відправника повертаються в результаті ще тривалішого процесу. У цьому разі цілковитою транзакційністю процесу переказу пожертвували заради швидкості операції.

Найчастіше «вузьким місцем» є back-end системи підприємства, проте не слід одразу пропонувати збільшувати їхню потужність, адже завдання можна розв’язати на рівні middleware за допомогою систем автоматизування процесів (Business Process Server) або черг повідомлень.

З чого починати, коли підприємство перебуває в процесі змін

Це типова ситуація. Без змін у бізнесі змінювати архітектуру ніхто не буде. Отже, маємо безліч невідомих: обсяги робіт, системи й спосіб взаємодії з ними (особливо з тими, які написано десятки років тому), архітектура/інфраструктура в клієнта перебувають у перехідному стані в межах свого життєвого циклу...

Потрібна точка опори. Опиратися на системи недоцільно. Навіть «прибиті цвяхами» до бізнесу системи раптово стають застарілими. У моїй практиці був проект упровадження сервісної архітектури й автоматизування бізнес-процесів (чотири роки), у межах якого основну бізнесову систему (core system) було замінено двічі.

Ідея в тому, що найстабільнішою частиною є декларування бізнес API й різних правил і політик його розвитку. Тому починаємо з визначення:

• Основний протокол для взаємодії з усіма системами в межах бізнесових функцій. Сьогодні найчастіше вибирають JSON + HTTPS (XML, SOAP та ін.).
• Формат опису/документування сервісів (Swagger/OpenAPI (RAML, WSDL ін.)).
• Мови програмування й технології, які прийнятні для клієнта в межах інтегрування. Імовірно, клієнт має свою команду для розвитку й супроводження ІТ-систем, яка впливає на рішення.
• Стандарти безпеки. Захищені протоколи передавання даних TLS (SSL) і протоколи автентифікування/авторизування.
• Правила публікування й виклику сервісів: правила йменування, версіювання, виклику, валідування, виведення з експлуатації тощо.

Маючи базис, можна починати з імплементування перших сервісів або навіть процесів. Починаємо з малого — думаємо про велике.

Що ми одержимо в ідеальних умовах

API Manager виступає централізованою точкою для документування, створення нових сервісів і гарантування їхньої безпеки. Створення прототипу нового сервісу може зініціювати й бізнесовий аналітик, маючи під рукою браузер. Оскільки всі бізнесові функції представлено сервісами, створення бізнесового процесу за допомогою Business Process Server стає питанням конфігурації, яку також може виконати бізнесовий аналітик. Усі процеси, як і сервіси, описано, завтоматизовано й легко змінити. За допомогою систем моніторингу просто знаходити проблемні сервіси й планувати зміни.

Підсумки

Навіщо це все? Адже якщо взяти, наприклад, API Manager, то практично у всіх хмарних провайдерів є свій сервіс: Apigee API Platform from Google, Azure API Management from Microsoft та API Gateway from Amazon. На жаль, цей сервіс не має загальних стандартів розробки й конфігурації. А якщо потрібно зробити Cloud-agnostic-рішення або розгорнути в приватному клауді чи на локальних серверах, то варіант, про який ішлося вище, конкурентний.

Представлений архітектурний шаблон уже використовують на багатьох підприємствах. Ми постійно стежимо за новинками у сфері інтегрування систем та оновлюємо список компонентів.