Исходное сообщение
"Первый выпуск свободной PaaS-платформы Cozystack на базе Kub..." Отправлено penetrator, 22-Фев-24 16:45
1) а если у тебя приложение недостчтоно большое, или не имеет таких контекстов, чтобы его распилить его на микросервисы, то все свое взаимодействие внутри приложения (которое может быть как правильно так и неправильно организовано) перенесешь на уровень инфраструктуры и деплоймента потом где-нибудь на реддите появляются сообщения что из-за сложности взаимодействия микросервисов девелоперы на проде плавающие баги месяцами ищут в том числе у таких монтров типа Amazon короче микросервисы ради микросервисов - НЕ РАБОТАЕТ 2) а) головную боль, потому удержать в голове всю лапшу взаимодействий становится сложнее. Это рекламная неправда, что идёт упрощение приложения. Где-то упрощается, а где-то понимать становится сложнее. так сам же подтверждаешь б) Возможность динамически распределять функции приложения по значительному количеству узлов используя возможности оркестратора ога-ога, только это вертикальное масштабирование, а не горизонтальное, scale up можно и без микросервисов, а если ты хочешь микросервис в горизонтальное масштабирование, то туда можно засунуть и немикросервисное приложение, можно выделить часть (но зачем?) его API и предоставить наружу, через HAProxy, в любом случае это настолько незначительные изменения, что ими нельзя объяснить пятикратной выгоды BaseCamp. т.е. микросервисы в данном случае нужны только, если тебе критически важно масштабировать горизонательно разные части твоего приложения ПО-РАЗНОМУ, например из-за стоимости лицензий, особенностей интеграции, или использования специфического оборудования, ну или по какой-то другой технической причине, 80% проектов если не больше не нуждаются в микросервисах и их по ошибке используют, как средство упрощения процесса разработки, но работает это далеко не всегда, и появляется необходимость в девляпсах, которые это все будут заводить в прод, агрегируя результаты работы подкоманд, как по мне ужасное решение по проектным процессам 3 и 4) ты будешь платить так что тебя оно будет раздевать, потому что оверпрайс там при масштабировании идет на порядок выше и более, т.е. можно с запасом взять второй дедик, чтобы загрузка пиковая была не более половины мощностей и при увелечении докупать аренду еще одного и это все равно ОЧЕНЬ ДЕШЕВЛЕ, чем брать облака в соотвествии в потреблением!!! т.е. другим словами "простой дедика" стоит намного дешевле чем "загрузка облаков" только в случае с дедиком у тебя предсказуемые, условно-фиксированные, и само собой более низкие счета и никак наличие нескольких сервисов с дополнительным сетевым оверхедом не позволит тратить мне меньше на инфраструктуру, не убедил

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> 1) а если у тебя приложение недостчтоно большое, или не имеет таких > контекстов, чтобы его распилить его на микросервисы, то все свое взаимодействие > внутри приложения (которое может быть как правильно так и неправильно организовано) > перенесешь на уровень инфраструктуры и деплоймента > потом где-нибудь на реддите появляются сообщения что из-за сложности взаимодействия микросервисов > девелоперы на проде плавающие баги месяцами ищут в том числе у > таких монтров типа Amazon > короче микросервисы ради микросервисов - НЕ РАБОТАЕТ > 2) > а) головную боль, потому удержать в голове всю лапшу взаимодействий становится сложнее. > Это рекламная неправда, что идёт упрощение приложения. Где-то упрощается, а где-то > понимать становится сложнее. > так сам же подтверждаешь > б) Возможность динамически распределять функции приложения по значительному количеству > узлов используя возможности оркестратора > ога-ога, только это вертикальное масштабирование, а не горизонтальное, scale up можно и > без микросервисов, а если ты хочешь микросервис в горизонтальное масштабирование, то > туда можно засунуть и немикросервисное приложение, можно выделить часть (но зачем?) > его API и предоставить наружу, через HAProxy, в любом случае это > настолько незначительные изменения, что ими нельзя объяснить пятикратной выгоды BaseCamp. > т.е. микросервисы в данном случае нужны только, если тебе критически важно масштабировать > горизонательно разные части твоего приложения ПО-РАЗНОМУ, например из-за стоимости лицензий, > особенностей интеграции, или использования специфического оборудования, ну или по какой-то > другой технической причине, 80% проектов если не больше не нуждаются в > микросервисах > и их по ошибке используют, как средство упрощения процесса разработки, но работает > это далеко не всегда, и появляется необходимость в девляпсах, которые это > все будут заводить в прод, агрегируя результаты работы подкоманд, как по > мне ужасное решение по проектным процессам > 3 и 4) ты будешь платить так что тебя оно будет раздевать, > потому что оверпрайс там при масштабировании идет на порядок выше и > более, т.е. можно с запасом взять второй дедик, чтобы загрузка пиковая > была не более половины мощностей и при увелечении докупать аренду еще > одного и это все равно ОЧЕНЬ ДЕШЕВЛЕ, чем брать облака в > соотвествии в потреблением!!! > т.е. другим словами "простой дедика" стоит намного дешевле чем "загрузка облаков" > только в случае с дедиком у тебя предсказуемые, условно-фиксированные, и само собой > более низкие счета и никак наличие нескольких сервисов с дополнительным сетевым > оверхедом не позволит тратить мне меньше на инфраструктуру, не убедил
	Введите код, изображенный на картинке: