From 5434d8fd67899c6dd7594c2fcd8907c8d6e73e41 Mon Sep 17 00:00:00 2001 From: Roberth Strand Date: Wed, 1 Jul 2026 11:40:47 +0200 Subject: [PATCH 1/6] docs(infralifecycle): suggestion for section content This commit is a suggestion for the section for On-Demand vs. Continuously Reconciled. Signed-off-by: Roberth Strand --- .../initiatives/infrastructure-lifecycle/03_Foundation.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md index 5184a20cb..d10f9775b 100644 --- a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md +++ b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md @@ -43,6 +43,14 @@ implemented in an easier way. ## On-Demand vs. Continuously Reconciled +These are two paradigms in lifecycle management that are fundamental opposites. On the one side, you have changes that are triggered by a person or external system, the other is where the system itself can reconcile any changes by observing a source. The first can be done through a portal, CLI, or scripts, while the other requires that you install and maintain a set of agents whose behavior is defined by configuration or policy. + +When you manage infrastructure with on-demand solutions like scripts, either manually run or through an automation pipeline, one of the benefits is that you get immediate feedback. With a reconciliation process, you rely on eventual consistency, which requires all changes to happen at the source. The GitOps principles call this the “desired state” and it should always be what the system tries to adhere to. This means that a continuously reconciled system is self-healing, while any on-demand model has no such guarantee. + +On-demand operations can also be more complex than a continuously reconciled one. Managing imperative pipelines and scripts can quickly grow out of proportion, putting cognitive load on the operator. The agents, Kubernetes controllers or operators, are usually singletons used for specific parts of the operation. This can result in a more stable architecture, with fewer variables and less bespoke solutions. + +You might think of them in different terms like “push versus pull” or “pipelines” versus controllers. Neither is wrong, and they both have their benefits and disadvantages. You can also opt for a hybrid approach, where certain parts of the system are reconciled continuously, while others are not. + ## DSL vs. Programming Language ## Stateful vs. Stateless From f94a2b01ebec687f3a37fea67e30784bc1dc2eae Mon Sep 17 00:00:00 2001 From: Roberth Strand Date: Sun, 5 Jul 2026 21:05:57 +0200 Subject: [PATCH 2/6] fix: accept improvement Co-authored-by: Thomas Schuetz <38893055+thschue@users.noreply.github.com> Signed-off-by: Roberth Strand --- .../initiatives/infrastructure-lifecycle/03_Foundation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md index d10f9775b..090b4fcde 100644 --- a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md +++ b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md @@ -43,7 +43,7 @@ implemented in an easier way. ## On-Demand vs. Continuously Reconciled -These are two paradigms in lifecycle management that are fundamental opposites. On the one side, you have changes that are triggered by a person or external system, the other is where the system itself can reconcile any changes by observing a source. The first can be done through a portal, CLI, or scripts, while the other requires that you install and maintain a set of agents whose behavior is defined by configuration or policy. +These are two paradigms in lifecycle management that are fundamental opposites. On the one side, changes can be triggered by a person or external system, the other is where the system itself can reconcile any changes by observing a source. The first can be done through a portal, CLI, or scripts, while the other requires that you install and maintain a set of agents whose behavior is defined by configuration or policy. When you manage infrastructure with on-demand solutions like scripts, either manually run or through an automation pipeline, one of the benefits is that you get immediate feedback. With a reconciliation process, you rely on eventual consistency, which requires all changes to happen at the source. The GitOps principles call this the “desired state” and it should always be what the system tries to adhere to. This means that a continuously reconciled system is self-healing, while any on-demand model has no such guarantee. From 9d784f8d84efed4800e842dc9d1d03c2d9081c6e Mon Sep 17 00:00:00 2001 From: Roberth Strand Date: Sun, 5 Jul 2026 21:06:11 +0200 Subject: [PATCH 3/6] fix: accept improvement Co-authored-by: Thomas Schuetz <38893055+thschue@users.noreply.github.com> Signed-off-by: Roberth Strand --- .../initiatives/infrastructure-lifecycle/03_Foundation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md index 090b4fcde..cb3f53b6d 100644 --- a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md +++ b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md @@ -45,7 +45,7 @@ implemented in an easier way. These are two paradigms in lifecycle management that are fundamental opposites. On the one side, changes can be triggered by a person or external system, the other is where the system itself can reconcile any changes by observing a source. The first can be done through a portal, CLI, or scripts, while the other requires that you install and maintain a set of agents whose behavior is defined by configuration or policy. -When you manage infrastructure with on-demand solutions like scripts, either manually run or through an automation pipeline, one of the benefits is that you get immediate feedback. With a reconciliation process, you rely on eventual consistency, which requires all changes to happen at the source. The GitOps principles call this the “desired state” and it should always be what the system tries to adhere to. This means that a continuously reconciled system is self-healing, while any on-demand model has no such guarantee. +When infrastructure is managed with on-demand solutions like scripts, either manually or through an automation pipeline, one of the benefits gained is immediate feedback. With a reconciliation process, one can rely on eventual consistency, which requires all changes to happen at the source. The GitOps principles call this the “desired state” and it should always be what the system tries to adhere to. This means that a continuously reconciled system is self-healing, while any on-demand model has no such guarantee. On-demand operations can also be more complex than a continuously reconciled one. Managing imperative pipelines and scripts can quickly grow out of proportion, putting cognitive load on the operator. The agents, Kubernetes controllers or operators, are usually singletons used for specific parts of the operation. This can result in a more stable architecture, with fewer variables and less bespoke solutions. From 8293d60683dacf110c7ac2b4ba2da3851ac0afb1 Mon Sep 17 00:00:00 2001 From: Roberth Strand Date: Sun, 5 Jul 2026 21:06:40 +0200 Subject: [PATCH 4/6] fix: accept improvement Co-authored-by: Thomas Schuetz <38893055+thschue@users.noreply.github.com> Signed-off-by: Roberth Strand --- .../initiatives/infrastructure-lifecycle/03_Foundation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md index cb3f53b6d..36cdd0724 100644 --- a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md +++ b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md @@ -49,7 +49,7 @@ When infrastructure is managed with on-demand solutions like scripts, either man On-demand operations can also be more complex than a continuously reconciled one. Managing imperative pipelines and scripts can quickly grow out of proportion, putting cognitive load on the operator. The agents, Kubernetes controllers or operators, are usually singletons used for specific parts of the operation. This can result in a more stable architecture, with fewer variables and less bespoke solutions. -You might think of them in different terms like “push versus pull” or “pipelines” versus controllers. Neither is wrong, and they both have their benefits and disadvantages. You can also opt for a hybrid approach, where certain parts of the system are reconciled continuously, while others are not. +In different terms, this can be described as “push versus pull” or “pipelines” versus controllers. Neither is wrong, and both have their benefits and disadvantages. There is also the option to go for a hybrid approach, where certain parts of the system are reconciled continuously, while others are not. ## DSL vs. Programming Language From 7c3f06261ade48a1c51953967911d835af994ef8 Mon Sep 17 00:00:00 2001 From: Roberth Strand Date: Thu, 9 Jul 2026 18:56:54 +0200 Subject: [PATCH 5/6] docs(contributors): added rs to contributor list Signed-off-by: Roberth Strand --- .../initiatives/infrastructure-lifecycle/05_Conclusion.md | 1 + 1 file changed, 1 insertion(+) diff --git a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/05_Conclusion.md b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/05_Conclusion.md index e4908fcaa..aef5512c5 100644 --- a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/05_Conclusion.md +++ b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/05_Conclusion.md @@ -10,5 +10,6 @@ feedback. Bruno Schaatsbergen (@bschaatsbergen) Thomas Schuetz (@thschue) +Roberth Strand (@roberthstrand) ## Reviewers From d74c8de3f112ff41b0fe982256e8239d620ac560 Mon Sep 17 00:00:00 2001 From: Roberth Strand Date: Thu, 9 Jul 2026 19:13:46 +0200 Subject: [PATCH 6/6] docs: attempt at adding more nuance Signed-off-by: Roberth Strand --- .../initiatives/infrastructure-lifecycle/03_Foundation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md index 36cdd0724..d55fe5bb5 100644 --- a/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md +++ b/tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md @@ -45,11 +45,11 @@ implemented in an easier way. These are two paradigms in lifecycle management that are fundamental opposites. On the one side, changes can be triggered by a person or external system, the other is where the system itself can reconcile any changes by observing a source. The first can be done through a portal, CLI, or scripts, while the other requires that you install and maintain a set of agents whose behavior is defined by configuration or policy. -When infrastructure is managed with on-demand solutions like scripts, either manually or through an automation pipeline, one of the benefits gained is immediate feedback. With a reconciliation process, one can rely on eventual consistency, which requires all changes to happen at the source. The GitOps principles call this the “desired state” and it should always be what the system tries to adhere to. This means that a continuously reconciled system is self-healing, while any on-demand model has no such guarantee. +When infrastructure is managed with on-demand solutions like scripts, either manually or through an automation pipeline, one of the benefits gained is immediate feedback. With a reconciliation process, one can rely on eventual consistency, which requires all changes to happen at the source. The GitOps principles call this the “desired state” and it should always be what the system tries to adhere to. This means that a continuously reconciled system is self-healing, while any on-demand model has no such guarantee. However, with the right tools, the on-demand model can be idempotent and more flexible. -On-demand operations can also be more complex than a continuously reconciled one. Managing imperative pipelines and scripts can quickly grow out of proportion, putting cognitive load on the operator. The agents, Kubernetes controllers or operators, are usually singletons used for specific parts of the operation. This can result in a more stable architecture, with fewer variables and less bespoke solutions. +On-demand operations can also be more complex than a continuously reconciled one. Managing imperative pipelines and scripts can quickly grow out of proportion, putting cognitive load on the operator. The agents, Kubernetes controllers or operators, are usually singletons used for specific parts of the operation. This can result in a more stable architecture, with fewer variables and less bespoke solutions. It comes with it own sets of problems, like less granular control and debugging. -In different terms, this can be described as “push versus pull” or “pipelines” versus controllers. Neither is wrong, and both have their benefits and disadvantages. There is also the option to go for a hybrid approach, where certain parts of the system are reconciled continuously, while others are not. +In different terms, this can be described as “push versus pull” or “pipelines” versus "controllers". Neither model is wrong, and both have their benefits and disadvantages. There is also the option to go for a hybrid approach, where certain parts of the system are reconciled continuously, while others are not. ## DSL vs. Programming Language