Comments 11
Если вы почитаете подробнее про 12factor, то увидите что там отсутствует какая-либо привязка к какой-либо технологии, и описанные факторы применимы к любому приложению и любой архитектуре. Указанные же в посте 7 факторов завязаны на облака, контейнеры, и… и на этом можно заканчивать перечисление. Область применимости данных «факторов» весьма ограничена и безальтернативно требует использования Kubernetes, а посему ни о каких «19 факторах» можете и не мечтать. «Спасибо, такое нам не надо».
Вам не надо, но почему вы за всех? Авторы вот за всех не говорят, а явно обозначают, для кого. В вводное примечание добавили ещё раз про Kubernetes, чтобы убрать остатки возможного диссонанса.
Выделенное курсивом обычно подразумевает цитату или иносказательное выражение, добро пожаловать в интернет.
Некоторые из них применимы только к вёб-приложениям.
И хотя авторы в самом начале пишут, что 12 факторов применимы только к вёб и SaaS приложениям, называют они своё творение просто «The Twelve-Factor App». Не «The Twelve-Factors for Web and SaaS applications» или как-то так.
Как же так? Кликбейт? Реклама вёб-приложений?
Хотя соглашусь, что упомянуть в заголовке Kubernetes и облака было бы не лишним.
Та же «наблюдаемость» — это широкое понятие и фактор, который следует обеспечить любым (!) приложениям, вне зависимости от архитектуры или того, как они развернуты. Наблюдаемость — это возможность определять внутреннее состояние системы и процессов в ней по выходным данным (метрикам, логам, трейсам).
Для распределенной (микросервисной, SOA) архитектуры это просто необходимость. Без наблюдаемости невозможно (дорого и долго) проводить диагностику ошибок на продуктивной среде. С ее помощью можно решать дополнительные задачи: строить карту ландшафта и зависимостей между системами, контролировать SLA процессов и операций и.т.д
эти 19 факторов никоим образом не прибивают приложение к кубернетесу. Мы же знаем, что тот же роллинг апдейт можно построить без него (и его делали в до-куб-овую эпоху). Безопасность (рут в контейнере и пр.) — то же безотносительно к кубернетесу.
То что кубернетес стал практически отраслевым стандартом… Ну, что ж. Это такой же "стандарт", как и Линукс на серверах. Можно это принять и эффективно оседлать техологию, а можно решать задачи альтернативными путям.
Против демонстрации на примере k8s ничего не имею, всё-таки это сейчас самый популярный инструмент, а само описание пунктов 13-16 легко натянется и на другой и останется верным.
А вот пункты 17-19 это уже что-то из разряда IBM Cloud only, к ним как раз больше всего вопросов. Но надо понимать что раз статья из блога IBM Cloud — значит и писать они будут про себя.
Более корректно было бы направить стрелки в обратную сторону, поскольку Prometheus сам ходит и опрашивает endpoint'ы, а Grafana сама забирает данные из Prometheus, но в смысле общей иллюстрации это не так критично.
Ну, это некритично по другой причине так-то — есть потоки данных (а они именно такие как на диаграмме), а есть диаграмма сетевых соединений. Иногда на них стрелочки идут в разных направлениях )))))
Минимумы и ограничения для контейнеров
Картинка как будто запутывает и намекает, что общее выделение ресурса для контейнера будет request + limit. Но мне всегда казалось, что request — это минимальное значение, а limit — это то, выше которого никогда не прыгнешь.
7 недостающих факторов в подходе 12 Factor App