Skip to content

docs(infralifecycle): suggestion for section content #2214

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kfaseela merged 6 commits into from
Jul 10, 2026
Merged

docs(infralifecycle): suggestion for section content #2214

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
5434d8f
docs(infralifecycle): suggestion for section content
roberthstrand Jul 1, 2026
f94a2b0
fix: accept improvement
roberthstrand Jul 5, 2026
9d784f8
fix: accept improvement
roberthstrand Jul 5, 2026
8293d60
fix: accept improvement
roberthstrand Jul 5, 2026
7c3f062
docs(contributors): added rs to contributor list
roberthstrand Jul 9, 2026
d74c8de
docs: attempt at adding more nuance
roberthstrand Jul 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions tags/tag-infrastructure/initiatives/infrastructure-lifecycle/03_Foundation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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, 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. 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. 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 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

## Stateful vs. Stateless
Expand Down
1 change: 1 addition & 0 deletions tags/tag-infrastructure/initiatives/infrastructure-lifecycle/05_Conclusion.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,5 +10,6 @@ feedback.

Bruno Schaatsbergen (@bschaatsbergen)
Thomas Schuetz (@thschue)
Roberth Strand (@roberthstrand)

## Reviewers
Loading