Köszönöm a részletes választ, és akkor pontosítok, hogy mit értek „nincs állapotmodell” alatt — mert valóban nem a Terraform-féle state-fájl létezését vitatom.
Az IaC-ben van state, de nem állapotmodell, és ez a különbség a lényeg.
1) Az IaC „state”-je mapping- és metadata-tároló, nem állapotmodell
A Terraform/Pulumi/CFN state:
- resource-azonosítók,
- provider-mapping,
- függőségek,
- metaadatok (token, timestamp, hash stb.).
Ez egy műveletközi tároló, nem egy absztrakt rendszerállapotot reprezentáló modell.
A state nem írja le:
- az Actor szándékát,
- a célállapotot mint logikai struktúrát,
- a változás következményeit,
- az ebből fakadó kötelezettségeket,
- a valós állapot és a kívánt állapot közti szignifikáns eltéréseket.
Tehát: state létezik → állapotfogalom nincs.
2) Az IaC “desired state” nem összevethető a tényleges állapottal
A deklarált konfiguráció → szándék leírása, nem állapot.
A valós infrastruktúra → tényleges állapot, ami:
- driftelhet,
- módosulhat IaC-n kívül,
- bővülhet vagy zsugorodhat más rendszerek hatására,
- lehet részben felkonfigurálva,
- lehet dependency-szinten eltérő.
Az IaC saját definíciója szerint sem végzi el a valós és az elvárt állapot tiszta összevetését, csak diffet számol a deklarációhoz képest, feltételezve hogy a state reprezentálja a valóságot — ami sok esetben nem igaz.
3) A CIC állításának alapja: az IaC modelljéből hiányzik az Intent → State → Obligation → Consequence lánc
A CIC szerint egy valós állapotmodellhez négy dolog kell:
- Actor – ki generálja a változtatást
- Intent – mit akar létrehozni
- State – formális állapot (nem provider-mapping, hanem logikai rendszerállapot)
- Obligation – milyen kötelezettséget generál az Intent
- Consequence – mi történik, ha a tényleges állapot eltér
- ProofTrace – bizonyítható lánc
Ezek közül egyik sem része az IaC-modellnek, így a drift kezelése mindig:
- eseti,
- eszközfüggő,
- részleges,
- regresszív (tuning helyett workaroundokat épít).
A CIC nem azt mondja, hogy az IaC „rossz”, hanem azt, hogy a deklaráció önmagában nem elég az állapot reprezentálásához.
4) A komplexitás önmagában nem indokolja a hiányt — csak azt mutatja, hogy a jelenlegi modell nem alkalmas rá
Idézlek:
„nem egyszerűen komplex-e a probléma?”
A probléma komplex, igen — de ettől még lehet rá olyan modell, amely ezt kezeli.
A CIC fogalmi tere (Actor → Intent → State → Obligation → Consequence) éppen ezt teszi:
- különválasztja a szándékot az állapottól,
- különválasztja a kívánt állapotot a tényleges állapottól,
- és definiálja a következménylogikát a kető közötti eltérés esetére.
Ezzel az IaC-ben lévő implicit drift mechanizmus → explicit állapotmodellré válik.
5) Röviden összefoglalva
Az IaC „state” nem állapotmodell, mert nem ír le egy absztrakt, összevethető rendszermodellt.
A CIC pedig azt mondja: egy infrastruktúrát csak akkor lehet determinisztikusan kezelni, ha a szándék, az állapot és a következmények formálisak.
Ezért használ más szemléletet.