а нужны ли мне эти ваши docker-контейнеры?

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

Однако «Варяг» погиб не зазря, некоторые его помнят до сих пор.

Какое к черту сражение? Я тут в треде срусь только для того, чтобы сделать краткий конспект по итогам. Так сказать «себя показать — людей посмотреть». Все-таки хочется держать руку на пульсе времени, а покрутить докеры серьезно не получалась — слишком уж это стартапоспецифичная хрень без реальных применений. То есть, применение у него только одно — заработать деньги и уйти в закат.

тех, кто готов потратить тридцать триста циклов проца вместо трёх

Ты уверен про триста? Вызов функции, даже в ноде при оптимизации — это 10-15 циклов. Сколько стоят переключения контекстов при работе с сетью? Порядка тысячи циклов на каждый read/write, даже если у тебя асинхрон, а с синхронными подключениями будет еще больше. А если это JSON/XML/HTTP, то привет парсинг. Итого 10 тыс циклов — норм такая оценка.

Так весь проект, вся профессия сегодня это как юнит-тест - нужен только как вещь в себе.

Я говорю о немасштабируемой несетевой ФС, написал же сразу, что говорю «о тупом сценарии». Распределенность подразумевается средствами БД, ну или о какой там организации хранилища ты говорил, когда интересовался, как при пересоздании ноды будут копироваться данные. Я думал, что именно о такой, когда нода хранит свои файлы на самой себе.

«покрутить докеры серьезно не получалась»

В IT разные есть специальности. Докеры это не для разработчков, а для инженеров по развёртыванию и внедрению.

Запуск СУБД в докере подобен запуску чего угодно в докере. Вот, вообще никакой разницы с запуском без него. Дополнительных удобств в виде бесплатной горизонтальной масштабируемости, конечно, не получишь, но и вреда особо никакого.

Выйдет дешевле. Потому как считать нужно не EC2 instance в амазоне против виртуалки в хетцнере, а набор сервисов в AWS + команда админов, умеющих их готовить против набора виртуалок в хетцнере вместе с командой админов, которая будет всё с нуля разворачивать. Дополнительный бонус: затраты на AWS вычитаются из налогооблагаемой базы, а за админов (помимо зарплаты) нужно платить дополнительные налоги и социальные отчисления. Такие дела.

затраты на AWS вычитаются из налогооблагаемой базы, а за админов (помимо зарплаты) нужно платить дополнительные налоги и социальные отчисления

Вот сразу надо было с козырей заходить, дав две строчки:
AWS на 100 руб, админов на 5 руб, социалка: -Х
Хетцнер на 5 руб, админов на 100 руб, социалка: +Y

Как оно на самом-то деле в риал лайф цифрах, примеры имеются?

Какой у тебя может быть конспект если ты зачем-то четыре страницы противопоставляешь микросервисы базам данных и файловым системам.

В проекте где я работала терабайтная БД реплицируемая на пять датацентров как была до начала времен так и осталась после распиливания одного из Java-монолитов на компоненты. И БД было абсолютно всё равно ходят к ней 1000 потоков из одного сервиса или 100 раз по 10 потоков из каждого отдельного компонента.

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

Не соглашусь. Команда админов, умеющих готовить AWS/Azure более скилловая –> зарплата в разы выше, чем у джуниор-админа, который вообще-то CCNA и usermod -a -G wheel ugoday может набрать в терминале.

Я в этой отрасли недавно, но тендецию вижу, что толковые админы перешли на AWS/Azure и получают хорошую зарплату. А менее скилловые так и остались админить бубунту на хетцнере

Вывод: Админ нужен и для AWS/Azure/GCP и для условного Hetzner. Для AWS админа зарплата будет +40% выше, но с другой стороны продукт будет качественнее. Правильно организованный бизнес будет с налаженным финпотоком будет делать ставку на стабильное и качественное решение и не будет экономить на спичках.

Какая еще «зона ответственности»?

Вас же не смущает, что Апач в LAMP делает одну задачу, а MySQL — другую. А здесь почему смущать начало? Докер занимается упаковкой зависимостей в образа и запуском процессов в изолированном контейнере. Другие задачи решаются другими инструментами.

Даже для отладки и контроля системы нужно хранить логи.

Эластиксёрч для вас слишком продвинутая технология?

«где хранить данные для микросервиса?

Там же, где и для мегасервиса. Вопросы запуска процессов и хранения данных ортогональны друг другу.

И ещё соображение: если использовать сторонние сервисы по максимуму, ускоряется подготовка инфраструктуры, а значит снижается время до запуска на рынке. Как растут затраты можно посмотреть у бухгалтера. А вот как рост прибыли посчитать? Это интересный вопрос.

Как растут затраты можно посмотреть у бухгалтера. А вот как рост прибыли посчитать? Это интересный вопрос.

И то и другое надо смотреть у финансиста, если живете не в СССР. Я посмотрел Ваши комменты выше - технические - все очень верные, явно разбираетесь в отличии от товарища, который один раз докер видел и то был не трезв, говорит может привиделось. Как только Вы перешли из технического отдела в область управления предприятием - то сразу «поплыли» - явно не Ваша тема

Вообще контейнер - плохой термин конечно. Он создаёт неверное впечатление какой-то отдельно стоящей коробки и от этого у пользователей случается когнитивный диссонанс.

Мы сейчас на CI виртуальные машины в контейнерах запускаем.

И поначалу мне прямо это казалось какой-то совершенной ересью. Машина в контейнере, лишние слои, ааа!!!

А потом так как бы да: виртуальная машина запущенная в своём namespace. Инструменты для её запуска и прогона нужных нам тасков упакованы в архив(образ). Оркестрацию этого всего, то есть выбор ноды, запуск процесса на ней и чистку по окончанию делает kubernetes.

docker как инструмент управления контейнерами лишняя сущность конечно в этой схеме, и вот то что он был изначально привязан к собственно запуску контейнера - это конечно была проблема. Но сейчас это уже всё решено.

AWS-админ может за 5 минут RDS базу накликать. А джуниор-админ может за 5 минут sudo apt get mysql набрать. Тут меж ними как бы паритет. Но потом джуниор узнает, что на этом работа не заканчивается, нужно базу мониторить и о проблемах оповещать, логи собирать, логи ротировать, бэкапы делать (а ещё резервные копии нужно проверять на предмет того, что из них реально развернуть копию данных (а ещё это нужно делать регулярно)) и тоже ротировать, а БД рядом с приложеним только нубы держат, надо бы в изолированный сегмент сети переместить и т.д. и т.п. В общем, тут тонна работы о которой программисты и не подозревают и делать всё с нуля и вручную как-то грустно.

Другой вопрос, что упрощая возможность делать комплексную инфраструктуру, AWS провоцирует реакцию «мы щаз запилим всё круче чем у Гугла», что добавляет кучу работы на ровном месте. Но за это платят, вы верно заметили. Так что все в выигрыше.

то сразу «поплыли» - явно не Ваша тема

Что есть, то есть. Я исхожу из общих соображений, если внезапно вся индустрия ломанулась в определённом направлении, значит что-то в этом есть. Перегибы возможны, но люди в среднем не дураки и свой интерес знают. Значит нужно понять отчего так происходит, вместо того, чтобы с порога объявлять всех дебилами.

Машина в контейнере, лишние слои, ааа!!!

Ну, слои и слои, чего бухтеть-то? Я верю, что есть ситуации, когда производительность критична и вот надо за кадый процент биться. Ни разу не видел, но готов допустить. В тех областях где работаю я это не так, зато есть куча организационно-админских проблем, которые хотелось бы как-то упростить. И если для этого нужно «сунул докер докер в докер», то отчего нет?

Потеря 15% производительности меня совершенно не напрягает. А вот то, что раньше новую версию приложения выкатывал админ ночью или по выходным, а теперь разработчики когда угодн — это приятно.

В проекте где я работала терабайтная БД реплицируемая на пять датацентров как была до начала времен так и осталась после распиливания одного из Java-монолитов на компоненты.

Независимо к вашему диалогу, вновь ты глупости говоришь. Противопоставляя макросервисы и монолит. 1TB БД не так уж много. С этим вполне справится VPS средней поршивости. Скорее всего сама структура была сделана рукожопами и БД постоянно обращается к диску, вместо нормальной работы.

Так что твой пример скорее говорит о некомпетентности, которую у вас закрыли ресурсами. Вот и все. К слову, 5 ДЦ - так не говорят, слишком абстрактно, в 1 ДЦ у тебя может быт 1 сервер, а может 10.

А, ну да. Криво прочитал. Извиняюсь, альфа. Ты как раз о том же говоришь. Привык, что ты тупишь обычно :D

Естественно, если речь идет про большой проект, обслуживающий значительное число пользователей и вечно хранящий статистику по ним

и все это в одной базе?

cнижается время до запуска на рынке

Мне было бы по честному интересно знать, о каких масштабах прожектов каждый тут пишет. Топик начался, собственно, с того, что было решено сертбот выделить отдельным контейнером.
Это масштаб какого уровня проекта нынче, малого, среднего или уже большого, которй надо деплоить непереставая на AWS 24/7 всем коллективом в одночасье, снабжая это эксабайтам бигдаты.
А то одному и баш скрипт это уже целый контейнер, а некоторые могут без контейнеров обслуживать десятки тысяч юзеров и при этом знать, что потрачено не тридцать тысяч циклов цпу на один вызов, а всего три, как это, собственно, изначально умными людьми на перфокартах и задумывалось.

Так что без указания масштабов проектов смысл дискусси теряется.

А вот как рост прибыли посчитать

Если под прибылью имеется в виду зарплата программистов, то понятно как.

А как продажа носовых платков зависит от скорости деплоя их бигдаты на AWS - это да, эс гибт проблемхен с рассчётом.

Я говорю о немасштабируемой несетевой ФС, написал же сразу, что говорю «о тупом сценарии»

Как раз «сетевая ФС» — это немасштабируемый костыль, который создан потому, что в один диск ФС не вмещается и/или нам нужно отказоустойчивость сверх предоставляемой RAID-ом.

Распределенность подразумевается средствами БД, ну или о какой там организации хранилища ты говорил, когда интересовался, как при пересоздании ноды будут копироваться данные. Я думал, что именно о такой, когда нода хранит свои файлы на самой себе

Например, при пересоздании ноды архивные данные будут браться с удаленного узла, а самые свежие скопируются на локальную. Или аналогичное разделение ролей, только на уровне логики, работающей по принципу map-reduce. Или по принципу «кэша». Вариантов несколько, но у них есть общее свойство — докеры с кубернетами никак не помогают эти сценарии хранения реализовать.

Просто, у современных «архитекторов» слепое пятно на месте БД, типа «да оно как-нибудь само заработает, я займусь самым важным — буду плодить микросервисы без остановки, ведь это масштабируется». А потом DBA рвут волосы на голове и жопе, потому что система загибается уже на тысяче одновременных клиентов, которые благодаря масштабируемости архитектуры «масштабируются» в сотни тысяч запросов к БД.

Запуск СУБД в докере подобен запуску чего угодно в докере. Вот, вообще никакой разницы с запуском без него

Персистентность? Репликация? СУБД нельзя просто так запустить, под него должны быть данные, а для репликации нужно строгая конфигурация.

Потому как считать нужно не EC2 instance в амазоне против виртуалки в хетцнере, а набор сервисов в AWS + команда админов, умеющих их готовить против набора виртуалок в хетцнере вместе с командой админов, которая будет всё с нуля разворачивать

Я ж не спорю, что начальная настройка с нуля будет труднее. Но когда вам начнут из месяца в месяц приходить счета на десятки, а то и сотни тысяч долларов, и они будут только увеличиваться со временем — это не весело. При том, что единственный способ от этого отмазаться — это таки создать свою систему на своих серверах с нуля. Что будет еще сложнее и еще дороже сделать на уже работающей системе. Это такой ультимативный вариант технического долга, когда не просто «разработка с каждым днем сложнее и дороже», а «просто стояние на месте приносит огромные убытки, любое движение вперед этим убытки наращивает».

Дополнительный бонус: затраты на AWS вычитаются из налогооблагаемой базы, а за админов (помимо зарплаты) нужно платить дополнительные налоги и социальные отчисления

Как удобно тратить чужие деньги.

Если у вас есть один проект на AWS, то и всё остальное будет тоже на АВС. Не держать же паралельно две инфаструктуры для «серьёзных» и «несерьёзных» задач. А так, я бы админами мерял. Если один админ справляется всё делать сам — пусть и дальше делает. А если их уже хотя бы три надо, имеет смысл перестать фигнёй маяться.

Какой у тебя может быть конспект если ты зачем-то четыре страницы противопоставляешь микросервисы базам данных и файловым системам

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

В проекте где я работала терабайтная БД реплицируемая на пять датацентров как была до начала времен так и осталась после распиливания одного из Java-монолитов на компоненты. И БД было абсолютно всё равно ходят к ней 1000 потоков из одного сервиса или 100 раз по 10 потоков из каждого отдельного компонента

Спасибо за хотя бы какие-то подробности, но на этом уровне детализации я все равно не могу ни согласиться, ни возразить. Может ведь оказаться и так, что у вас там неповторимо безупречное кэширование контекстов, что каждый сервис от соседей узнает нужную ему информацию без необходимости в центральном хранилище, и при этом вся эта де-факто распределенная БД внутри сервисов умеет оставаться согласованной без этого самого центрального хранилища. Но для 99% систем это не так — а я пишу именно про типовые микросервисы, на докерах, монге, касандре, питоне, ноде — продолжайте список.

При этом таких вещей как скорость выкатки релиза, простота разработки в команде и прозрачность процесса выкатки для разработчика у тебя вообще нет в области видимости

Давай разберем сказанное по частям. Скорость выкатки? В чем проблема скорости выкатки монолита? Что он долго собирается? Я очень надеюсь, что вы пишете не на крестах, иначе могу лишь посочувствовать. Что тестировать нужно систему целиком? Тестировать распределенную систему ОЧЕНЬ сложно. Не «на отлюбись» тестировать, а именно грамотно, с гарантиями. что она не завалится на пиковой нагрузке, вызванной посетителями или просто кривой архитектурой, резко генерирующей из ниоткуда кучу запросов в одну секунду, например, потому что кто-то почистил кэш.

Когда у тебя монолит, то все эти эффекты видны из нескольких десятков функций и приводят к намного менее серьезным эффектам, потому что вместо передачи данных по сети происходят простые вызовы функций.

простота разработки в команде

Я даже толком не знаю, как серьезно на это отвечать. Давай для начала прикинем, что вообще есть «сложного» в разработке модульного монолита. Самый канонический вариант — ядро линя. Сколько там людей в разработке участвует? Сотни? Каждый занимается своим модулем-подсистемой, в рамках одного модуля работает штук пять программистов максимум. Что сложного в разработке такого монолита? Что могут измениться глобальные структуры-функции и придется всей команде обновлять код? Расскажи мне, что произойдет с микросервисами, если руководство решит перейти с Постгреса на Касандру. Или решит, что JSON слишком медленно бегает — на следующей неделе будем переделывать систему на protobuf. Да разработка встанет на полгода.

Так что здесь скорее «я предпочитаю видеть только простоту разработки в команде, но не хочу видеть большого числа трудностей в разработке командой».

прозрачность процесса выкатки

Это что вообще такое? Не, на это меня уже не хватает, сорян.

Персистентность? Репликация?

И животноводство.

Запуск процесса в некотором namespace никак не отменяет репликации и сохранения состояния.

Я в этой отрасли недавно, но тендецию вижу, что толковые админы перешли на AWS/Azure и получают хорошую зарплату. А менее скилловые так и остались админить бубунту на хетцнере

Спрос и предложение — причины не технические, а маркетинговые. Есть много стартапов, которым лишь бы выкатить что-то, чтобы показать инвесторам прогресс, а дальше уже не важно, потому что CEO изначально не собирался создавать какой-то серьезный сервис.

Правильно организованный бизнес будет с налаженным финпотоком будет делать ставку на стабильное и качественное решение и не будет экономить на спичках

Если не разорится на AWS до того, как выйдет на прибыльность или продастся. Тот же инстаграм бы разорился, но его выкупил фесбук, и первым делом полностью убрал весь AWS из инсты.

а я пишу именно про типовые микросервисы

Ты пишешь исключительно про соломенные микросервисы которые выдумываешь тут же по ходу дела.

Это что вообще такое? Не, на это меня уже не хватает, сорян.

Ага.

Вас же не смущает, что Апач в LAMP делает одну задачу, а MySQL — другую

Вообще не смущает. Меня смущает программист, который говорит «я эксперт по PHP, но в этих ваших MySQL и HTML ничего не понимаю — мне это и не нужно, я зато эксперт по PHP».

Докер занимается упаковкой зависимостей в образа и запуском процессов в изолированном контейнере

Чур не прыгать по темам. Разговор шел про «мы пишем микросервисы, а БД нас не волнуют». Докер — это слишком абстрактная и универсальная вещь, чтобы говорить про какую-то специализацию. Я вот не видел вакансий «нужен специалист по докеру» — почему-то всем нужны мастер на все руки, девопс, который и гитом занимается, и сборкой, и CI/CD, деплой прода настраивает, и логирование-контроль — не очень-то похоже на специалиста.

Даже для отладки и контроля системы нужно хранить логи.

Эластиксёрч для вас слишком продвинутая технология?

Постгрес в контейнере умеет писать логи в эластик? Если же сервис изначально разрабатывать под эластик, то получится, что даже для отладки сервиса на локалхосте нужно разворачивать инфраструктуру с эластиком. Собственно, да, примерно как обычно и отлаживаются подобные системы.

«где хранить данные для микросервиса?

Там же, где и для мегасервиса. Вопросы запуска процессов и хранения данных ортогональны друг другу

Мегасервис имеет внутренний кэш, как правило когерентный — он находится в общей памяти. Микросервисы не могут позволить себе такой роскоши, поскольку у них, как известно, нет общей памяти — вместо этого кэшами становятся внешние сервисы. Я уже выше приводил альфе пример того, насколько быстро такая система быстро выбивается из рук, по крайней мере если на с волнует производительность и эффективность использования ресурсов.

И ещё соображение: если использовать сторонние сервисы по максимуму, ускоряется подготовка инфраструктуры, а значит снижается время до запуска на рынке

Поправка-обобщение: если используются ГОТОВЫЕ РЕШЕНИЯ. Они не обязательно должны быть сторонними сервисами, но ты так пишешь, будто готовое решение — это только сторонний сервис.

Естественно, если речь идет про большой проект, обслуживающий значительное число пользователей и вечно хранящий статистику по ним

и все это в одной базе?

Конечно нет. Но не все ли равно, хранить ли 30 миллиардов записей в одной базе или в трех?

Я всего лишь о том, что копировать данные при пересоздании ноды не требуется. Вот об этом: потому что для «перезапуска на другом узле» нужно как-то перекинуть сотни гигабайт данных.

Ну, как минимум в пределах ДЦ не требуется.

Вот настоящий Владимир!!!

Твиссель, вы сами понимаете что пишете? Какой то развязный аноним зовет вас целоваться в мусорный контейнер, а вы и рады … Цитирую его, подлеца:
Мы в контейнере у тебя целуемся …
Вы беритесь за ум, Твиссель, вливайтесь в мою команду разработчиков АПИ …

Владимир

Ты пишешь исключительно про соломенные микросервисы которые выдумываешь тут же по ходу дела

Я сразу написал, что это не 100%, а 99%, так что это может быть не ваш случай.

прозрачность процесса выкатки

Это что вообще такое? Не, на это меня уже не хватает, сорян

Ага

Ну, то есть, я был прав по поводу выборочного отображения фактов. Ну типа как пояснить покупателю, что у него в доме нет одной стены? «Свежий воздух, прекрасный вид на речку из комнаты». Так и тут: мы вываливаем в прод наш сервис без тщательного интеграционного-нагрузочного тестирования, но это теперь называется не «херак-херак — и в продакшен», а «прозрачность процесса выкатки».

а для репликации нужно строгая конфигурация.

Что абсолютно одинаково при запуске БД внутри докера и вне его. Сюрприз!

Меня смущает программист,

Это докер виноват, что программист в чём-то не разбирается?

Разговор шел про «мы пишем микросервисы, а БД нас не волнуют»

Сюрприз. Нас много чего не волнует, начиная с того где сервер электричество берёт. Важная тема, без него ничего не работает, но занимаются этим другие люди. Ну вот так вот всё склалось.

почему-то всем нужны мастер на все руки, девопс, который и гитом занимается, и сборкой, и CI/CD, деплой прода настраивает, и логирование-контроль — не очень-то похоже на специалиста.

1. Не вижу проблемы.

2. А в Африке негры голодают. Эту проблему докер тоже не решает, дарю вам в качестве аргумента.

Постгрес в контейнере умеет писать логи в эластик?

СЮРПРИЗ! И не в контейнере тоже. Какая разница как вы процесс запустили, на сбор логов и метрик это никакого влияния не оказывает.

Если же сервис изначально разрабатывать под эластик

А вот это уже не сюрприз. Это фейспалм.

Мегасервис имеет внутренний кэш, как правило когерентный — он находится в общей памяти.

очень рад за него.

Микросервисы не могут позволить себе такой роскоши, поскольку у них, как известно, нет общей памяти — вместо этого кэшами становятся внешние сервисы.

Вот и решение.

на с волнует производительность и эффективность использования ресурсов.

Расскажите чем вы таким важным занимаетесь?

ГОТОВЫЕ РЕШЕНИЯ. Они не обязательно должны быть сторонними сервисами

Дешевле купить готовое, чем платить команде админов/кодеров/тестировщиков. Ну, если в вашей стране, конечно, рабство отменили. Если есть много бесплатной рабочей силы, то хоть что можно сделать, хоть свой AWS написать, хоть пирамиды возвести.

Но потом джуниор узнает, что на этом работа не заканчивается, нужно базу мониторить и о проблемах оповещать, логи собирать, логи ротировать, бэкапы делать (а ещё резервные копии нужно проверять на предмет того, что из них реально развернуть копию данных (а ещё это нужно делать регулярно)) и тоже ротировать

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

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

Ты так пишешь про ротацию логов и репликацию, будто это какая-то высшая математика, а не просто «сделать apt-get и прописать конфиги». Причем, при всех красивых историях про репликацию и бэкапы из коробки в AWS, оный не гарантирует отсутствие потерь данных, а при проблемах с производительностью нужно ставить иконы и свечки. Кастомная репликация? Мечтай, жри что дают. То есть, ты быстро получил готовое решение, которое не поддается дальнейшему развитию — классический техдолг. И по итогу, когда тебе реально нужен пит-стоп за две секунды, AWS его не может обеспечить.

С рациональной позиции получается абсурд, но я даже могу представить, как это работает: приходит к заказчику Вася, и говорит «ну, мы сначала поставим тестовый мускуль на VPS, на нём будем первые наброски системы разрабатывать, потом когда-нибудь прикрутим репликацию...», уходит Вася, приходит Коля «мы за пять минут развернем мультимастер с автоматическими снэпшотами и мультизональной доступностью» — и заказчик говорит Коле «вау, да ты понимаешь, о чем говоришь, готовая система в кратчайшие сроки, сразу чувствует опыт, не то что этот лошара Вася». В этом плане психология заказчика мало отличается от домохозяйки, которая хочет купить таблетку, от которой бы разгладились морщины и вес снизился на 20 кг. Это НЕВОЗМОЖНО — но это покупают, ещё и как. К вопросу о том, почему я не дружу с заказчиками.

БД рядом с приложеним только нубы держат, надо бы в изолированный сегмент сети переместить

Ладно бы сказал «на отдельный хост», но в отдельный сегмент? Зачем? Чтобы дальше было пакеты гонять? Я догадываюсь, что это популярный подход, судя по тому, как неохотно сайты выдают большие объемы данных, но всё же я не понимаю, откуда этот паттерн архитектуры взялся.

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

«Индустрия» ломанулась вкладывать в MMM/Bitcoin/пирамиданейм — ты мне расскажешь, что «люди не дураки, свой интерес знают»? В принципе, те, кто организовывают пирамиды — да, знают, но все, кто вступают в пирамиду, являются лохами в той или иной степени, даже если по итогу выходят в плюсе — «организатор», более высокое звено от их плюса получило намного больше.

Как бы я даже не пытаюсь спорить по поводу того, что рак микросервисов заполонил рынок, но я пытаюсь найти в этом какое-то рациональное зерно, и пока что не особо получается. «Набрать два десятка дешевых джунов пилить год систему, которую три грамотных сеньора сделали бы за месяц» — это такая-себе рациональность и такая-себе оперативность занятия ниши стартапом.

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

Разрабы того же ватсапа делали это всегда. Конечно, у них монолитная распределенная система на эрланге, но всё же.

Если у вас есть один проект на AWS, то и всё остальное будет тоже на АВС. Не держать же паралельно две инфаструктуры для «серьёзных» и «несерьёзных» задач. А так, я бы админами мерял. Если один админ справляется всё делать сам — пусть и дальше делает

Я бы на этом и закончил. Есть какая-то задача, требующая минимальных ресурсов и простенького железа, не особо требовательная к аптайму, но из этого раздувается «репликация, 24/7, микросервисы, я же гугл». Если у вас есть мелкий проект с небольшой нагрузкой, то платить 100$ в месяц AWS за безгеморный хостинг с автоматизацией простейших сценариев администрирования — это идеальный вариант, я даже не буду пытаться здесь спорить. Впрочем, не один амазон предоставляет хостинг мускуля.

Если мне нужна реплицированная БД с логированием-мониторингом, то у меня уже есть большой нагруженный проект

Просто интересно: а если проект небольшой и ненагруженный, то бэкапы и остальное внезапно стали не нужны?

мне уже придется делать мониторинг для своей собственной системы, даже если она крутится на AWS, поскольку мне интересны метрики системы в целом, а не только отдельных служб.

Это всё замечательно, только все эти (а также многие другие) задачи в AWS делаются легче и быстрее, чем без него.

Ты так пишешь про ротацию логов и репликацию, будто это какая-то высшая математика,

Ага. Причём со знанием дела пишу, а не фантазирую как некоторые.

а не просто «сделать apt-get и прописать конфиги».

А это всегда так. Кажется, что надо просто «сделать apt-get и прописать конфиги», а потом куда-то пара человекомесяцев девается. Прямо магия.

С рациональной позиции получается абсурд,

Тут уместна цитата:

— Ах, я усмехнулся совсем другому. Видите, чему я усмехнулся: я недавно прочел один отзыв одного заграничного немца, жившего в России, об нашей теперешней учащейся молодежи: «Покажите вы, — он пишет, — русскому школьнику карту звездного неба, о которой он до тех пор не имел никакого понятия, и он завтра же возвратит вам эту карту исправленною». Никаких знаний и беззаветное самомнение — вот что хотел сказать немец про русского школьника.

приходит к заказчику Вася, и говорит «ну, мы сначала поставим тестовый мускуль на VPS, на нём будем первые наброски системы разрабатывать, потом когда-нибудь прикрутим репликацию…», уходит Вася, приходит Коля «мы за пять минут развернем мультимастер с автоматическими снэпшотами и мультизональной доступностью» — и заказчик говорит Коле «вау, да ты понимаешь, о чем говоришь, готовая система в кратчайшие сроки, сразу чувствует опыт, не то что этот лошара Вася».

Ну да, как-то так.

Ладно бы сказал «на отдельный хост», но в отдельный сегмент? Зачем?

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

Ты опять несешь чушь. Иди протрезвись. Этот стэк был там в 2009-ом. Монолит и клиент под симбиан. Они давно все переписали по стандарты FB и везде всунули PHP/JS

Запуск процесса в некотором namespace никак не отменяет репликации и сохранения состояния

Вот я об этом и пишу — мускуль нельзя просто «запустить в некотором namespace», он должен быть сконфигурирован под конкретное окружение и иметь конкретный снимок данных. И на этом фоне проблема «где пропали мои данные?» намного более актуальна при смене конфигурации, чем «на каком порте висит новый экземпляр мускуля?».

Ладно бы сказал «на отдельный хост», но в отдельный сегмент? Зачем? Чтобы дальше было пакеты гонять? Я догадываюсь, что это популярный подход, судя по тому, как неохотно сайты выдают большие объемы данных, но всё же я не понимаю, откуда этот паттерн архитектуры взялся.

Чувак, web не ограничивается одним твоим местечковым интернет-магазином. Часто специально надо разместить сервисы по датацентрам так, чтобы нормально работать со всем миром. Не просто же так услуги CDN востребованы. И конечно смешно читать, что 99% проектов это php+mysql. Это уже лет 15 как не так. Просто под каждую задачу свое решение. Микросервисы удобны - програмистам проще сопровождать их. Проще масштабировать и добавлять новую функциональность.

«Индустрия» ломанулась вкладывать в MMM/Bitcoin/пирамиданейм — ты мне расскажешь, что «люди не дураки, свой интерес знают»?

Биткоин не пирамида, а в МММ индустрия не вкладывалась. Ещё примеры у вас будут?

но я пытаюсь найти в этом какое-то рациональное зерно,

А выглядит как будто пытаетесь обгадить всё, чего не понимаете.

и пока что не особо получается.

Наверное каши мало едите.

Ты опять несешь чушь. Иди протрезвись. Этот стэк был там в 2009-ом. Монолит и клиент под симбиан. Они давно все переписали по стандарты FB и везде всунули PHP/JS

По моем сведениям на бэке ничего не поменялось:

https://www.cometchat.com/blog/whatsapps-architecture-and-system-design

Рад за них, за вацап и за эрланг.

Еще раз. Там поменялось все. Весь стэк поменяли. То что ты пишешь - было в 2009-ом году.

I’m a former WhatsApp server engineer[1]. WhatsApp primarily moved from bare metal hosting running FreeBSD to Facebook’s owned and operating containerized management system which incidentally runs Linux.

Сейчас там контейнеры, джаваскипт и пхп местного разлива (хак)