Also check out https://github.com/khalidx/runbook (shameless plug). Executable markdown documents that you can run. Great for DevOps and sharing commands with the team.
Yes, that's exactly how I use it! Especially when I need to combine Terraform and CDK, or Terraform and Pulumi (depending on where I'm using which). The library has a nice CLI UI which makes running different things and gluing them together easy.
If you do end up trying this: try running "runbook ls" and "runbook run" after you download. It gives you an autocomplete UI that searches-as-you-type across all commands in your markdown document.
Standardized roles don't exist in any industry anywhere, and from both sides to be incentive is there to fudge responsibilities. From a business perspective, advertising for current trends makes talented applicants more likely to apply. On the flip side, an applicant likely wants to have a DevOps title even if they are simply doing clickops, as it makes them more appealing later down the line with 4+years experience in the title. "Title inflation" happens in all industries - you see it with people being called senior engineers with 2-3 years of experience, for example.
Simply because DevOps is the onomatopoeic sound devs made when slipping on their banana peel (crappy code pushed in production) with a loud "ops" who happen to be both a sad face and a cry for help...
Beside that while this was the video that pushed me from Unix to Emacs (yes, correctly because that's was my switch not Vim in general but Unix model to Emacs/classic Desktop model) I never manage anything this way, instead most of my setups are tangled configs from org-mode, something I can't avoid to avoid entering in crazy kill mode looking to some YAML-lovers devs fresh blood... In many devops modern @$£&%"£CENSORED!!£!.
The results are stored inline, and the data can be re-used in different blocks even between languages. It doesn't look like codedown does that, can markdown do that with source blocks ?
Back in 2014 when this was first published I found it really inspiring and incorporated many of the techniques it describes into my daily workflow. It's been a while, so I wonder what he's doing now.
This was before Infrastructure-as-Code, Immutable Infrastructure, etc were popularized. 99% of the time, on greenfield systems, you shouldn't have to use Puppet or Chef or Ansible.
Runbooks-as-Code is also a great practice, similar to the notebook shown here. But they should be limited to one-time actions, like triage, recovery, etc.
> 99% of the time, on greenfield systems, you shouldn't have to use Puppet or Chef or Ansible.
I'm not entirely sure about this. One one hand, being able to set everything up once manually and just documenting the process usually will be easier, so people will opt for this, if given the choice.
Then again, I'm pretty sure that certain people aren't all that good at documentation and will write as little of it as possible, leading to this greenfield project that will inevitably turn into a brownfield project 5 years down the line now being at a disadvantage.
By then, nobody will really have any idea how to set up a new environment, or what exactly it needs. Worse yet, if you have some sloppily written documentation, that actually is no longer accurate and lies to you.
