From 387e08c5d5f935a72cf14f36b10d4c3d0e594bc4 Mon Sep 17 00:00:00 2001 From: Michele Cereda Date: Sat, 9 Dec 2023 23:54:30 +0100 Subject: [PATCH] feat: ops best practices from experience --- knowledge base/devops.placeholder | 5 ++- knowledge base/gitops.md | 3 +- .../operations best practices.placeholder | 34 ++++++++++++++ knowledge base/safe.placeholder | 1 + .../the automation paradox.placeholder | 44 +++++++++++++++++++ 5 files changed, 85 insertions(+), 2 deletions(-) create mode 100644 knowledge base/operations best practices.placeholder create mode 100644 knowledge base/the automation paradox.placeholder diff --git a/knowledge base/devops.placeholder b/knowledge base/devops.placeholder index 875ca3a..cb18f0d 100644 --- a/knowledge base/devops.placeholder +++ b/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/ diff --git a/knowledge base/gitops.md b/knowledge base/gitops.md index 98aa238..de273d0 100644 --- a/knowledge base/gitops.md +++ b/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.
+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. diff --git a/knowledge base/operations best practices.placeholder b/knowledge base/operations best practices.placeholder new file mode 100644 index 0000000..b57d895 --- /dev/null +++ b/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.
+ 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.
+ 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.
+ 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 diff --git a/knowledge base/safe.placeholder b/knowledge base/safe.placeholder index fbc5a59..2a09487 100644 --- a/knowledge base/safe.placeholder +++ b/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/ diff --git a/knowledge base/the automation paradox.placeholder b/knowledge base/the automation paradox.placeholder new file mode 100644 index 0000000..af62a79 --- /dev/null +++ b/knowledge base/the automation paradox.placeholder @@ -0,0 +1,44 @@ +# The automation paradox + +The point of automation is to reduce the manual workload.
+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.
+ 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_.
+ Especially true when one uses imperative runbooks.
+ Google [_Software crisis_][software crisis] for more info. +- The need to manage such complexity gave birth to a whole cottage industry.
+ 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.
+ 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.
+ Check out [the _GitOps_ approach][gitops]. +- Apply the KISS approach where possible.
+ 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.
+ Dependent on the final goals. +- Limit abstractions.
+ 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