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

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

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

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

1) Кодовая база. Одна кодовая база — одно приложение. Кодовая база ведется с помощью системы контроля версий, любой, на ваш вкус. Каждый разработчик в команде работает с одним и тем же кодом(изменения, внесенные разработчиком во время работы не противоречат этому пункту), на серверах запускается этот же код. Представьте, что у вас есть N друзей близняшек, одевающихся почти одинаково. Отличать их друг от друга смогут разве что родители(а смогут ли?).
2) Зависимости. Приложения явно указывает пакеты, которые нужны ему для работы через манифесты декларации зависимостей и  менеджер зависимостей. Таким образом мы избегаем ситуаций, когда в одной среде приложение работает корректно, а при запуске на другом компьютере приложение падает из-за отсутствия нужной библиотеки.
3) Конфигурация. Должна подкидываться приложению из переменных окружения. Если вы прибьете гвоздями креды для подключения к БД в коде, а потом поменяете пароль на сервере базы или же переместите базу на другой хост, то без патча в исходном коде приложения вы банально не заведетесь.

В последующих постах пройдемся и по остальным 9 пунктам :)