Називати статтю «Еволюція прикладних інформаційних систем і перспективи розвитку їх архітектури» було б занадто академічно, адже тут буде дуже короткий витискання з реального практичного досвіду, можливі варіанти розвитку технологій, що викликали їх потреби і шляхи вирішення. Я сподіваюся, що стаття допоможе узагальнити і переосмислити широке коло завдань, пов'язаних з прикладними ІС, і відразу хочу уточнити, що розумію під цими термінами. ІС - це системи, що забезпечують обробку, передачу і зберігання даних. Це далеко не все програмування, але зараз ІС найчастіше асоціюються з веб і мобільними додатками, хоча і не збігаються з ними повністю, знак рівності між UI і ІС не можна ставити тим більше. Дуже прошу всіх подивитися на питання якомога ширше і приєднуватися до обговорення в коментарях. І ще, я навмисно не буду використовувати назви фреймворків і технологій, щоб уникнути зайвих холіварів, обмежившись загальноприйнятими назвами архітектур, стандартів і протоколів, що і вам рекомендую в коментарях.
Розгалуження в технологіях траплялися багато разів в історії, але за періодом невизначеності завжди слідує етап сталого розвитку, коли несуттєві гілки йдуть у тінь, а актуальні особливості об'єднуються в самий життєздатний гібрид. Для початку ми коротко простежимо, як ІС розвивалися з самої їх появи. Щоб спогади нахлинули, нам вистачить всього 9 рядків і картинки.
Я не вказував часу існування для архітектур, тому, що і зараз у своїх нішах паралельно існують майже всі з перерахованих рішень. Для сучасних ІС переважаюча технологія все ще # 5, тобто звичайні веб сторінки з перезавантаженням за посиланнями (тонкий клієнт) і всією логікою на сервері. Для багатьох завдань більшого і не потрібно. На передньому краю # 8, тут веб-додатки і мобільні додатки злилися архітектурно, хоч і мають безлічі відмінностей у технологіях і реалізації. Що ж далі? Тенденції вже намітилися: сервер це API, бази даних на клієнті, рендеринг на клієнті, багатий GUI, робота в офлайні, високі навантаження і багато користувачів. Але технологічно ці потреби задовольняються настільки різними платформами, що відбулося розгалуження. Це в рівній мірі актуально і для веба і для мобільних додатків. Потрібно сказати, що для десктопних додатків ситуація теж збігається, з деякими застереженнями, але вони зараз не в тренді і ми будемо мати на увазі, що наступні 4 варіанти розвитку можуть бути застосовані до прикладних ІС взагалі.
Обслуговування високих навантажень хмарою (# A Cloud Highload)
Переваги: Хмари прекрасно справляються з масштабуванням, використовуючи принцип REST, додатки можуть обслуговувати десятки мільйонів абонентів, якщо відмовляються від стану, тобто серверні процеси не зберігають стану в пам'яті, всі мережеві виклики незалежні і не переводять сесію ні в який стан.
Недоліки: У реальних додатках часто відходять від REST саме тому, що для вирішення завдання потрібен стан. Виходить псевдо-REST, не масштабований, але з купою обмежень. А головне, абсолютно не підходить для програм, що інтерактивно взаємодіють з користувачем або забезпечують взаємодію між користувачами.
Вивід: У багатьох випадках це оптимальне рішення: публікація контенту, інформаційні ресурси, ЗМІ, можуть бути ефективно побудовані в хмарі, але для складних додатків з базами даних та інтерактивністю, це крок назад від архітектури # 8.
Сервер програм (# B Application servers)
Переваги: Місце веб-сервера займає сервер програм, тобто не програма запускається під керуванням веб-сервера, а веб-сервер вбудовується в програму або сервер програм. До того ж для підвищення ефективності HTTP/HTTPS можна замінити спеціалізованими протоколами на базі TCP/TLS. Особливо це актуально для мобільних і десктопних додатків, що дає можливість будувати RPC, шину подій, синхронізацію БД.
Недоліки: Такі додатки поки не мають універсальних хмарних рішень, але все йде до того, що вони скоро з'являться. А до цього, потрібно винаходити свій стек технологій і самим будувати приватну хмару. Це складно підтримувати і обслуговувати. Крім того, синхронізація БД на сервері і клієнті робиться вручну, через додаток, зазвичай надзусиллями розробників, а використовувати такі рішення повторно зазвичай не вдається.
Вивід: Цей напрямок зараз доступний тільки великим компаніям, що мають потребу в обслуговуванні мільйонів користувачів, створенні інтерактивних додатків або R&D лабораторіям, які готують подібні рішення для масового користувача.
БД-центричний підхід (# C Database-centric)
Переваги: Дуже привабливо поставити БД вперед програми і налаштувати синхронізацію (часткову реплікацію) між базами даних. Таким чином, ми маємо СУБД вбудовувані в програми і працюємо не з сервером, а з локальною БД. Для цього вже придумано безліч методів: optimistic replication, operational transformation, conflict-free replicated data type, адже СУБД існують вже досить давно і навчилися масштабуватися.
Недоліки: Спілкування між додатками тільки через дані явно обмежує наші можливості. Це редукція всього до роботи з базою. А як же передача подій, інтеграція на рівні API, виклик віддалених процедур? Про все це потрібно забути при БД-центричному підході.
Вивід: Для певного класу завдань це шикарне рішення, а разом з інтроспекцією і скаффолдингом UI така архітектура автоматично «» розкатає «» в дуже широкій сфері застосування більш складних конкурентів, що інтегруються за допомогою API і вимагають весь час писати взаємодію програмно.
Однорангова або пірінгова взаємодія (# D Peer-to-Peer)
Переваги: Це розвантажить сервери, які будуть виконувати тільки функцію зв'язування/брокера. Локальна взаємодія між користувачами часто більш ефективна, ніж через віддалений сервер, особливо при великих потоках даних. Дає надію на анонімність обміну приватними даними.
Недоліки: Питання «» довіри «» в пірінгових мережах все ще повністю не подолаємо. Будувати розподілені ІС тільки на P2P не вдасться, сервери все одно будуть у цій схемі. Поки немає поширених протоколів, бібліотек, фреймворків та інших програмних засобів для реалізації в обсязі, необхідному для побудови прикладних ІС.
Вивід: Елементи однорангових мереж будуть вбудовуватися в централізовані ІС.
Узагальнення тенденцій
Який гібрид вийде в результаті злиття цих напрямків, поки не ясно, але вже можна побудувати кілька припущень і, як мінімум, виділити тенденції.
Вже очевидно, що гілка архітектур на цьому етапі буде відбуватися, в першу чергу, за рахунок вбудовування системних компонентів в сам додаток:
- Вбудовані в програму комунікаційного сервера: HTTP/WS, HTTPS/WSS, TCP/TLS и т.д.
- Вбудовані в програму СУБД з автоматичною синхронізацією.
- За аналогією можна згадати і про ще одну функцію ІС, це обробка даних або обчислення. Отже, вбудовані в програми систем розподілених обчислень рано чи пізно теж станеться. Адже пристрої користувача в наш час мають велику обчислювальну потужність і не використовувати їх для розподіленої обробки даних, це недозволене архітектурне упущення.
Особисто я хочу об'єднати Data-centric архітектуру (яка, за принципом Парето, накриє 80% потреб повною автоматизацією) з сервером додатків (який дасть можливість зробити інтеграцію на рівні API або шини подій для решти 20% випадків). Для цього протокол взаємодії ІС повинен підтримувати одночасно 5 типів взаємодії: RPC, REST, Event BUS, DB Sync, Binary streaming. Над таким комплексним рішенням і працює зараз наша команда.
Крім чотирьох великих архітектур можна будувати гібриди з комбінації окремих можливостей:
- Synchronization - синхронізація структур даних між додатками в розподілених системах в режимі часу, наближеному до реального;
- Offline - можливість працювати з частиною даних, збережених у локальному сховищі в браузері або мобільному додатку, а при виході в онлайн синхронізувати;
- Interactivity - можливість двостороннього обміну подіями з сервером і побудова реактивних компонентів: UI, курсорів баз даних, логіки додатку, обміну по мережі тощо;
- Low latency (або High availability) - характеристика готовності обробки запитів і оптимізація часу відгуку сервера (не плутати з пропускною здатністю);
- Highload - обробка інтенсивного потоку запитів (request per second), що включає їх частоту, розмір, пріоритет, час очікування в черзі, час життя і ресурси для обслуговування;
- High connectivity - велика кількість конкурентних (одночасних і довгоживучих) з'єднань клієнтів до сервера з можливістю двостороннього обміну даними за ініціативою будь-якої зі сторін;
- High interconnection - характеристика інтенсивності взаємодії між конкурентними з'єднаннями, а також розмір взаємодіючих груп з'єднань;
- Scalability - група характеристик горизонтального і вертикального масштабування, що забезпечують прозорість масштабування для програмних і апаратних засобів (без переписування коду);
- Big data - можливість обробляти великі обсяги даних, наприклад потокова обробка даних або побудова запитів до розподілених сховищ;
- Big memory і in-memory DB - висока утилізація обсягів пам'яті або перенесення баз даних повністю в оперативну пам'ять з додатковими індексами для швидкого виконання запитів;
- Integration flexibility - характеристика гнучкості і простоти інтеграції рішень, на базі інтроспекції, автоматичного зв'язування інтерфейсів, скаффолдингу і динамічної інтерпретації метамоделей.
Для того, щоб ми всі розуміли тенденції, пропоную відповісти на питання, а так само, буду вдячний за конструктивну критику і коментарі.
Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.
Які сценарії еволюції ІС найбільш перспективні?
21.57% Старий веб 11
3.92% Просте масштабування у хмарі пасивних програм без інтерактивності 2
23.53% Серверу додатків у приватних хмарах для великих проектів і компаній 12
31.37% Новий тип хмар, що підтримують інтерактивну двосторонню взаємодію 16
33.33% Інтерактивні сервери додатків стануть доступні для дрібних проектів 17
15.69% БД-центричний підхід стане доступний дрібним проектам 8
33.33% Новий тип хмар з БД-центричними додатками як сервіс 17
37.25% Прикладні ІС будуть реалізовані за принципом однорангової P2P взаємодії 19
Проголосував 51 користувач. Утрималися 78 користувачів.
Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.
Які можливості технологічного стіка найбільш затребувані?
56.76% Синхронізація даних 42
48.65% Робота в офлайні 36
43.24% Інтерактивність 32
32.43% Низька латентність і готовність 24
40.54% Високі навантаження 30
21.62% Велика кількість сполук 16
17.57% Велика інтенсивність взаємодії з'єднань 13
54.05% Легка масштабованість 40
32.43% Великі обсяги даних 24
14.86% Big memory и in-memory DB 11
52.7% Простота інтеграції рішень 39
Проголосували 74 користувачі. Утрималися 62 користувачі.
Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.
Ваше особисте ставлення до появи нових архітектур і технологій?
25.29% Все влаштовує, нове не цікавить 22
58.62% Чекаю з нетерпінням всього нового і пробую 51
16.09% Беру участь в OpenSource проектах, роблю внесок у майбутнє 14
Проголосували 87 користувачів. Утрималися 56 користувачів.
