Двенадцать факторов: методология для облачных SaaS-приложений
The Twelve-Factor App
Методология «Двенадцать факторов» (The Twelve-Factor App) — это набор практик для создания software-as-a-service приложений, которые легко масштабировать, разворачивать на современных облачных платформах и поддерживать. Она основана на опыте разработки и эксплуатации сотен тысяч приложений на платформе Heroku. Документ описывает 12 факторов, от управления кодом и зависимостями до логирования и административных задач, и предназначен для разработчиков и DevOps-инженеров, создающих сервисы.
Минимизируйте расхождения между разработкой и продакшеном, обеспечивая непрерывное развертывание для максимальной гибкости.
- nebezb
Всё ещё очень актуально. Даже если вы не применяете это, можно многому научиться, прочитав за 15 минут.
Единственное, к чему у меня претензии, — глава 3: Конфигурация [1]
«Храните конфигурацию в окружении», «Учётные данные для внешних сервисов, таких как Amazon S3 или Twitter».
Помимо того, что это плохой совет, он имел вторичный эффект: разработчики решили, что можно хранить все локальные секреты окружения в ~/.bashrc.
Прекратите так делать. Следуйте остальным 11,5 факторам.
- browningstreet
Я правда думал, что это будет 12-слойная демонстрация MFA, показывающая абсурдность наших нынешних болезненных и неустойчивых трендов MFA.
- dec0dedab0de
Тогда казалось, что Heroku — это будущее. Каждый раз, когда я пытаюсь разобраться в какой-то ерунде в Azure, я мечтаю о том более простом будущем, которое мы потеряли.
- sandeepkd
Интересно, насколько это казалось естественным и правильным способом разработки ПО. Помню, как люди ссылались на это как на путеводную звезду. А потом постепенно люди приблизились к этому, но пошли дальше. Лично я считаю, что эти концепции требуют мышления универсала, то есть архитектора приложений. Сейчас у нас много продакт-инженеров в командах, продакт-менеджеров и менеджмента. Продакт-инженеры не всегда имеют достаточно рычагов влияния или стимулов, чтобы продвигать такие концепции.
И в то же время эти концепции кажутся настолько высеченными в камне, что так или иначе каждый будет заново их открывать.
- theozero
.env, как мы знаем, полон проблем... НО! Зацените varlock (https://varlock.dev) — это бесплатно и с открытым исходным кодом, и мы действительно модернизировали и адаптировали знакомый синтаксис (небольшой DSL поверх), чтобы сделать его намного лучше.
Встроенная валидация, типобезопасность, композиция через функции, загрузка с плагинами, защита от утечек и многое другое.
- RKearney
Заголовок должен быть (2011)
- imglorp
Хорошие лучшие практики, в основном, но я считаю, что модель 12FA полностью слила состояние, выведя его за рамки: «состояние — вон там, во внешнем сервисе, эмодзи трёх обезьян».
Да, но иногда состояние — это вся суть, и вам нужно управлять им самим, и тогда некоторые ваши процессы должны быть факторами 9 или 10.
- mermadicsolutio
Я тоже обдумываю компромисс для управления секретами в своём приложении. Хранить их легко — нужна только шифровка, и в основном всё хорошо. Но доставка — это сложно. Доставка через env, безусловно, проста, но может привести к утечке. Другой путь — подпись, ограниченная задачей, но это не мешает задаче распечатать секрет, это лишь уменьшает радиус поражения.
Но если удалить секрет после завершения задачи или развёртывания, результат практически тот же.