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

> самое сложное для человека - смириться с тем, что ты посредственность

Ну т.е. политика заменяемости и дробления персонала - это оттого, что посредственности?

Кстати, микросервисы это не источник проблемы автора.

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

По сути автор работает на позиции не разраба, а подстановщика параметров в некие шаблоны скриптов.

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

> Автор делает вывод что это временно и активно идёт работа чтобы эту ситуацию исправить.

Создать вместо "артелей" "айтифабрики"-конвееры - вот в чем идея.

Автор айти-луддит как бы.

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

Не совсем, как я понял.

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

Как на конвеере.

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

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

> микросервисы - гуд.

Естественно, сами по себе ни разу не бэд.

> Красиво — небольшое.

Главное не размер !!!

Главное - соразмерность и согласованность.

> Пусть каждая программа делает что-то одно, но хорошо.

Предпочитая масштабируемость эффективности - это смотря с какой т.з. будет хорошо.

С т.з. эффективности - вопрос, хорошо ли это.

> Предпочитайте переносимость эффективности.

См. Выше. И важен баланс все же.

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

> Храните данные в простых текстовых файлах.

То-то я вижу известные СУБД так и делают, ага)
Всякой задаче свой формат полезен. И текстовый в т.ч.

> Извлекайте пользу из уже существующих программных решений.

Так и рождаются нагромождения макросов на экселе вместо разработки БД )

Зачем, ведь существует эксель!!!

Всему своя мера же.

> Используйте скриптовые языки для уменьшения трудозатрат и улучшения переносимости.

Это слой сценариев по сути.
Когда программа "сама своему сценарию рантайм компилятор".
До определенного предела да - неплохо.

> Избегайте пользовательских интерфейсов, ограничивающих возможности пользователя по взаимодействию с системой.

Скорее избегайте организации интерфейсов, ограничивающих разработчика для дальнейшего расширения.

Это да.

Но.
Избегание тоже должно быть в меру.
Зависит от задачи.

> Делайте каждую программу «фильтром».

Ну такое себе.

***

В целом абсолютизация этих принципов так же спорна, как и их игнорирование, ибо принципы неплохи.