Микросервисы — отчуждение от результатов труда

habr.com — взгляд на микросервисы с марксистской точки зрения. Вся статья очень большая, с огромным вступлением, поэтому в коммент скопирую только фрагмент "по делу". Полная статья по ссылке.
Новости, Политика | Soloqub 12:13 18.01.2023
6 комментариев | 104 за, 4 против |
#1 | 12:13 18.01.2023 | Кому: Всем
В общем, у меня долго не получалось найти рациональное объяснение происходящему, но однажды мне его буквально на пальцах растолковал... один из технических топ-менеджеров Яндекс.Такси, где я когда-то работал. История эта уже древняя, потому, думаю, вполне можно рассказать, никого не задев.

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

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

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

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

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

Но вот беда — просадки не случилось! Месяц закончился, и вообще ни одна бизнес-метрика не пострадала: наняли ровно столько же, сколько в предыдущем.

Видя это, бизнес, разумеется, задался вопросом: "А стоит ли вообще каждый раз впихивать в этот найм по миллиарду? Может быть, и двухсот миллионов достаточно?"

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

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

В общем, чтобы выполнить нужные замеры и подсчёты, я решил взять любую базу данных (например, PostgreSQL) и записывать в неё происходящие события вместе с идентификаторами (будущих) водителей, операторов и т.п. Подождав месячишко, пока накопится статистика, я планировал поделать из неё выборки, отвечающие на вопросы бизнеса.

Просто же всё? И вот пришёл я с этим "просто" к тому самому топу.

— Здесь достаточно одного программиста, — начал я, — он за день (ну, хорошо, округлим до недели) сделает функцию, записывающую событие в БД. Большого количества полей в записях не требуется: тип, время, связь с нанимаемым водителем и связь с исполнителем. В общем, работа очень простая, могу даже сам запилить: тут строк пятьдесят кода. Затем, — продолжил я, — мы обойдём все формы и бакенд, добавляя http-запросы, генерирующие это событие, — и вуаля! В конце следующего месяца отчёт готов!
— Не пойдёт.
— Почему?
— Вы не сможете получить разрешение на размещение такого проекта на площадке Яндекса.
— А что тут не так?
— У нас регламент. Например, база данных должна работать в трёх датацентрах.
— Хорошо, запрос к эксплуатации будем делать на постгрис с синхронной репликацией. Что ещё?
— Вы не пройдёте техаудит.
— Что же тут аудировать? Пятьдесят строк кода! Пройдём!
— Нет, — снова повторил он, — то, что ты предлагаешь — ни разу не микросервис. А по регламенту должен быть именно он.
— Хгм... — озадачился я. — А ведь и инфраструктура, которую мы хотим обложить метриками, — не микросервисная.
— Ну и что? Получать ресурсы (БД, деплой) ты будешь для нового проекта, так? Значит, он обязан быть микросервисом, иначе ничего тебе не выдадут.
— Слушай! — попытался я воззвать к его сознательности, — посмотри на бизнес, там ведь все бегают как ужаленные и кипятком во все стороны писают! Речь идёт о судьбе, ни много ни мало, а миллиарда в месяц! Какая разница, микросервис или не микросервис? Давай максимально быстро дадим ответы на поставленные вопросы, а потом будем хоть до пенсии переписывать в спокойном режиме, приводя в соответствие к требованиям регламента?
— Нет, мы не станем так делать! — обломал меня он.
— А как?
— Мы реорганизуем (расширим) отдел. В него войдёт десять-двенадцать разработчиков, они напишут нужные микросервисы. Здесь я вижу что-то около десяти микросервисов.

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

— Но бизнес же ежемесячно, возможно, теряет до миллиарда!
— Нас не волнуют проблемы бизнеса. Соблюдение регламентов гораздо важнее!
— А в чём ценность этих регламентов, если за них приходится столько платить?
— Разве много? — удивился он.
— Один человеко-месяц (ограничение сверху) размениваем на двадцать четыре человеко-года (ограничение снизу) плюс, эээ..., двадцать миллиардов потерь за время разработки...
— Ну и что? — задал он вопрос, поставивший меня в тупик.

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

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

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

Технически (именно технически) микросервисы — совершенно бессмысленная вещь.
Микросервисы, например, — не способ масштабировать нагрузку: stateless программы легко масштабируются простым добавлением копий, а масштабирование statefull всегда происходит там, где хранятся данные.

Можно даже сформулировать правило:
С технической точки зрения (производительность, количество кода и т.п.), микросервис всегда может быть замещён обычным кодом, и это действие приведёт к тому, что накладные расходы упадут, а эффективность вырастет.
Однако зачем их используют, для чего вводят такие регламенты?
— Видишь этих людей? — ответил он мне, показывая страничку одного из подчинённых ему отделов на staff, — здесь, например, их сейчас сто пятьдесят. Все они работают в одной парадигме — пишут микросервисы — причём значительную часть работы вообще делает кодогенератор.
Знаешь, в чём ценность подобного подхода?
— В чём? — переспросил я.
— Во-первых, я могу уволить половину или даже вообще всех, заместив их совершенно новыми людьми с улицы. От этого не случится никакого ущерба.

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

Осмысление

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

Это даже не разделение труда, которое предавал анафеме Жан-Жак Руссо, — это самое натуральное отчуждение от результатов труда по Карлу Марксу!
Ни больше ни меньше!

Отчуждение рабочего в его продукте имеет не только то значение, что его труд становится предметом, приобретает внешнее существование, но ещё и то значение, что его труд существует вне его, независимо от него, как нечто чужое для него, и что этот труд становится противостоящей ему самостоятельной силой; что жизнь, сообщённая им предмету, выступает против него как враждебная и чуждая.
© Карл Маркс

Итак, рассмотрим среднестатистического разработчика Яндекс.Такси. Нанимаясь, он прошёл десяток-другой собеседований и попал, наконец, на вожделенную должность. А что дальше? А дальше над ним висит регламент: "только микросервис". И даже больше — "на 80% кодогенерируемый микросервис".

Что такое микросервис, значительная часть которого кодогенерируется? Это способ изолировать разработчика от целого (и друг от друга). Это жёсткий контракт в YAML-файлах: "На входе требуется вот это, а на выходе вот то, приступай!". И даже внутри оставшихся двадцати процентов свобода творчества самым садистским образом ограничена: цензурируется шестью с половиной линтерами!

Поскольку человек — существо разумное, ему присуща потребность самовыражения. И раз она настолько серьёзно ограничена внешними рамками, то неудивительно, что он:
Перманентно пребывает в демотивированном состоянии (отсюда столь низкая производительность: 24 человеко-года, против одного человеко-месяца).
Пытается искать ей иное приложение, пытаясь, например, оптимизировать или улучшить то, что не нужно.
Фрагментарно мыслит (ведь оперирует он именно фрагментами).

В Яндексе есть прекрасный внутренний ресурс (ЯЧан), где можно писать анонимно. Так вот, там эти самые "винтики большой машины" говорят о себе: "Я работаю перекладывателем JSON'ов!"

Шутка? Да, но в каждой шутке всего лишь доля шутки...

А дальше?

Сравнительно длительное время именно в IT мире наблюдалась уникальнейшая (по сравнению с другими отраслями) ситуация: наёмные рабочие имели доступ к средствам производства и в любой момент могли, используя их, прокатиться вверх на социальном лифте.

А что? Всё, что тебе нужно, — компьютер и немножко терпения. Идея же сгодится практически любая, просто сделай качественно!
Однако постепенно такие возможности закрываются и далее будут закрываться ещё агрессивнее. По мере роста отчуждения труд разработчиков будет всё сильнее дешеветь, пока из нынешних хипстеров не получатся настоящие пролетарии.
Уже сейчас бизнес нацелен на радикальное снижение уровня квалификации среднестатистического разработчика, на работника с максимально фрагментированным мышлением (чтобы не пытался, поднимаясь по социальным лифтам, составлять конкуренцию).

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

В итоге весь этот деструктив доводит до того, что некоторые уже добровольно устанавливают на свой IDE не только линтеры, контролирующие количество пустых строк, но и форматеры кода!

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

Что делать?

Научно-технический прогресс понемногу приводит нас к тому, что именно мы — IT'шники — станем тем рабочим классом, которому придётся ломать систему эксплуатации человека человеком. И делать это придётся, преодолевая уныние и внутреннее лакейское нежелание что-либо менять.

Путь борьбы требует значительных психологических ресурсов, и самое трудное — преодоление собственного нежелания плыть против течения. Хоть это давно описано многими классиками11, но отклик находит лишь у немногих.
...Но иногда некоторые из них говорили что-то неслыханное в слободке. С ними не спорили, но слушали их странные речи недоверчиво. Эти речи у одних возбуждали слепое раздражение, у других смутную тревогу, третьих беспокоила легкая тень надежды на что-то неясное, и они начинали больше пить, чтобы изгнать ненужную, мешающую тревогу.
© Максим Горький.

Именно нам, IT'шникам, необходимо как можно быстрее превозмочь коллективный отказ от борьбы — иначе, как говорил великий американский писатель, железная пята математически непреложна.

—- Тогда, и вы, и мы, и весь рабочий класс будем раздавлены железной пятой деспотизма, не ведающего удержу и жалости, —- деспотизма, какого не знала доселе ни одна, даже самая тёмная эпоха в жизни человечества. Вот имя для него —- Железная пята!
© Джек Лондон

Начал главу "Что делать?", а о том, что делать, так пока ничего и не сказал. Исправляюсь.
Итак, бороться! А борьба наша начинается прежде всего с воплощения Ленинского завета: "Учиться, учиться и ещё раз учиться"13.
...среди рабочих выделяются настоящие герои, которые —- несмотря на безобразную обстановку своей жизни, несмотря на отупляющую каторжную работу на фабрике, —- находят в себе столько характера и силы воли, чтобы учиться, учиться и учиться, и вырабатывать из себя сознательных социал-демократов...
© В.И. Ленин

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

Боритесь! Отказывайтесь от вакансий, где вам предлагают работать над микросервисами. Встречно предлагайте монолитные приложения!

Удалите из своего IDE форматирующие код расширения, уничтожьте линтеры, верифицирующие стиль, оставьте только те, что дают информацию о возможных ошибках. Заставьте творца, который живёт внутри, выйти на первый план!

Хороший кандидат, для реализации творческих потребностей — OpenSource. Отчаянно необходимо, например, написать препроцессоры для Go и Rust, реализующие синтаксис исключений!

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

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

Вместе с отчуждением уныние и нежелание бороться будут только нарастать, однако нужно помнить, что и шансы на победу со временем уменьшаются. Поэтому, чем раньше мы выступим единым фронтом, тем лучше!
Да, многие возможности уже упущены. Да, Железная Пята наступает с неумолимой неизбежностью. Однако наше генеральное сражение ещё впереди!

Дорогу осилит идущий. Капля точит камень. Если каждый из нас — хоть где-то хоть какой-то гадости в IT — скажет твёрдое "нет!", мир станет лучше, чище и на шажок ближе к идеалу.

Оковы тяжкие падут,
Темницы рухнут — и свобода
Вас примет радостно у входа,
И братья меч вам отдадут.
© А.С. Пушкин

Надеюсь, эта статья поможет читателю выбрать правильную сторону в этой вечной борьбе сил света и тьмы. К счастью, или, увы, но отсидеться в сторонке не получится.

Пролетарии всех стран, соединяйтесь!
#2 | 12:32 18.01.2023 | Кому: Пальтоконь
> Боротьба нанайского мальчика в одно лицо? Ну или я нихрена не понял из написанного.

Тут скорее вариант номер два.
#3 | 12:50 18.01.2023 | Кому: Goman
> Автор столкнулся со специализацией. Ему показали, что программирование это вовсе не творчество (как многие наивно полагают), а поденное ремесло.

Тут не про творчество. Автор столкнулся с необъяснимым, бизнес готов нести огромные издержки (800 тысяч в месяц на 4 года это 38+ миллиардов чистого убытка) ради того чтобы соответствовать регламентам. На первый взгляд дурость в чистом виде. На второй оказалось что есть вещи, которые ценятся дороже.

Ну и про "средний класс" тоже хорошо разъясняется. Весь IT сейчас — это средний класс. По сути это пролетарии, однако огромные доходы и вполне достойный образ жизни заставляет их не чувствовать себя таковыми, не чувствовать себя угнетёнными. Автор делает вывод что это временно и активно идёт работа чтобы эту ситуацию исправить.
#4 | 13:25 18.01.2023 | Кому: light331
> Даже самый самый генеральный директор является точно таким же наёмным работником как оператор метлы, которому в любой момент могут дать пня под зад лишив работы.

Нет, не так. Не любого наёмного работника можно просто вышвырнуть, без большого и очень большого ущерба для бизнеса. И топ-менеджер явно не равен работнику метлы, если только это не зицпредседатель Фунт .
#5 | 14:05 18.01.2023 | Кому: totoshka
> После прочтения мнения автора об операторе goto и вреде статической типизации - последующее читал скептически.

Да, у него много загонов. Про линтеры тоже дичь.
С таким же успехом можно захейтить редакторов и корректоров литературных текстов, по сути они исполняют ту же функцию, что и линтеры.
#6 | 15:04 18.01.2023 | Кому: nikopol
> это идея работает, что хорошо видно в кризисе который идет прямо сейчас, что мидлы нахер никому не нужны. Либы джунов для манки работы, либо синьоры-архитекторы.

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