feat: ops best practices from experience

knowledge base/devops.placeholder

@@ -1,5 +1,8 @@
-# DevOps
+# The DevOps approach
+
+It is a _culture_, an _approach_, not a set of tools or a job title.
 
 https://www.youtube.com/watch?v=KJ5u_Kui1sU
 https://artero.dev/posts/scripts-do-not-scale/
 https://artero.dev/posts/are-you-a-devops-engineer/
+https://blog.massdriver.cloud/posts/devops-is-bullshit/

knowledge base/gitops.md

@@ -1,6 +1,7 @@
 # The GitOps approach
 
-Approach for implementing Continuous Deployment for cloud native applications.
+Approach for implementing Continuous Deployment for cloud native applications.<br/>
+It is a _culture_, not a set of tools or a job title.
 
 The core idea is having a Git repository that contains **declarative** descriptions of the currently desired state of one or more environments, plus automated processes to make the environment match the described state in the repository.
 

knowledge base/operations best practices.placeholder

@@ -0,0 +1,34 @@
+# Operations best practices
+
+- Think of KISS to be an invite to keep thinks simple with respect of your ultimate goal.<br/>
+  Avoid simplicity only for the sake of simplicity.
+- Apply the KISS approach wherever possible.
+- Mind [the automation paradox].
+- Remember that _DevOps_, _GitOps_ and all other corporate bullshit terms are just sets of practices, suggestions, or approaches.<br/>
+  They are **not** to be taken literally, and **need** to be adapted to the workplace, not the other way around.
+- Amazon's tenets are double-edge swords and, taken literally, only work for Amazon.
+- Watch out for complex things that should be simple (i.e. the [SAFe] delusion).
+- Pipelines' tasks should be tasks one can execute from one's own computer.
+- Pipelines are meant to be used as last mile steps for specific goals.
+- Keep pipelines' tasks as simple, consistent and reproducible as possible.<br/>
+  Avoid like the plague to put programs or scripts in pipelines.
+- There cannot be a single pipeline for everything, the same way as _one-size-fits-all_ is a big, fat lie.
+
+## Sources
+
+- [A case against "platform teams"]
+- [Culture eats your structure for lunch]
+- [DevOps is bullshit]
+- [Platform teams need a delightfully different approach, not one that sucks less]
+- [We have used too many levels of abstractions and now the future looks bleak]
+- [Why the fuck are we templating YAML?]
+
+[safe]: safe.placeholder
+[the automation paradox]: the%20automation%20paradox.placeholder
+
+[a case against "platform teams"]: https://kislayverma.com/organizations/a-case-against-platform-teams/
+[culture eats your structure for lunch]: https://thoughtmanagement.org/2013/07/10/culture-eats-your-structure-for-lunch/
+[devops is bullshit]: https://blog.massdriver.cloud/posts/devops-is-bullshit/
+[platform teams need a delightfully different approach, not one that sucks less]: https://www.chkk.io/blog/platform-teams-different-approach
+[we have used too many levels of abstractions and now the future looks bleak]: https://unixsheikh.com/articles/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html
+[why the fuck are we templating yaml?]: https://leebriggs.co.uk/blog/2019/02/07/why-are-we-templating-yaml

knowledge base/safe.placeholder

@@ -2,3 +2,4 @@
 
 https://freedium.cfd/
 https://medium.com/agileinsider/the-illusion-of-safe-unmasking-the-flaws-of-scaled-agile-5b0df6ef77e3
+https://safedelusion.com/

knowledge base/the automation paradox.placeholder

@@ -0,0 +1,44 @@
+# The automation paradox
+
+The point of automation is to reduce the manual workload.<br/>
+It's goals are also to maintain consistency and reliability of infrastructure and processes.
+
+The issue:
+
+- For every automation one puts in place, a _system_ is created.<br/>
+  Such system is the automation itself of the set of tools used to create it.
+- A system needs configuration and maintenance.
+- One relies on systems to maintain other systems.
+- Complex systems trend toward _brittle_ and _expensive_.<br/>
+  Especially true when one uses imperative runbooks.<br/>
+  Google [_Software crisis_][software crisis] for more info.
+- The need to manage such complexity gave birth to a whole cottage industry.<br/>
+  This includes tools and specific job titles (i.e. _DevOps_, _SRE_).
+- The tools one choses to implement one's system need to be consistent and reliable.<br/>
+  Should they not be, their issues defeat the whole purpose of what one is trying to automate.
+
+Possible solutions:
+
+- Move from imperative to declarative (desired state) where one can.<br/>
+  Check out [the _GitOps_ approach][gitops].
+- Apply the KISS approach where possible.<br/>
+  Make it so that is simple to maintain, not necessarily simple for the sake of simplicity.
+- Focus on the tools that most allow one to simplify the automation.<br/>
+  Dependent on the final goals.
+- Limit abstractions.<br/>
+  Check out [We have used too many levels of abstractions and now the future looks bleak] and [Why the fuck are we templating yaml?].
+
+## Sources
+
+- Personal experience.
+- [Automating your source of truth - GitOps and Terraform]
+- [Software crisis]
+- [We have used too many levels of abstractions and now the future looks bleak]
+- [Why the fuck are we templating yaml?]
+
+[gitops]: gitops.md
+
+[automating your source of truth - gitops and terraform]: https://www.youtube.com/watch?v=-K8R1OVXPy0
+[software crisis]: https://www.geeksforgeeks.org/software-engineering-software-crisis/
+[we have used too many levels of abstractions and now the future looks bleak]: https://unixsheikh.com/articles/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html
+[why the fuck are we templating yaml?]: https://leebriggs.co.uk/blog/2019/02/07/why-are-we-templating-yaml.html