github/awesome-kubernetes
1
0
Fork 0
mirror of https://github.com/nubenetes/awesome-kubernetes.git synced 2026-05-18 15:17:24 +00:00
Code Issues Packages Projects Releases Wiki Activity

march 3rd

Browse Source
This commit is contained in:
Inaki Fernandez
2022-03-03 14:24:06 +01:00
parent 939a69bd06
commit a38e364d38
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/about.md
View File

@@ -12,7 +12,7 @@ I'm not a freelancer and most of the time I work as a contractor, which in Spain
Suggesting improvements and best practices or applying quality standards and automated solutions that work well and are easy to verify shouldn't penalize a career, but it's terribly common. I am concerned about working with some colleagues or managers who consider it a threat, generating absurd conflicts, blame games and acting in bad faith or stupidly distorting the purpose of the project.
In a service driven IT sector (with ambiguities and many hidden interests) the product is the hours billed by the consultant, being almost irrelevant the content of the job and the delivered quality. It is thus difficult not to find technical solutions under the policy of applying "the most difficult, non-standard, slowest and most obfuscated way possible" as a competitive element (the hard way and doing weird things). This does not scale. Being ambiguous in JDs (not to say dishonest) without clarifying the real content of the job is easy and very well paid.
In a service driven IT sector (with ambiguities and many hidden interests) the product is the hours billed by the consultant, being almost irrelevant the content of the job and the delivered quality. It is thus too common to find technical solutions under the policy of applying "the most difficult, non-standard, slowest and most obfuscated way possible" as a competitive element (the hard way and doing weird things). This does not scale. Being ambiguous in JDs (not to say dishonest) without clarifying the real content of the job is easy and very well paid.
**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 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, 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. Perhaps DevOps should be renamed as OpsDev to avoid misunderstandings.