Розвиток веб-архітектур (шлях до SOA)

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Я собираю информацию по развитию веб-проектов и эволюции веб-архитектур.

В часности, о переходе централизованных LAMP-решений на SOA.

Благодарю всем кто прочитает эту статью и добавит свой отзыв, особенно интересуют отзывы (как программистов, системных архитекторов, так и руководителей проектов) о мотивах и причинах, которые привели к эволюционному (или революционному) изменению архитектуры веб-проектов, смене языков разработки веб-приложений (например с php на java).

---
UPDATE: нашел в 2016 году этот топик... :))))

---
UPDATE: оновлення 2026 року. 18 років запису, це був 32 запис форуму на сайті. За це час багато чого змінилися в IT, еволюціонували архітектури, був сплеск мікросервісів, зараз набуваж популярності оркестрація ШІ-агентів.
Добре що ДОУ досі існує і містить чимало корисних публікацій і коментарів.

Ретроспектива: 18 років, від LAMP-моноліту до оркестрації ШІ-агентів (2008 → 2026)

Коли я писав цей топік у 2008 році, головне питання звучало приблизно так: «як розтягнути Drupal/WordPress/Magento на кілька серверів, не зламавши те, що вже працює». SOA тоді була новою модною парадигмою, ESB виглядали серйозно, а слово «хмара» ще писали в лапках. Цікаво подивитися, як цей шлях виглядає з 2026 року — і які з тодішніх відповідей виявилися правильними, а які стали «архітектурним смітником».

Куди реально пішла галузь

2008–2011. LAMP і перші розриви моноліту.
Проєкти на PHP/MySQL виходили з-під контролю на десятках тисяч користувачів. Стандартна реакція тих часів: винести кеш (memcached), розділити читання/запис (replication), додати reverse proxy (Varnish, потім Nginx перед Apache). SOA на практиці зводилася до SOAP-сервісів, ESB і «інтеграційного шлюзу», який у 80 % випадків ставав новим монолітом — просто на XML.

2011–2015. REST переміг SOAP, з’явився «веб 2.0 для машин».
JSON+REST витіснили SOAP майже скрізь, окрім банків і телекому. Фронтенд відокремився від бекенду — спершу через jQuery+AJAX, потім через AngularJS і React. Розробники раптом помітили, що архітектура клієнта — це теж архітектура. Почали окремо обговорювати SPA, BFF (Backend-For-Frontend), API gateway.

2015–2019. Контейнери і мікросервіси.
Docker (2013), потім Kubernetes (2014–2015) перевернули спосіб упаковки і доставки сервісів. SOA «перевідкрили» під ім’ям мікросервісів — але вже не з ESB, а з API gateway, service discovery, circuit breaker, distributed tracing. Netflix-стек (Eureka, Ribbon, Hystrix) став фактично навчальним посібником.

Паралельно прийшов DevOps як обов’язкова частина архітектури: pipeline, IaC (Terraform, Ansible), GitOps. Архітектор без знань CI/CD у 2018 — це вже був дивний персонаж.

2019–2022. Event-driven і «архітектура без серверів».
Kafka стала базою для подієво-орієнтованих систем. CQRS, Event Sourcing, DDD перестали бути академічними і потрапили у виробничі обговорення (див. сусідні теми форуму). Serverless (AWS Lambda, Azure Functions) розвантажив команди від інфраструктури там, де навантаження нерегулярне.

2022–2024. Service mesh, platform engineering, «розпухання мікросервісів».
Багато компаній зрозуміли, що 200 мікросервісів — це не архітектура, а проблема. З’явилися терміни modular monolith і majestic monolith — повернення до моноліту, але вже з модулями, чіткими контрактами і вибором, що саме виносити в окремий сервіс. Service mesh (Istio, Linkerd) дозволили винести крос-функціональні турботи (mTLS, retry, traffic split) з коду в інфраструктуру. Platform engineering оформилося як окрема дисципліна: внутрішні платформи розробки, портали (Backstage), self-service.

2024–2026. ШІ як перший клас архітектури.
Раптом виявилося, що великі мовні моделі — це не «ще один API». Це повноцінний компонент, який треба архітектурно вписувати: RAG (генерація з пошуковим підкріпленням), AI gateway, контроль контексту, evaluation pipelines, governance моделей. У 2025–2026 у промислових системах нормальним стало мати:
— векторні бази даних поряд із реляційними і графовими;
— окремий «охоронець контексту» між пошуком і моделлю;
— explicit knowledge graphs для трасування і пояснюваності;
— оркестрацію ШІ-агентів як окремий шар (часто на Temporal, NATS JetStream або власних координаторах);
evaluation і replay infrastructure для відтворюваності рішень моделі.

Що з обговорень 2008 року виявилося правдою
«Моноліт треба розрізати по швах бізнес-доменів, а не по таблицях БД» — банальність 2008-го стала Domain-Driven Design в 2015 і фундаментом мікросервісів в 2019.
«Інтеграційна шина — це теж моноліт» — підтвердилося. ESB майже зник, на його місці асинхронні брокери (Kafka, NATS) і API gateway.
«PHP не помре, але великі системи писатимуть на іншому» — Java, Go, Node.js, потім Rust і Kotlin зайняли свої ніші. PHP залишився, але для веб-публікацій і e-commerce.

Що виявилося хибним або наївним
«Достатньо розпиляти моноліт на сервіси — і буде масштабованість». Виявилось, що без observability, контрактного тестування і дисципліни деплою це лише розподілений моноліт із додатковою мережею між помилками.
«SOA вирішить інтеграцію через ESB». Ні. ESB перетворилися на bottleneck, і галузь пішла у бік decentralized integration: API + events + schema registry.
«Хмара зробить інфраструктуру дешевшою». Часто — зробила дорожчою, але швидшою. Економіку треба свідомо проєктувати (FinOps), інакше cloud bill з’їдає економію від швидкості.
«Чим більше мікросервісів, тим краще». Приблизно з 2020-го галузь почала повертатися до модульного моноліту як свідомого вибору.

Що з 2008-го досі залишається відкритим
Узгодженість даних у розподілених системах. Saga, outbox pattern, eventual consistency — інструменти з’явилися, але кожен новий проєкт усе одно проходить це болюче місце наново.

Контракти між сервісами. OpenAPI, gRPC, AsyncAPI допомогли, але дисципліна команд по-справжньому не масштабується інструментами.

Документація як артефакт першого класу. Дзеркало 2008 і 2026: усі знають, що треба, мало хто робить. ШІ-асистенти трохи покращили ситуацію, але не зняли проблему.

Що я як архітектор узяв би з цього шляху сьогодні
Починайте з модульного моноліту, виносьте у сервіс лише те, що має іншу логіку масштабування, життєвого циклу або команду власника.
Контракт важливіший за технологію. JSON чи Protobuf, REST чи gRPC, Kafka чи NATS — це другорядно поряд із чітким, версіонованим контрактом.

Observability — частина архітектури, а не операційний додаток. Якщо tracing, logs і metrics не закладені в день перший, потім ви платите подвійно.

ШІ-компоненти — це окрема архітектурна дисципліна. Їх не можна вписувати «ще одним мікросервісом». Потрібні правила: версіонування промптів, пошуковий контекст, evaluation, governance, відтворюваність.

Доказовість важливіша за красивий інтерфейс. У регульованих доменах (auto, med, fin) система має не просто відповісти, а показати, чому вона так відповіла — з джерелами, версіями, припущеннями і слідом міркування. Це ниточка, яка тягнеться від експертних систем 80-х і досі актуальна, навіть в епоху LLM.

Замість підсумку
Якщо у 2008-му питання звучало «як розрізати моноліт на сервіси», у 2026-му воно вже формулюється інакше: як зібрати з людей, сервісів, моделей і знань систему, рішенням якої можна довіряти і яку можна аудитувати. Архітектура перестала бути «діаграмою компонентів» і стала питанням довіри: до даних, до коду, до моделей і до процесів.

Гарно, що ДОУ досі живий і що цей маленький топік 2008 року тепер — точка ретроспективи. 18 років — це достатньо, щоб мода на технології встигла обернутися кілька разів. Але інженерна дисципліна, як виявилося, мало змінилася: ті самі питання про контракти, межі, відповідальність і докази.

— Микола Федчик, оновлення 2026 року