> А если конечный стейт окружения не детерминирован?
так он и не обязан быть детерминирован, клиент может сам в bpmn редакторе докинуть недостающие элементы например (бд или типа того). доступные элементы всё равно уже заранее могут быть описаны (как роли ансибла), только не нужно писать промежуточные "плейбуки"
> Как ты предлагаешь провайзить сущность?
приватное/публичное облако + packer образы решают все проблемы. kops вон умеет вообще без доступа к инстансам деплоить кубер.
если инстансы будут в большей степени immutable это существенно упростит управление ими и автоматизацию. работу с железом я не рассматриваю, но там тоже такое возможно.
суть в том что можно сделать devops as a service, т.е публичный сервис, через который можно набросав схемку деплоить облака или даже свою инфраструктуру7
> так он и не обязан быть детерминирован
В конце ты написал про дженкинс, поэтому я подумал, что bpmn уже нет.
> приватное/публичное облако + packer образы решают все проблемы
Так и подумал, что так ответишь. Packer позволяет плодить сущности, а bpmn — их композить, но ты всё ещё не решаешь проблему провайзинга; ты её только отодвигаешь в сторону packer'а. В packer ты провайзишь убогим json, либо потом говёным hcl. Что не является выходом и оставляет незаполненную пропасть.
> если инстансы будут в большей степени immutable
Иммутабельность бесполезна без идемпотентности, а идемпотентность невозможна без лока данных на уровне инфры. Ну вот создал ты инфру через пулуми и пакер, а завтра передеплоил и всё у тебя сломалось. Иммутабельность есть? Есть. Идемпотентность? Нет. Referential transparency? Нет.
Ты только создаёшь иллюзию работоспособности подхода, как это делают девы со своими псевдо юнит тестами.