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

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

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

Правило, которое сэкономит огромное количество времени вам самому и всем, кто будет читать ваш код:

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

Плохо:

test: ["CMD", "curl", "-f", "http://backend:3015/readiness"]

psql -p 5432 -h localhost -U ivanivanovich -d devdb

rsync \
  -a \
  -v \
  -z \
  --progress \
  -r \
  -e "ssh -p 33 -i ~/.ssh/srv_id_rsa" user@remote-server:/source/dir/ \
  /my/dir/on-local-machine \
  --files-from="file_path/backup.txt"

Хорошо:

test: ["CMD", "curl", "--fail", "http://backend:3015/readiness"]

psql --port=5432 --host=localhost --username=ivanivanovich --dbname=devdb

rsync \
  --archive \
  --verbose \
  --compress \
  --progress \
  --recursive \
  --rsh="ssh -p 33 -i ~/.ssh/srv_id_rsa" \
  user@remote-server:/source/dir/ \
  /my/dir/on-local-machine \
  --files-from="file_path/backup.txt"

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

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

Чистый код сам по себе никому не упал. Ни клиенты, ни директора, ни менеджеры, ни кто-либо ещё не обсуждают качество кода. Зато все они обсуждают очень конкретные метрики, бизнес-задачи и сроки их выполнения. И в какой-то момент обязательно придут к разработчику с раскалённой кочергой, если он в очередной раз не успеет закрыть тикеты в Джире к вечеру пятницы (ну или когда вы там следующий спринт обсуждаете).

Из этого знания вытекает простой факт: для компании/клиента законченный проект или фича гораздо важней, чем ваш чистый код. Единственные кому нужен чистый код — это сами разработчики. Если в базе кода бардак, это личные проблемы разработчика и команды. Это то, что теперь будет мешать вам на пути к достижению главной цели. Какой? Ну давайте подумаем вместе. Если вы среднестатистический разработчик, то, скорей всего, работаете в некой коммерческой компании. А в чём у нас главный смысл работы любого бизнеса? Правильно, в увеличении доходов.

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

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