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

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

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

очередная корпорация модифицирует фрях, но изменениями не делится

Все кто надо - делятся. И не потому что их копилефт-копирасты заставляют, а потому что делиться выгоднее.

это не прокатывает в случае люникса, и по итогу у линя все правки в общем апстриме

Вовсе нет, причём дважды. Во-первых, не все правки надо принимать, если и некачественные (но их тоже местами принимают). Во-вторых, не все правки принимают в апстрим, вот слышал например историю как те самые «корпорации» в лице микрософта пытались закоммитить в апстрим какой-то свой драйвер, а их отклонили.

Только очень странный человек будет брать AWS, чтобы запускать на нём голые EC2 instances.

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

Можно сказать «я тут чищу говно вилкой»

Дело ваше, но я бы рекомендовал сменить место работы.

хостовая ОС работает норм, с ней всё в порядке, это просто бизнес встал колом и не может ни один запрос обработать, но это уже мелочи

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

А на проде прод-сервис это не «замусоривание» а основная функция.

правильно и если сервис развивается, то постоянно его надо обновлять + приходится обновлять другие компоненты (например библиотеки так как в них что-то очень вкусное для разработчиков появилось)? Ну и в случае физических проблем с сервером насколько быстро ты сможешь поставить то же самое окружение на новый сервер?

Докер сделает так, чтобы сожравший ресурсы сервис продолжал работать?

докер даст возможность этому сервису выжрать не больше чем ему выделено.

Плюс одно спасибо за развёрнутый ответ.

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

Второй акт: я поставил memcached, потому что моей БД слишком плохо. Кэшам и клиентам желательно быть как можно ближе друг к другу — ладно, это кубернет умеет решать. Мы сейчас опускаем проблему отказоустойчивости БД, допустим, что она у нас отказоустойчива by-design и мы можем на пофиг запускать-останавливать наши экземпляры БД. Возникает новая проблема — как убедиться, что наш кэш с приложением не живут своей жизнью отдельно от БД? Собственно, за меня этот ответ может дать архитектор из фейсбука:

https://www.youtube.com/watch?v=m4_7W4XzRgk&t=910s — NSDI '13 - Scaling Memcache at Facebook

Они подвязались в репликацию мускуля для того, чтобы напрямую слать оповещения в memcached. Да, кстати, напомните мне, в какие именно экземпляры memcached эти оповещения о репликации слать, и самое главное, от кого ждать ответа для того, чтобы засчитать очередной элемент лога мускуля успешно реплицированным? Мы не можем перезапускать memcached с новыми конфигами при смене набора клиентов и/или БД — перезапускать или обновлять конфигурацию мы будем у роутеров. Ага, то есть, нам нужны дополнительные сервисы-роутеры для репликации и какой-нибудь mcrouter между клиентами и memcached.

Вы уже чувствуете, какая «простая» система у нас получается, как много проблем мы «решили» при помощи кубернета?

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

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

Вот ты 5 страниц в теме исписал, а скажи честно, докер когда-нибудь в глаза видел?

Конечно видел, и запускал, но не более того.

Только очень странный человек будет брать AWS, чтобы запускать на нём голые EC2 instances

Я ж не спорю, только выйдет еще дороже.

Самое смешное что вы контейнером сервис защищаете, а этот ваш кубернейтс сам в защите нуждается.

docker и kubernetes это как бы очень разные вещи (как рельсы и светофор). А так да, человеческий фактор может абсолютно любую систему сделать уязвимой.

потому что для «перезапуска на другом узле» нужно как-то перекинуть сотни гигабайт данных

Дык хранилище и инстанс мускуля это разные сущности, не?

заказчику просто очень хочется почувствовать себя гуглом

А, то есть ты как минимум на треть со мной согласен!

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

cgroups изначально были реализованы гуглом с целью организации ПЕРЕраспределения ресурсов. Ключевой префикс — пере. То есть, таким образом можно огранизовывать приоритеты по использованию ресурсов. Но это только при условии, что изначально вообще есть такая задача. Да, можно ограничить какие-то вспомогательные службы, но эти же службы реже всего оказываются причиной проблем, а основная причина — это просто наш сервис перегружен, потому что у нас кривая архитектура.

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

То есть то, с чем справляется ось без докера :)

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

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

Вопрос сводится к «как быстро я смогу перенести терабайты данных со старого сервера на новый». Фанаты микросервисов почему-то строят свои повествования так, будто терабайты NVMe хранилищ ничего не стоят и спокойно переносятся между датацентрами. А нужны будет терабайты, потому что микросервисы подразумевают безсхемовое сохранение исходных данных, поскольку миграция данных при обновлении системы идет вразрез идеологии, а значит при обновлении будет меняться только отображение данных, которое будет строиться с нуля при каждом новом запросе.

Вы уже чувствуете, какая «простая» система у нас получается, как много проблем мы «решили» при помощи кубернета?

Конечно, а еще он не умеет картошку чистить. Ужасная и бессмысленная технология :)

Уже незачем, ведь такой велосипед давно создан и активно здесь обсуждается.

Надо будет причесать код немножко и выложить куда-нибудь. Все равно в таком виде он уже наверняка не используется никем.

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

В inventory были группы prod, stage и dev, и в каждой группе были условные «хосты», то есть собственно сами облака.

То есть по сути ansible использовался как шаблонизатор для рендеринга hcl-файла, который потом заливался на nomad через nomad api соответствующего кластера.

Ну и поскольку hcl этот у самого nomad очень бедный и ничего не умеет, на ansible было сильно проще создавать некоторые абстракции, и потом выкатывать 20 разных жабо-приложений одним и тем же способом но с разными параметрами.

А за счет восприятия облака как одного сервера в ansible можно было пользоваться всей мощью встроенных механизмов работы с переменными.

Дык хранилище и инстанс мускуля это разные сущности, не?

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

заказчику просто очень хочется почувствовать себя гуглом

А, то есть ты как минимум на треть со мной согласен!

Я на 100% с тобой согласен, но я хотел услышать мнение другого человека. Вдруг я сошел с ума и один во всем мире это вижу. С другой стороны, может быть ты сам являешься моим глюком, и на самом деле такого пользователя на LOR не существует.

У меня такое ощущение что ты дальше LAMP в разработке не продвинулся, при этом зачем-то пытаешься выдать свой личный опыт за «всех», «большинство» и «типовые системы».

Для LAMP облака не нужны, кубернетесы тем более, всё верно. Если твои заказчики ничего кроме LAMP не просят, а ты им ничего кроме LAMP не предлагаешь - у вас всё хорошо. Мир прост и понятен.

Для LAMP облака не нужны, кубернетесы тем более, всё верно. Если твои заказчики ничего кроме LAMP не просят, а ты им ничего кроме LAMP не предлагаешь - у вас всё хорошо. Мир прост и понятен

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

Вопрос сводится к «как быстро я смогу перенести терабайты данных со старого сервера на новый».

Прямо терабайты на любой сервис? И обязательно там же, где и само приложение? Но зачем?

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

Три раза прочитал, так и не понял. Микросервисы да, бывают stateless и да, они берут информацию из db в момент обращения к ним. Что такое «бессхемовое сохранение» не очень понятно. Дамп памяти? Серьезно? А миграция какая имеется в виду? Копирование или изменение структуры?
Если миграция = копирование, то да. Часто это очень затратно и применяются другие механизмы - чаще репликация.
И вот что же это за данные такие, для получения которых (при обновлении) мне нужны терабайтные базы данных вот прямо всегда мне не представить. Даже аналитика с биг датой по-другому работает, а тут какие-то микросервисы.
Тем, кому действительно нужны терабайтные базы для сервиса знают как их хранить, кэшировать, бэкапить и резервировать. Для всех остальных есть ttl.

Ну я о тупом сценарии. Блочное устройство с данными подключено по сети. Это не обязательно сетевая ФС, допустим что их у нас по числу инстансов плюс репликация. При пересоздании инстанса БД устройство монтируется в новый инстанс и поехали дальше, не надо ничего копировать.

Вдруг я сошел с ума и один во всем мире это вижу. С другой стороны, может быть ты сам являешься моим глюком, и на самом деле такого пользователя на LOR не существует.

Т.е. с другой стороны ты опять же сошел с ума. Чот ты совсем не оставляешь себе выбора, не надо так.

То есть по сути ansible использовался как шаблонизатор для рендеринга hcl-файла, который потом заливался на nomad через nomad api соответствующего кластера.

Оркестрировать оркестратор. Ужас какой. Нет, понятно, что jinja кажется более вменяемой, что consul-templates, но блин.
fyi: и на самом nomad умеет не только в host network, а еще и bridge, docker network и еще как-то. Host network я бы сказал, что самая нестандартная конфигурация, так как там большинство вкусных плюшек nomad'а не работают. А тот же consul умеет dns-ом прикидываться и нормально резолвить зарегистрированные nomad'ом сервисы. Так что «искать» перезапущенный сервис точно не надо.

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

«Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус… Но зачем?»

Зачем? У тебя одна точка отказа — это сетевое хранилище. Более того, теперь до него еще и дольше бегать, чем до локалхоста.

У тебя одна точка отказа — это сетевое хранилище.

Она не одна и она не у меня, я хз вообще как оно там в дц организовано. Они мамой клянутся что избыточно и надежно.

Зачем?

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

до него еще и дольше бегать, чем до локалхоста

Предположим, что мы не НАСТОЛЬКО хаёвый хайлоад.

Прямо терабайты на любой сервис? И обязательно там же, где и само приложение? Но зачем?

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

Например, какой смысл от того, что ты можешь быстро развернуть LOR на новом сервере, если в этом новолоре не будет никакого контента вообще? В том числе профилей пользователей.

Что такое «бессхемовое сохранение» не очень понятно. Дамп памяти?

JSON.

А миграция какая имеется в виду? Копирование или изменение структуры?

В самом простом варианте

ALTER tablename ADD columnname constraintname

Или посложнее: Немного отстал от жизни, что за notify? (комментарий)

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

Как это «по-другому»? Кликхауз можешь за пару секунд развернуть на новом сервере со всеми данными за два года год?

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

Я сейчас в замешательстве. Я не знаю, что это за бизнесы такие, которые регулярно безвозвратно выносят все данные о своей работе на мусорник.

Оркестрировать оркестратор. Ужас какой. Нет, понятно, что jinja кажется более вменяемой, что consul-templates, но блин.

Дело не в языке шаблонов, а именно в структуре переменных.

Я вообще считаю что это сильно недооценненный момент в Ansible и о нём мало говорят.

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

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

А тот же consul умеет dns-ом прикидываться и нормально резолвить зарегистрированные nomad’ом сервисы.

Умеет, если настроить. А для этого необходимо согласование между конфигами nomad и настройками consul. И например разделение обязанностей, как в k8s, где админы админят кластер, а разработчики разворачивают свои сервисы уже не срабатывает. Потому что consul тоже админят админы, а тебе надо там постоянного что-то там допиливать с каждым новым приложением.

Вас не в ту степь заносит. Всё, что нужно сервису — это получить точку подключения куда писать-читать. При этом, что скрывается за endpoint’ом — одинокий под в том же кластере или супер-дупер HA кластер, убравляемый бородатыми DBA его не интересует.

Она не одна и она не у меня, я хз вообще как оно там в дц организовано. Они мамой клянутся что избыточно и надежно

Масштабируемые ФС стоят дорого, намного дороже облак, дешевле брать реплицированный-шардированный мускуль.

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

Это как вешать бельё сушиться на цепи из золота 985 пробы. Распределенная ФС — это уже сама по себе БД, не проще мускуля.

Всё, что нужно сервису — это получить точку подключения куда писать-читать

А система никаких прикладных задач не выполняет (охотно поверю) или же нас задачи волновать не должны? «Нам главное день продержаться, да в эндпоинт записать». «Работаю за эндпоинты».

Не понял вопроса.

Умеет, если настроить. А для этого необходимо согласование между конфигами nomad и настройками consul

Nomad без consul'а скорее всего и не используется нигде. А настройка заключается только в том, чтобы сгенерировать token в consul'e и прописать его (и хотя бы один инстанс) в конфиге nomad'а. Вообще не rocket science. Все остальное делается уже в job'ах самого nomad'а.

Не понял вопроса

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

Кто хранит эту информацию?

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

Например, какой смысл от того, что ты можешь быстро развернуть LOR на новом сервере, если в этом новолоре не будет никакого контента вообще? В том числе профилей пользователей.

Странный ты. Во-первых контента на lor'е вряд-ли терабайты. И тебе выше несколько человек рассказывают, что есть репликации, proxy, что монтировать готовые вольюмы можешь, а ты все уперся - давайте полностью копировать все данные каждый раз при перезагрузке сервиса.

ALTER tablename ADD columnname constraintname

Нахрена мне alter table, если у меня json?

Как это «по-другому»? Кликхауз можешь за пару секунд развернуть на новом сервере со всеми данными за два года год?

Да, могу. ClickHouse умеет в s3 данные хранить.
Видимо специально для таких странных кейсов.

Я сейчас в замешательстве. Я не знаю, что это за бизнесы такие, которые регулярно безвозвратно выносят все данные о своей работе на мусорник.

Кроме lamp'а есть огромный удивительный мир, где аналитические и архивные базы живут отдельно от баз, которые используются для обмена данными между stateless worker'ами.
И где знают что такое бэкапы...

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

Какая еще «зона ответственности»? Что это за зона ответственности такая, в которой нет сохраняемой информации? Даже для отладки и контроля системы нужно хранить логи. Вынося сохранение информация из контейнера ты не столько решил проблему, сколько создал новую проблему «где хранить данные для микросервиса?». Пацаны, го решать проблемы, я создал!

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

А без контейнера и микросервисов такой проблемы нет?

что суть всех микросервисов сводится к перекладыванию нагрузки с логики на БД

А ты в этом уверен? И ты правда понимаешь что значит этот термин «микросервис»?
И я могу пример попросить для подтверждения этого «тезиса»?

по поводу субд в докере https://habr.com/ru/post/578744/ второй абзац

правильно и если сервис развивается, то постоянно его надо обновлять + приходится обновлять другие компоненты (например библиотеки так как в них что-то очень вкусное для разработчиков появилось)?

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

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

В случае с apt: добавляем репозиторий в sources.list, добавляем куда-то там ключ подписи, apt-get update, apt-get install -y task-our-project

докер даст возможность этому сервису выжрать не больше чем ему выделено.

Так сервис то будет работать или нет? Железка сама по себе (пусть и с работающим sshd) никому не нужна, нужен сервис для которого её поставили.

И тебе выше несколько человек рассказывают, что есть репликации

Реплицированная БД — это глубоко statefull сервис, его нельзя просто создать на новом сервере, он должен быть заранее создан.

что монтировать готовые вольюмы можешь

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

Нахрена мне alter table, если у меня json?

Внезапно, постгря умеет и то, и другое.

ClickHouse умеет в s3 данные хранить.
Видимо специально для таких странных кейсов

Хм-м-м, а а яндексе интересные ребята сидят — в кликхаузе есть интеграция с вообще всеми популярными БД. Правда, проблему передачи терабайтных баз по сети S3 не решает.

Кроме lamp'а есть огромный удивительный мир, где аналитические и архивные базы живут отдельно от баз, которые используются для обмена данными между stateless worker'ами

Кто-то запрещает создать две базы мускуля?

что суть всех микросервисов сводится к перекладыванию нагрузки с логики на БД

А ты в этом уверен? И ты правда понимаешь что значит этот термин «микросервис»?
И я могу пример попросить для подтверждения этого «тезиса»?

Можешь. Никсовый баш. Перекладывает геморрой на ФС, так же неэффективен в межсервисовом взаимодействии.

но приведу в пример пакетные менеджеры от линукс-дистров - изобретены задолго до докеров и прекрасно справляются с задачей.

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

Так сервис то будет работать или нет?

Да откуда я знаю. Зависит от того как ты его написал.

Железка сама по себе (пусть и с работающим sshd) никому не нужна, нужен сервис для которого её поставили.

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

Какой еще баш? Где пример, что монолит сам все делает, а переделали на микросервисы и стала за всех отдуваться db?

Кто-то запрещает создать две базы мускуля?

Блин, ну вылезай уже из своего подвала. Существуют не только php и mysql. И задачи у stateless сервисов бывают совершенно разные. И никто не запретит тебе совмещать базы данных со stateless worker'ами. И никто не запрещает тебе хранить базы на дисках, если это требуется.

Правда, проблему передачи терабайтных баз по сети S3 не решает.

Нахрена тебе гонять терабайтные данные по сети? Ну хоть один пример зачем это надо?

Какой еще баш? Где пример, что монолит сам все делает, а переделали на микросервисы и стала за всех отдуваться db?

Давай так: где хотя бы один пример проекта, который был монолитом, а стал микросервисоми? Не потому, что у соцсетки стал миллиард пользователей (и то у них не микросервисы), а потому, что микросервисы — это модно, молодежно, прогрессивно, просто, и эффективно. То есть, чтобы сэкономить на разработке. Как правило, переход на распределенность-масштабируемость сопровождает большим скачком в затратах на разработку и эксплуатацию. Я могу привести пример разве что одноклассников, и они на своих 10-15 млн пользователей страдают за весь фейсбук, если судить по их статьям на хабре — у них какие-то фантастические цифры в десятки миллиардов записей в таблицах, которые непонятно откуда и зачем взялись.

Нахрена тебе гонять терабайтные данные по сети? Ну хоть один пример зачем это надо?

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