From 4b8edce1b293ffb080e09528e8d036366de56233 Mon Sep 17 00:00:00 2001 From: Inaki Fernandez Date: Mon, 7 Mar 2022 09:29:38 +0100 Subject: [PATCH] footnote --- docs/about.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/about.md b/docs/about.md index 5a332e46..be60460b 100644 --- a/docs/about.md +++ b/docs/about.md @@ -16,7 +16,9 @@ In a service driven IT sector (with calculated ambiguities and many hidden inter **Ambiguities about DevOps term**. Development of new ad-hoc devops tools and ad-hoc monitoring solutions should not be the role of devops specialists. DevOps professionals develop IaC and CI/CD pipelines with standard tools and code, ideally with a [cattle service model](http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/), GitOps patterns & [kubernetes](https://www.nextplatform.com/2021/08/02/kubernetes-expands-from-containers-to-infrastructure-management/#:~:text=More%20and%20more%20in%20the%20middleware%20layer%2C%20not%20in%20the%20hardware.) among other responsabilities such as application monitoring. The development of devops tools for kubernetes with i.e. client-go should be clearly mentioned in a JD as "software development of devops tools for kubernetes with client-go" (suitable for a software engineer with [client-go skills](https://itnext.io/generically-working-with-kubernetes-resources-in-go-53bce678f887), a developer of devops/kubernetes/monitoring tools). In addition, a DevOps specialist should not be a fullstack developer who occasionally does QA + DevOps + Cloud Design/Ops. Moreover, avoid confusing terms to justify these different backgrounds by creating two roles like DevOps Software Developer and DevOps SysAdmin. Maybe DevOps should be renamed as OpsDev to avoid misunderstandings. -A tech stack is not relevant compared to the way technology is managed. You could have the best tool and run into trouble by taking the risk of applying an unsupported or not recommended approach. +A tech stack is not relevant compared to the way technology is managed. You could have the best tool and run into trouble by taking the risk of applying an unsupported or not recommended[^1] approach. + +[^1]:[For example: OpenShift deployment using the UPI method instead of IPI because of lack of permissions as an excuse](https://keithtenzer.com/openshift/openshift-4-aws-ipi-installation-getting-started-guide/#:~:text=OpenShift%20offers%20two%20possible%20deployment%20methods%3A%20IPI%20(as%20mentioned)%20and%20UPI%20(User%20Provisioned%20Infrastructure).%20The%20difference%20is%20the%20degree%20of%20automation%20and%20customization.%20IPI%20will%20not%20only%20deploy%20OpenShift%20but%20also%20all%20infrastructure%20components%20and%20configurations.) **DevOps principles: People, processes, technology**