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

у 99% мужчин есть член

1% от ~4 млрд — это примерно 40 миллионов. Урежь леща-то.

Это борьба с утечками памяти, штоле?

Это борьба с потерей данных при перезагрузке сервиса

это какая-то бессмысленная вода уровня аджайл-манифеста.

Аджайл то тебе чем не угодил?

Порядка сотни тыщ строк записей в секунду.

Ну ну.

итогу упираются в одну и ту же БД

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

которые нынче принятой примитивной готовой инфраструктурой логирования и оркестрации не решаются никак.

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

А не как в реальности: херак-херак и в прод... не работает? Лепим костыль... падает? Перезапускаем по таймауту.

В какой дикой реальности ты живешь. Соболезную

с таким пафосом

кстати да, вот это особенно отталкивает в дебилах.

чужие давно известные копеечные «идеи» + глупости перемешиваются и подаются так, словно «демократию» туземцам несут.

но это общее место для индустрии: «светилы» с хакер-ньюс и васяны с ооо ромашка c одинаковым апломбом и пафосом свои «озарения» доносят.

Потом начинаются кэши

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

если в проект внедрили кеш - то всё, это тотальное кривое говно сделанное дебилами.

я уже не говорю про то, что десятилетия сильнейшие умы боролись за согласованность состояния в пределах одной БД, за одновременное исполнение SQL транзакций, за доказательства [не]сериализуемости. разрабатывали технологии под это, блокировочные, версионные, гибридные, уточняли формальные определения. разработали системы, которые реально работают и корректно обслуживают запросы в замысловатых сценариях одновременного доступа. и тут приходят микросервис-даунята и кеш-даунята. причем даунятам может быть и 40 и 50 и сколько угодно лет. через 15 лет с чудовищным пафосом они изобретут блокировки, причем максимум возможного в их системах наверное будет read committed.

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

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

то есть вещь та же самая, но была как бы добром, а стала совсем злом. а ведь 99% внедрений именно такие - «сейчас же все используют, зачем нам 'устаревшее'»

А потом начинаются претензии «откуда ты взял, что микросервисы приводят к раздуванию БД на ровном месте».

Во-первых, следует напомнить, что докер и микросервисная архитектура, это 4 совершенно разных человека. Во-вторых, логгируются запросы от заказчиков. Много запросов — много логов. Причём от того, как нарезать обрабатывающую систему: одним ли куском или на мелкие покрошить, количество работы не изменяется.

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

Ничего не понял.

Ну как бы «растянутые в пять раз сроки и бюджет» — это, наверное, не совсем прекрасно, да?

А чем вы подтвердите эти цифры?

У взрослых людей для трассировки запросов в распределённых системах применяются специальные инструменты. Например, https://www.jaegertracing.io/.

У вас есть конкретная готовая инфраструктура — это ж замечательно. У Васи Пупкина её нету, и потому …

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

чтобы в it могли «работать» макаки за банан.

Я не то чтоб обладаю какой-то реальной статистикой, но по личным впечатлениям (всё ж таки 10 лет в профессии) освоившие докер-кубернетес-авс зарабатывают существенно так по-больше, нежели остановившиеся на уровне lamp-bash-свитер с оленями.

Полночь, суббота, выходные, перехожу на тёмную сторону силы.

Аджайл то тебе чем не угодил?

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

Я работал в компаниях, где agile (scrum конкретно) отлично работает и дает потрясающий результат + видел еще несколько со стороны, но это все gamedev

Тут бы для начала выяснить что вы лично называете аджайлом и что наызваете потрясающим результатом.

Кстати, а правда, что gamedev — это помойка, куда идут школьники, которые вообще в IT шли, чтобы написать свою игру, им там платят меньше рынка, заставляют перерабатывать (потому как разработать новый дум или квейк — большая честь), а когда они выгорят или поумнеют, их выкидывают и заменяют новыми? Я сам в геймдеве не работал, но мнение такое слышал неоднократно.

Это борьба с утечками памяти, штоле?

С неконтролируемым раздуванием пространства состояний. Которое мешает пониманию происходящего и воспроизводимости поведения.

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

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

Я вынужден согласиться с ugoday про «запуск в контейнере не отличается от запуска без контейнера» — но немножко в другом смысле. В том, что для бизнеса нет разницы, будешь ли ты одиночный сервер настраивать руками в родном окружении или в контейнерном — и там и там есть логирование, и там и там придется настраивать и админить. Применение докера, Nix, или какого-то экзотического пакетного манагера — это всё имеет минимальный эффект на конечный результат. Есть пакет для докера? Берешь пакет для докера.

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

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

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

Возвращаясь к закону тривиальности: вопросы мироксервисов и контейнеров вообще не должны были появляться на радаре, они, по большей части, не так значимы. как грамотной проектирование и реализация, как подбор кадров для этой работы. Но грамотно проектирвоать и подбирать сотрудников умеют единицы, а лепить микросервисы куда попало, писать тесты горами, рассказывать про принципы SOLID, DRY, и писать бинарные деревья (даже если ты верстальщик) — миллионы. И потому конец немного предсказуем — популярным оказывает то, что помогает делать вид, то есть, работать, а не выполнять задачу и достигать цели.

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

Гугл в треде — всем укрыться в BigTable

Манявр защитан

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

Это борьба с потерей данных при перезагрузке сервиса

Внимание, вопрос: так кто же сохраняет данные при перезагрузке сервиса? Я как бы полтреда об этом и талдычу. Собственно, микросервис тут толком ничего и не делает.

Аджайл то тебе чем не угодил?

Бессмысленностью и водянистотью. Что есть, то есть, зачем называть черное белым? Хочешь покакать — идешь в туалет, нужно что-то конкретное — смотри не аджайл манифест.

Порядка сотни тыщ строк записей в секунду.

Ну ну

Баранки гну. Даже при отдельных транзакциях у NVMe имеется сотни тыщ IOps, которые способны приближать к одной сотне тыщ. Это все-таки сотня тысяч циклов процессора на запись — более чем достаточно на все прерывания и переключения контекста.

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

Ага, то есть, я «ухожу от ответа», а твои ссылки к абстрактным левым сайтам — это самый что ни на есть конкретный ответ по теме, да?

которые нынче принятой примитивной готовой инфраструктурой логирования и оркестрации не решаются никак.

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

Вообще-то я тебе привел пример варниша — типовой высоконагруженной софтиной с продвинутым логированием.

через 15 лет с чудовищным пафосом они изобретут блокировки, причем максимум возможного в их системах наверное будет read committed

Справедливости ради — максимальный высокопроизводительный уровень изоляции для распределенной БД находится между snapshot и read committed. То есть, такой-себе sloppy snapshot isolation, которое представляет из себя набор снимокв для каждого отдельного сервера, где между снимка действует read committed, а внутри одного снимка — snapshot, очевидно. Но пытаться лочить сервера — это значит терять всю распределенность и производительность, потому между серверами возможен только read committed.

Во-первых, следует напомнить, что докер и микросервисная архитектура, это 4 совершенно разных человека. Во-вторых, логгируются запросы от заказчиков. Много запросов — много логов. Причём от того, как нарезать обрабатывающую систему: одним ли куском или на мелкие покрошить, количество работы не изменяется

У тебя будто слепое пятно на месте распределенных логов. Map-reduce суещствует десятки лет, и применим не только для логов. В индустрии доминирует какая-то маникакальная одержимость централизацией, причем, эта централизация почему-то называется «распределенная система». Например, раскидать БД по датацентрам, но чтобы во всех экземплярах БД были идеально одинаковые данные. Есть много логов на разных компах — кидаем все логи в один узел обработки логов, который потом придется делить на шарды, потому что в один узел все логи не влазят. Зачем изначально было жестко централизировать это логирование? Тебе нужна телеметрия, которая показывала бы, что узел жив? Ну так меряй именно ее.

Проблема-то не в централизованном мониторинге, а в том, что этот мониторинг используют совсем не по назначению.

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

Ничего не понял

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

А чем вы подтвердите эти цифры?

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

У взрослых людей для трассировки запросов в распределённых системах применяются специальные инструменты. Например, https://www.jaegertracing.io/

Сорян, не тыкал эту штуку. Но сами разрабы ее прямо пишут:

«It is simply an orders of magnitude larger problem to network and debug a set of intertwined distributed services versus a single monolithic application.»

Я постом выше уже ответил, что это всё проблемы, которых просто не существует, когда у тебя не распределенная система:

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

по личным впечатлениям (всё ж таки 10 лет в профессии) освоившие докер-кубернетес-авс зарабатывают существенно так по-больше, нежели остановившиеся на уровне lamp-bash-свитер с оленями

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

Пеерходя к бизнесу: есть люди, которые выполняют ту же роль «создать видимость результатов», которые вообще не умеют ни в кодинг, ни в админство (Маск, Джобс, etc), и при этом весьма успешно сдают проекты. То есть, к технологиям это вообще не имеет отношения.

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

Сейчас — да. В начале нулевых — совсем нет.

Кстати, а правда, что gamedev — это помойка, куда идут школьники, которые вообще в IT шли, чтобы написать свою игру, им там платят меньше рынка,

Нет, это неправда. Игры - это один из самых конкурентных рынков. У тебя тысячи конкурентов, а тебе надо, чтобы пользователи пришли к тебе и оставались (я про online игры). Там не место школьникам. На самом деле в gamedev'е очень приличные зарплаты, потрясающие условия труда и вообще очень кайфово.

многократное растягивание сроков на элементарных проектах имеет место.

Это если менеджмент неквалифицированный. У них и agile не работает. Очень многие люди, которые из программистов стали менеджерами не хотят осваивать свою новую профессию. То есть если ты хочешь работать программистом, то тебе надо изучить семантику языка, алгоритмы, паттерны. А вот если тебя назначили начальником, то почему-то нет понимания, что нужно учиться руководить.

что наызваете потрясающим результатом

Когда все делается в срок. Без всяких авралов и переработки.
Я писал выше, что квалифицированных руководителей очень мало. Так как, заняв должность руководителя, люди даже не думают, что это тоже профессия и ей надо учиться. А неквалифицированному менеджменту никакой agile не поможет. Они его даже внедрить не смогут.

Это все-таки сотня тысяч циклов процессора на запись — более чем достаточно на все прерывания и переключения контекста.

Давай так.
1. У тебя нет даже близко похожей нагрузки. Так что я не понимаю, как ты об этом с такой уверенностью говоришь. Ты проверь. Залей свой бэкап и посчитай. Раздели время на строки.
2. У тебя всё-таки база данных. Причем с транзакциями, бинарным логом, индексами и ключами. И блокировками.
3. Если бы такие скорости были у mysql никто бы не писал тот же, упомянутый выше ClickHouse, у которого ради быстрых инсертов пожертвовали update'ами и delete'ами - их там просто нет.

ты где украл тыщу хостов.

Тысяча хостов приблизительно 50000 - 100000 евро в месяц, если компания зарабатывает хотя бы миллион в месяц, то это не так дорого. Не понимаю твоей зависти.

Внимание, вопрос: так кто же сохраняет данные при перезагрузке сервиса?

Так внешнее (по отношению к сервису) хранилище же. Смысл в том, чтобы сервис не хранил никакого состояния у себя, мимо хранилища.

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

И не должен.

ты где украл тыщу хостов

При чем тут я-то, если у меня нет тыщи хостов, это не значит, что ни у кого нет.

Например, раскидать БД по датацентрам, но чтобы во всех экземплярах БД были идеально одинаковые данные

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

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

Ты еще и экономист до кучи.

Аджайла не существует. По крайней мере я ни разу не видел.

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

https://github.com/datacharmer/test_db

[user/test_db-master] $ sudo mysql < employees.sql    
INFO
CREATING DATABASE STRUCTURE
INFO
storage engine: InnoDB
...
LOADING salaries
data_load_time_diff
00:00:18
[user/test_db-master] $ wc -l load_salaries*
   967330 load_salaries1.dump
   946986 load_salaries2.dump
   929732 load_salaries3.dump
  2844048 total

Это на SATA III SSD. 150 тыс записей в секунду. Да, на миллиардах записей этот показатель просядет, но — это десктопный комп и десктопный диск.

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

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

У тебя всё-таки база данных. Причем с транзакциями, бинарным логом, индексами и ключами. И блокировками

Выше БД со всеми ключами, если чо. Внешний ключ приводит к генерации индекса.

Если бы такие скорости были у mysql никто бы не писал тот же, упомянутый выше ClickHouse, у которого ради быстрых инсертов пожертвовали update'ами и delete'ами - их там просто нет

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

mysql < employees.sql

А почему ты заливаешь employeers.sql, а считаешь какие-то другие файлы?

Применение докера, Nix, или какого-то экзотического пакетного манагера — это всё имеет минимальный эффект на конечный результат. Есть пакет для докера? Берешь пакет для докера.

Я согласен с этим в техническом смысле (более того Guix мне нравится больше всего), но не согласен в социальном. Вот, представьте себе, у вас есть небольшая фирма, в ней 20 программистов и все пишут на java. Маячит на горизонте новый проект, в котором ява будет не лучшим выбором, а вот перл, наоборот, подходит идеально. Но перл-программистов у вас нет, яванские человеки перл не знают и знать не хотят. Держать отдельную команду перловиков, так это их нанимать надо (а у вас, кстати, нет никого, кто умеет нанимать перловиков), а потом менеджерить отдельно. А проект может и не взлетит и что потом с этим делать? На оутсорс как-то непонятно как отдавать, с фрилансерами у вас опыта нет и т.д. и т.п. В этих условиях имеет смысл тупо писать проект на яве, потому что небольшие технические преимущества альтернативы не оправдывают весь сопутствующий ей геморрой.

Так же и тут, докер — это удачная технология, которая взлетела и теперь все его знают и умеют с ним работать. Знают посредственно, но этого достаточно. Можно брать любого среднего админа или кодера и докер не будет для них сюрпризом. В крайнем случае в интернете статейки почитают, благо что их там херова туча. А вот если б я продавил использование guix environments, то мне пришлось бы объяснять каждому новому сотруднику что это такое и как с ним работать, основы scheme и как emacs+geiser настраивать, чтоб комфортно было. А оно мне надо со всеми няньчиться? А оно им надо вкладываться в технологию, которую нигде больше не используют? Вот так и живём.

микросервис тут толком ничего и не делает.

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

Кажется, я стал забывать русский язык. Судя по контексту и общему тону, здесь:

в качестве разрабов нанимают макак за банан, а деньги тратят на девопса

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

Когда все делается в срок.

Просто инетересно, а не по agile вы когда-либо работали?

Поэтому все книжки по …

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

А всё же хотелось понять в чём вы видите альтернативу? Пока что выглядит как хранить логи сервера на нём же. Но тогда, в случае смерти и недоступности оного сервера без астропата не понять что же с ним случилось и как так вышло. Значит логи сервера нужно пересылать куда-то ещё. Вот это куда-то ещё и есть ELK или нечто подобное.

Если у тебя один сервис создает все запросы к БД

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

Есть проблема, есть решение, все довольны. Гораздо хуже, когда проблема есть, а решения нету. Вот, например, в основном продукте моей конторы есть компонент, который может присутствовать только в одном экземпляере. Его уже пытались переписать (возможно дважды), но воз и ныне там. Эта хреновина адово тормозит. Хотелось бы создать десять её экземпляров, чтобы она тормозила в десять раз меньше. Вы, конечно, уже готовы сказать, что надо меньше говнокодить и я с этим согласен, надо. Но за прошлые 10 лет это исправить не смогли. А значит скорее всего и за следующие 10 лет не исправят. А жить с этой болью как-то надо.

вы смешали в кучу контейнеры, оркестрацию, микросервисную архитектуру и облачные технологии

Приправив все это ведром жопной боли. Ну это как водится.

эффекта от докера нет, эффект от микросервисов отрицательный

Все вокруг дебилы и ложку в ухо тащат, один ты в белом худи стоишь скромный и красивый %)

У вас инфраструктура заточена под контейнеры? У нас инфраструктура заточена под башекостыли

Сектор Газа - Опарыш.мп3

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

Грамотность, конечно, важна, спору нет. Причем как в разработке, так и в эксплуатации. Но при чем тут стандартизация и облегчение эксплуатации, которые делает возможным виртуализация (особенно контейнеры)? От недостатка страданий админы станут ленивыми, глупыми и неграмотными или что? Как в той недалекой байке про тяжелые времена, которые якобы создают сильных людей и так далее?

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