Эволюция микро-сервисов
От: Ватакуси Россия  
Дата: 21.08.21 08:19
Оценка: 3 (1) :)
Относительно недавно столнулся со следующим "логическим" этапом этих микро-сервисов: микро-веб-приложения.

У вас есть сайт (пускай на ангуляре или реакте), который дробится на десятки, если не сотни микро-приложений. Каждое из них:
1) Живёт в своём хранилище
2) Как правило принадлежит одному отделу
3) Тащит своих стили, свои базовые классы, функции и т.п.
4) Имеет свою собственную службу (для общения с базами и возможно другими службами), которая тоже живёт в своём хранилище
5) Имеет свой собственнй CI/CD (как и служба из 4))
6) Имеет свои собственные тесты и возможно интеграционные тесты и даже нагрузочные (конечно же в своих хранилищах)
7) Встраивается в родительское приложение динамически (или через пару строк конфигурации), но без него жить не может — т.е. для запуска и отладки нужно заводить целый авто-парк (у меня до 7 разных может крутиться одновременно)

Что это даёт из +:
1) Можно менять, заливать и отлаживать не завися от других (ну, не 100%, но сильно меньше зависеть)
2) Относительно легко понимать как устроено и работает
3) Меняя стили и поведение, ты никому ничего не поломаешь

Из — (по закону диалектики, это почти всегда обратная сторона +):
1) Сильно больше возни с созданием, управлением
2) Нельзя запустить без родительских приложений (или это особо ничего не даст)
3) Идёт разброд и шатание по стилям, стандартам и поведению.
4) Любое глобальное изменение нужно применять сразу в десятках, если не сотнях микро-проектов.
5) Версии сторонних библиотек могут входить (и зачастую входят) в противоречие друг с другом.

Забыл сказать — какую глобальную задачу такая архитектура решает — чтобы можно было заливать свой код и не мешать другим (не зависеть от других). В связи с этим вопрос — наверняка это можно решать как-то иначе?
Что вообще думаете?
Коо иу-то дзиман-о суру ё-ни наримас га...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.