>> Коллега работал и в техподдержке, когда для замены проца/памяти
>> мотался по миру с железом. И, собственно, это его впечатлило больше всего
> Ну, видите - вот и ответ на вопрос.
> Ваш коллега был рад, что у него было меньше проблем, чем он ожидал.
> А если бы он менял проц/память на уже выключенном аппарате, с которого
> всё давно уже смигрировало - это было бы, конечно, не так эффектно.

   Он не ожидал: это было его обязанностью. Т.е. он был обучен этому. Но замена без выключения и всего сопутствующего всё равно процесс интересный.

>> Вы, вероятно, мало общались с ДБА и разработчиками СУБД.
>> А мне приходилось участвовать в проектах федерального уровня, где 250 ТБ
>> базы - это не самые большие.
> Ну, некоторый опыт всё-таки был.
> Но, мало-ли, вдруг кому-то действительно нужно было иметь 250 Тб и более
> с готовностью несколько миллисекунд. Не могу зарекаться, что такого не может
> быть, разумеется.

   Это не редкий случай. Это, прежде всего, предсказуемость: по ресурсам, по времени ответа и пр. И это - грамотный подход к проектированию архитектуры.

>>    Вообще считаю, что пихать всё подряд "в кубеня" -
>> очень плохой подход. Хотя сейчас это "стильно, модно, молодёжно".
> Раньше то же самое говорили про линукс, докер, виртуализацию и всякие CI-CD.
> А когда это достигло некоего уровня зрелости - стало возможным делать огромные
> проекты с таким скромным бюджетом и временем, о которых раньше в
> самых дурных снах и помыслить было нельзя.

   Странно смешано. Особенно про Линух и виртуализацию. Да и CI/CD тоже: были, обычно, самописные скрипты, которые заменились на заточенные системы - я не помню каких-то предубеждений по этому поводу.

   А в куберы пихать серьёзные statefull приложения - это, конечно, можно технически, но... зачем? Регулярно вижу, когда какой-нибудь кластер Эластика нагруженный заворачивают в кубер. Спрашиваю: а если под будет мигрировать, а он тут нагружен серьёзно? Ответ: а мы привяжем к конкретным узлам, и чтобы только он мог там крутиться. Зачем, поясните, делать так? Чтобы просто "было в кубере"? Чем эта првязка лучше нативного разворачивания Эластика на тех же серверах?
   А Кафку (не грефневую) в виде кластера? При условии, что регулярно кластер кафки... скажем так: хреново работает в кубере. Можно, конечно, сказать "кривые руки", но руки у коллеги на том проекте вполне себе прямые. Вынесли из Кубера и вздохнули спокойно. Возможно какие-то ухищрения и решают проблему, но "зачем?" - я так и не понял: нативно Кафка вполне себе работает и проще в сопровождении.

> Это дело времени.
> Даже если сейчас есть значительные шероховатости - через несколько лет это войдёт
> в обиход.
> И всё это будет считаться обычной рутиной.
> Как обычной рутиной теперь считается использование линукса в качестве сервера.

   Причём тут это? Запихать-то в кубер можно всё, но ЗАЧЕМ? На мой взгляд: попахивает идиотизмом.

   Вот вы защищаете это самое "всё в кубер". Поясните - ЗАЧЕМ? Зачем запихивать туда ВСЁ? Может быть негативные моменты и можно обойди какой-то хитрой схемой, но ЗАЧЕМ? ЗАЧЕМ усложнять то, что в более простом варианте и так будет отлично работать. Более простом, а, значит, более надёжном.

   Регулярно вижу спецов, которые выучились Ансиблам, Куберам и прочим тераформам, но когда дело заходит про подготовку площадки под проект, то не могут использовать куда более элементарный вещей: отдадут серверы, где "всё есть рут", или 100 ГБ (условно) уйдёт в "всё есть рут", а остальное - в "хомяк". И делай, что хочешь. И в XFS без LVM. - "Партицирование? Вы о чём вообще? Зачем?"