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

Open
roberthstrand wants to merge 1 commit into
base: main
Choose a base branch
from
+8 −0
Open

docs(infralifecycle): suggestion for section content #2214

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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, 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
Expand Down
Loading