Эволюция микро-сервисов
От: Ватакуси Россия  
Дата: 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) Версии сторонних библиотек могут входить (и зачастую входят) в противоречие друг с другом.

Забыл сказать — какую глобальную задачу такая архитектура решает — чтобы можно было заливать свой код и не мешать другим (не зависеть от других). В связи с этим вопрос — наверняка это можно решать как-то иначе?
Что вообще думаете?
Коо иу-то дзиман-о суру ё-ни наримас га...
Re: Эволюция микро-сервисов
От: vsb Казахстан  
Дата: 21.08.21 08:57
Оценка:
Здравствуйте, Ватакуси, Вы писали:

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

В>Что вообще думаете?

Ну мне кажется, что решать иначе — так же, как и монолит вместо микросервисов. Просто писать код дисциплинированно и модульно, чтобы каждый модуль был изолирован и не мешал другим. Микросервисы эту задачу решают на инфраструктурном уровне — чтобы помешать другому микросервису, который крутится в другом контейнере — это постараться надо. В целом, думаю, это правильный подход. Если брать ту же Java, просто нет инструментов, которые бы позволили в рамках одной JVM нормально изолировать разные модули, скажем, запретив одному модулю жрать больше 10 MB памяти или 5% процессора. А для приложений ОС, контейнеров, виртуальных и тем более физических машин и тд такие инструменты есть. И это Java — самая передовая VM, у остальных ничего подобного тем более нет.
Re: Эволюция микро-сервисов
От: Kolesiki  
Дата: 21.08.21 09:42
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Относительно недавно столнулся со следующим "логическим" этапом этих микро-сервисов: микро-веб-приложения.


В>У вас есть сайт (пускай на ангуляре или реакте), который дробится на десятки, если не сотни микро-приложений. Каждое из них:

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

Походу, у кого-то сильное недопонимание приставки "микро".
Re: Эволюция микро-сервисов
От: sambl74 Россия  
Дата: 21.08.21 10:35
Оценка:
В>Из — (по закону диалектики, это почти всегда обратная сторона +):
В>1) Сильно больше возни с созданием, управлением

Ну докер компоуз запустил, он тебе всё поднял. Спокойно отлаживаешь.

В>2) Нельзя запустить без родительских приложений (или это особо ничего не даст)


А надо ли?

В>3) Идёт разброд и шатание по стилям, стандартам и поведению.


Ну нет, дизайн то общий же обычно. Плюс свой набор компонент может идти.

В>4) Любое глобальное изменение нужно применять сразу в десятках, если не сотнях микро-проектов.


Ну например? Больше похоже на плохой дизайн и нарушение DRY принципа.

В>5) Версии сторонних библиотек могут входить (и зачастую входят) в противоречие друг с другом.


Дык микрофронтенды же независимы. Они общаются только через API.

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


С ростом размера команд, и особенно и их количества, это показалось разумным выходом.

В>Что вообще думаете?


Такой вот теперь веб...
Re[2]: Эволюция микро-сервисов
От: AeroSun  
Дата: 21.08.21 16:27
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Походу, у кого-то сильное недопонимание приставки "микро".


Точно) Когда хотели микро, а получилась фрактальная инфраструктура
Re: Эволюция микро-сервисов
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 21.08.21 17:30
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Что вообще думаете?


Как пользователю мне бы хотелось готовое решение. Чтобы оно сразу было из коробки. Чтобы обо всех согласованиях заботились разработчики. Когда начинают бить приложения на плагины или другие части, например, микросервисы, это значит кому-то потом придётся с этим возиться.

Теперь насчёт работы по сети. Банальный вызов функции всегда быстрее. Если можешь вызвать функцию напрямую, то нет смысла её запаковывать и передавать вызов по сети, тоже самое касается передачи данных. Микросервисы так понимаю нужны для развёртывания в облачных сервисах.

Причём очевидно, что независимый разработчик и владелец облака это не одна и та же организация. То есть вся эта замута с микросервисами нужна владельцам облаков для распределения обработки данных. Следовательно для такой системы нужна команда поддержки, которая будет работать даже не над общим коробочным решением, а просто чтобы всё это запускалось и как-то отрабатывалось в каждом конкретном случае.

Я здесь не вижу способов как это могло бы упростить жизнь разработчиков или как-то им помочь. Никак это им не поможет. Классы вот тоже в теории должны были быть независимыми и всё такое, а что в итоге. Теория о том, что пока не меняется интерфейс всё будет в порядке не работает, потому что в реале интерфейс таки меняется.

Так и в чём вопрос:

Забыл сказать — какую глобальную задачу такая архитектура решает — чтобы можно было заливать свой код и не мешать другим (не зависеть от других).

Представим, что разработчики пишут говномикросервисы. Что дальше? Есть только один способ не зависеть от других, это написать всё самому. Иначе придётся общаться с этими людьми. А не хочешь общаться, тогда потребляй то, что они производят.
Re: Эволюция микро-сервисов
От: Тёмчик Австралия жж
Дата: 22.08.21 03:55
Оценка: +1
Здравствуйте, Ватакуси, Вы писали:

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

В>Что вообще думаете?

Думаю, что разрезать большой монолит на пачку микро-фронтендов полезно для разруливания блокировок и конфликтов мёржей, когда много людей одновременно в проект коммитят, и одна громадная батарея тестов на всё сразу крутится на изменение в любом модуле. И далее, отвязаться от одного фреймворка одной версии, чтоб потом не оказалось мучительно больно переписывать всё сразу, вместо один микрофронтэнд at a time.
LIVE camera in Dee Why: http://www.coastalwatch.com/surf-cams-surf-reports/nsw/dee-why
Re: Эволюция микро-сервисов
От: Буравчик Россия  
Дата: 22.08.21 05:24
Оценка: 1 (1)
Здравствуйте, Ватакуси, Вы писали:

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


Да, деплоить приложение по частям можно и без микросервисов — разбить монолит на модули-пакеты и деплоить их независимо друг от друга.
Под пакетом подразумевается сущность с поддержкой версионирования (java-пакеты, python-пакеты, so/dll-библиотека и т.п.)
Best regards, Буравчик
Re: Эволюция микро-сервисов
От: Shmj Ниоткуда  
Дата: 22.08.21 07:24
Оценка: +1 -1
Здравствуйте, Ватакуси, Вы писали:

В>Что вообще думаете?


Я думаю что IT трансформируют в соответствии с принципами глобального управления. Когда появляется новая область, где требуются сложные умения/знания и где одиночки могут на что-то влиять — хозяевам мира это не нравится, им нужно сохранить власть. И есть отработанные принципы как управлять тем, в чем не разбираешься (ведь разбираться во всем не возможно).

Главный принцип — разделяй и властвуй. Т.е. сделать так, чтобы никто не понимал и не видел целой картины. Чтобы чел. был всего лишь винтиком в системе — понимал только фронт, к примеру, а остальное не понимал. Т.е. чтобы сам по себе не мог выдать завершенный продукт.

И чем выше степень разделения — тем прочнее твоя власть, тем больше без тебя эти умники ни на что не способны, только на помоечку.
Re: Эволюция микро-сервисов
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.08.21 08:23
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Забыл сказать — какую глобальную задачу такая архитектура решает — чтобы можно было заливать свой код и не мешать другим (не зависеть от других).

Самое главное что в каждом микросервисе можно делать свою СУБД, использовать свои ЯП и серверы.

В>В связи с этим вопрос — наверняка это можно решать как-то иначе?

Можно конечно, ключевые слова: модульность, дисциплина, автотесты.

Модульность помогает писать независимо, не вызывая отказов в в одних частях при правках в других.
Модульность крайне сложна если у вас есть общие ресурсы, типа БД или UI. Но все-таки возможна.

Дисциплина нужна чтобы не нарушать модульную архитектуру и не создавать лишние связи. В отличие от микросервисов, где можно на уровне прав на отдельные репозитарии запретить вносить изменения, в одном "монолитном" приложении потенциально любой программист может поправить то, что ему править не надо.

Автотесты нужны чтобы проверять что все работает. Желательно не юнит-тесты, а e2e тесты, которые проверяют работоспособность на реальных данных.

В>Что вообще думаете?

Думаю что начинать с микросервисов это максимально плохая идея. Выделять части вашего кода в отдельные микросервисы стоит только тогда, когда по другому невозможно или слишком дорого.
Re[2]: Эволюция микро-сервисов
От: smeeld  
Дата: 22.08.21 11:24
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Думаю что начинать с микросервисов это максимально плохая идея. Выделять части вашего кода в отдельные микросервисы стоит только тогда, когда по другому невозможно или слишком дорого.


Ща набигут и скажут, что старпёр, и не понимаешь новых и невпендюренных прорывных технологий. Это когда на каждый чих создаётся свой сервис, ибо такое на хабрах и медиумах модно-молодёжные инфоцигане всякие втирают. С проблемами такого подхода его адепты не сталкивается, ибо пишут только мелкие хеллоуворлды.
Re[2]: Эволюция микро-сервисов
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.08.21 16:38
Оценка: +1
Здравствуйте, velkin, Вы писали:

V>Причём очевидно, что независимый разработчик и владелец облака это не одна и та же организация. То есть вся эта замута с микросервисами нужна владельцам облаков для распределения обработки данных. Следовательно для такой системы нужна команда поддержки, которая будет работать даже не над общим коробочным решением, а просто чтобы всё это запускалось и как-то отрабатывалось в каждом конкретном случае.


Сейчас даже роботов пишут на микросервисах


V>Я здесь не вижу способов как это могло бы упростить жизнь разработчиков или как-то им помочь. Никак это им не поможет. Классы вот тоже в теории должны были быть независимыми и всё такое, а что в итоге. Теория о том, что пока не меняется интерфейс всё будет в порядке не работает, потому что в реале интерфейс таки меняется.


Коллега ушел писать роботов на микросервисах — доволен, как слон
Маньяк Робокряк колесит по городу
Re: Эволюция микро-сервисов
От: Cyberax Марс  
Дата: 23.08.21 03:36
Оценка: +1 -1
Здравствуйте, Ватакуси, Вы писали:

В>Относительно недавно столнулся со следующим "логическим" этапом этих микро-сервисов: микро-веб-приложения.

В>У вас есть сайт (пускай на ангуляре или реакте), который дробится на десятки, если не сотни микро-приложений. Каждое из них:
Не надо так делать. Сотни микросервисов будут нужны только для "сайта" типа amazon.com

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

В>Что вообще думаете?
Без фанатизма делать сервисы (без "микро").

Основное деление должно быть по организационной структуре компании. Т.е. одна команда — один сервис.
Sapienti sat!
Re: Эволюция микро-сервисов
От: Лось Чтостряслось Польша  
Дата: 27.08.21 09:26
Оценка:
Здравствуйте, Ватакуси, Вы писали:

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

вряд ли, ты правильно написал, что + неотделимы от —
В>Что вообще думаете?
что как же хорошо, что я не веб-программист!
русофобия сушит мозг
Re[2]: Эволюция микро-сервисов
От: Лось Чтостряслось Польша  
Дата: 27.08.21 09:28
Оценка:
Здравствуйте, Shmj, Вы писали:

S>хозяевам мира


госспади, ну прекрати уже!
иди вон квалию потренируй, что ли, и то больше пользы будет
русофобия сушит мозг
Re[3]: Эволюция микро-сервисов
От: Shmj Ниоткуда  
Дата: 27.08.21 11:12
Оценка:
Здравствуйте, Лось Чтостряслось, Вы писали:

ЛЧ>госспади, ну прекрати уже!

ЛЧ>иди вон квалию потренируй, что ли, и то больше пользы будет

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

Им не нужны новые Цукерберги. Хотя даже после того, как хозяева мира сыграли с Цукербергом в карты — у него осталось мене 1/4 владения корпорации — все остальное во владении тех, кто понимает глобальные принципы управления.

Сейчас новый Цукерберг практически не возможен — разработка ПО стала стоить слишком дорого и в одиночку ты не сможешь сделать сервис с нуля. А дальше будет еще сложнее. Фулстеков уже практически нет как понятия. И дальше идет еще более глубокое разделение.
Отредактировано 27.08.2021 11:16 Shmj . Предыдущая версия . Еще …
Отредактировано 27.08.2021 11:16 Shmj . Предыдущая версия .
Re[2]: Эволюция микро-сервисов
От: Буравчик Россия  
Дата: 27.08.21 11:16
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Основное деление должно быть по организационной структуре компании. Т.е. одна команда — один сервис.


Вообще, деление на микросервисы должно производиться по функционалу.
Организационная структура может повторять функционал, поэтому и про оргструктуру верно.
Best regards, Буравчик
Re[4]: Эволюция микро-сервисов
От: Sharov Россия  
Дата: 27.08.21 11:44
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Лось Чтостряслось, Вы писали:


ЛЧ>>госспади, ну прекрати уже!

ЛЧ>>иди вон квалию потренируй, что ли, и то больше пользы будет

S>Здесь никакой мистики или теории заговора. Под хозяевами мира понимаю наиболее влиятельные кланы, которые держат доли крупнейших корпораций, вхожи в совет директоров и имеют рычаги оказания давления.


Прочитал как "которые держат логи крупнейших корпораций" Что-то в этом есть.

S>Сейчас новый Цукерберг практически не возможен — разработка ПО стала стоить слишком дорого и в одиночку ты не сможешь сделать сервис с нуля. А дальше будет еще сложнее. Фулстеков уже практически нет как понятия. И дальше идет еще более глубокое разделение.


Мне кажется ровно наоборот -- сейчас такие технологии, что один разработчик вполне может запилить гугл образца середины 00-х.
Облака,ML и вот это вот все. Т.е. проблема не сделать одному -- это, кмк, более чем возможно -- проблема в том, чтобы
раскрутиться. Вот на что уйдет весь бюджет.
Кодом людям нужно помогать!
Re[5]: Эволюция микро-сервисов
От: Shmj Ниоткуда  
Дата: 27.08.21 12:06
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Мне кажется ровно наоборот -- сейчас такие технологии, что один разработчик вполне может запилить гугл образца середины 00-х.


Кому нужен сервис с отставанием на 17 лет? Это почти четверть века.
Re[4]: Эволюция микро-сервисов
От: Лось Чтостряслось Польша  
Дата: 27.08.21 12:09
Оценка:
Здравствуйте, Shmj, Вы писали:


S>Сейчас новый Цукерберг практически не возможен — разработка ПО стала стоить слишком дорого и в одиночку ты не сможешь сделать сервис с нуля. А дальше будет еще сложнее. Фулстеков уже практически нет как понятия. И дальше идет еще более глубокое разделение.

да!
но это не из-за заговора влиятельных кланов, а по объективным причинам
русофобия сушит мозг
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.