IMO the end days for TF and YAML engineering are close, at least for new work
It’s all HTTP APIs. Build a web UX and store the state in a DB.
SRE/ops people ...at work just use the methods everyone else does
Unless the company still has hardware, cloud ops/SRE is just making their lives harder to be different
Please no. Don't make running a stateful service a requirement for tooling people need to use when the world is on fire. Or needs to load 40Mb of JS to rebuild a deployment, and works only on Chrome 46.012.2039465. Ops/SRE/DevOps/SysAdmin/SysOps/etc are different, and have optimised things to reduce the amount of dependancies.
Ideally the same tool can be run locally and in CI (with the same invocation commands) so that an Op can run tests locally, and even see the potential diff, before putting it up for review.
The advantage of this approach is you can see a diff, and use standard tooling like git / pr reviews to approve changes in day to day, and when the world is on fire, someone can break the glass and run it locally.
Never underestimate the value of peer review on a change to the infra - there is a reason things like ITIL exist, and we should learn from them.
sounds sweet. imagine applying gerrit to infra
> there is a reason things like ITIL exist, and we should learn from them
spot on.
That said, I am unsure if most people here are ITIL aware/certified.
TBH, the primary reason why I am familiar with ITIL is our clients from Accenture days requires certification to win contracts.
Yeah, it is cool - https://opendev.org/ is done that way, as is some of the wikimedia labs infrastructure
I am not certified either - I have just worked in places with ITIL inspired processes, but I can really see a way they can move forward with tools like terraform / pulumi / ansible and git
Requiring the definition of everything that makes up your stack to be stored in a format that is not text adds complexity to the disaster recovery process, not to mention mutation, diffing, reviewing, approving, promoting, etc.
For places where a single environment that is updated in place and requires little/no approval to do so, sure. Personally I really like textual definition of infrastructure and configuration, and disagree that it is end days for them.
Would also be great to import things with generic names:
from diagrams.aws.database import RDS as Database
which you could replace at a later point with: from diagrams.gcp.database import SQL as Database
And have a provider neutral description that could eventually be compiled into a provider-specific Terraform description just by changing the imports.