mirror of
https://github.com/nubenetes/awesome-kubernetes.git
synced 2026-05-23 09:33:33 +00:00
chore: update docs/about.md [20260517-1948]
This commit is contained in:
github-actions[bot]
committed by
GitHub
GitHub
parent
767e3168b0
commit
bf0e7873b7
@@ -16,11 +16,11 @@ Suggesting improvements and best practices or applying quality standards and aut
|
||||
|
||||
In a service driven IT sector (with calculated 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](https://www.fairwinds.com/blog/never-should-you-ever-in-kubernetes-1-do-k8s-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](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.
|
||||
**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/store/2021/08/02/kubernetes-expands-from-containers-to-infrastructure-management/1654000/#:~: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[^1] approach.
|
||||
|
||||
[^1]:For example: [OpenShift deployment using the UPI method instead of IPI](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.) because of lack of permissions as an excuse.
|
||||
[^1]:For example: [OpenShift deployment using the UPI method instead of IPI](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.) because of lack of permissions as an excuse.
|
||||
|
||||
**DevOps principles: People, processes, technology**
|
||||
|
||||
@@ -31,7 +31,7 @@ A tech stack is not relevant compared to the way technology is managed. You coul
|
||||
| __DevOps__ | Automation and frequent deployments | CI/CD pipeline | Supply chain management, Cloud Configuration as Code, etc. | Less strict and more open | Less focus on correctness |
|
||||
| __GitOps__ | ==Correctness; doing DevOps correctly== | Git | Kubernetes, Controller (e.g., Operator), separate CI/CD pipelines, Infrastructure as a Code, etc. | ==Stricter and less open== | ==Designed with correctness== |
|
||||
|
||||
>[The SRE Experience Is Changing with Cloud Native:](https://thenewstack.io/how-the-sre-experience-is-changing-with-cloud-native/)
|
||||
>[The SRE Experience Is Changing with Cloud Native:](https://thenewstack.io/how-the-sre-experience-is-changing-with-cloud-native//)
|
||||
>
|
||||
>- From Firefighting to Prevention for SREs.
|
||||
>- Empower Developers with Self-Service.
|
||||
@@ -69,9 +69,9 @@ As professionals we are obliged to a high commitment to our clients, sometimes s
|
||||
|
||||
Losing employment and significantly penalizing employability and economic bargaining power for defending the value of automation, continuous improvement and standardization in computer engineering is a high price to pay. The alternatives often seem to be manual work with low salary expectations, lack of opportunities with new cloud jobs (better paid), promotion to a management position or emigration to countries with a different economic model (where technical jobs are better valued). This does not scale either. Freelancing worldwide is not for everyone either.
|
||||
|
||||
> *"One of the biggest problems in IT is that we keep reinventing the wheel. We are running the same circles, producing similar technologies to solve the same problems. Reinventing the wheel is a great way to learn how the wheel works, but not an efficient way to build software"* ([@dmokafa](https://twitter.com/dmokafa))
|
||||
> *"One of the biggest problems in IT is that we keep reinventing the wheel. We are running the same circles, producing similar technologies to solve the same problems. Reinventing the wheel is a great way to learn how the wheel works, but not an efficient way to build software"* ([@dmokafa](https://x.com/dmokafa))
|
||||
|
||||
> *"Tech industry thinks throwing more tools to the problem is the solution. More tools = more failure modes"* ([@rakyll](https://twitter.com/rakyll))
|
||||
> *"Tech industry thinks throwing more tools to the problem is the solution. More tools = more failure modes"* ([@rakyll](https://x.com/rakyll))
|
||||
|
||||
Instead of [reinventing the wheel](https://devdriven.by/promotion/) by rewriting from scratch a new installer or ad-hoc devops tool to manage/monitor kubernetes, please pay attention to the links shared here and learn how to add value on the so called [day 2](https://dzone.com/articles/defining-day-2-operations). You will find solutions and knowledge in a practical and efficient way without being totally essential to obtain a certification to successfully complete the task. For example, if there's money for [reinventing the wheel](https://www.reddit.com/r/ExperiencedDevs/comments/pw6vuv/promotion_driven_development/) on day 1, then there's money for investing in these high value added solutions on day 2 where automation can significantly improve our lives and the quality of the delivered service. **Automation is also a key element when evaluating the delivery of a service.**
|
||||
|
||||
@@ -79,11 +79,11 @@ Instead of [reinventing the wheel](https://devdriven.by/promotion/) by rewriting
|
||||
|
||||
Does saying this publicly imply being blacklisted and losing professional opportunities? What kind of society do we live in?
|
||||
|
||||
Tips: ask the hiring manager what experience they have with Cloud Automation, Cloud Managed Services and K8s in Production, if they deploy OpenShift via IPI[^1] or UPI, whether they are familiar with [Gitops](https://thenewstack.io/kubernetes-at-scale-without-gitops-is-a-bad-idea/) as the correct way of doing DevOps, if they work with modern, easy-to-use automation tools ([terraform](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs), [ansible modules](https://docs.ansible.com/ansible/latest/collections/kubernetes/core/k8s_module.html) with YAML/[Jinja templates](https://github.com/pallets/jinja/), argocd, helm, an automation server[^3] to run pipelines, declarative code in Jenkins[^4] Pipelines or in DevOps Azure Pipelines, [IaC boilerplates](https://nubenetes.com/terraform/) instead of [k8s vanilla](https://www.digitalocean.com/blog/vanilla-kubernetes-vs-managed-kubernetes), etc) or they are not practical and prefer to develop their own ad-hoc tools with millions of lines of code that need maintenance (by who?). If any doubt, ask them to show you their pipelines and custom solutions, how long it takes them to deploy and setup their k8s infra on day 1 & day 2 (pets vs cattle service model), how long it takes them to deploy a single app and if the process is fully automated or not, what monitoring solutions they have, if security and Role-based Access Control (RBAC) are implemented in their k8s clusters, whether changes and PoCs are tested first in ephemeral and isolated K8s/Cloud infra test environments with IaC & CI/CD pipelines, if solutions can be discussed within the team, etc.
|
||||
Tips: ask the hiring manager what experience they have with Cloud Automation, Cloud Managed Services and K8s in Production, if they deploy OpenShift via IPI[^1] or UPI, whether they are familiar with [Gitops](https://thenewstack.io/kubernetes-at-scale-without-gitops-is-a-bad-idea//) as the correct way of doing DevOps, if they work with modern, easy-to-use automation tools ([terraform](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs), [ansible modules](https://docs.ansible.com/projects/ansible/latest/collections/kubernetes/core/k8s_module.html) with YAML/[Jinja templates](https://github.com/pallets/jinja/), argocd, helm, an automation server[^3] to run pipelines, declarative code in Jenkins[^4] Pipelines or in DevOps Azure Pipelines, [IaC boilerplates](https://nubenetes.com/terraform/) instead of [k8s vanilla](https://www.digitalocean.com/blog/vanilla-kubernetes-vs-managed-kubernetes), etc) or they are not practical and prefer to develop their own ad-hoc tools with millions of lines of code that need maintenance (by who?). If any doubt, ask them to show you their pipelines and custom solutions, how long it takes them to deploy and setup their k8s infra on day 1 & day 2 (pets vs cattle service model), how long it takes them to deploy a single app and if the process is fully automated or not, what monitoring solutions they have, if security and Role-based Access Control (RBAC) are implemented in their k8s clusters, whether changes and PoCs are tested first in ephemeral and isolated K8s/Cloud infra test environments with IaC & CI/CD pipelines, if solutions can be discussed within the team, etc.
|
||||
|
||||
[^3]: Jenkins/CloudBees, Ansible Tower/AWX, Foreman, Rundeck, Azure DevOps, GitLab CI, etc.
|
||||
|
||||
[^4]: Automation with [Jenkins Configuration as Code](https://www.jenkins.io/projects/jcasc/) replaces what was previously done via [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/) and [jenkins remote REST API](https://www.jenkins.io/doc/book/using/remote-access-api/) calls (requiring backend development with tools like [swagger](https://swagger.io/) and API Testing tools like [postman](https://www.postman.com/)). Similar scenario applies to other technologies.
|
||||
[^4]: Automation with [Jenkins Configuration as Code](https://www.jenkins.io/projects/jcasc//) replaces what was previously done via [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli//) and [jenkins remote REST API](https://www.jenkins.io/doc/book/using/remote-access-api//) calls (requiring backend development with tools like [swagger](https://swagger.io/) and API Testing tools like [postman](https://www.postman.com/)). Similar scenario applies to other technologies.
|
||||
|
||||
> [*"The absolutely difficult thing is reaching volume production without going bankrupt, that is the actual hard thing"*](https://www.youtube.com/watch?v=cdZZpaB2kDM&t=2025s) Elon Musk
|
||||
|
||||
@@ -95,7 +95,7 @@ Tips: ask the hiring manager what experience they have with Cloud Automation, Cl
|
||||
|
||||
</center>
|
||||
|
||||
> *"I am a big fan of the scientific method. Engineers do not build bridges from a right or left perspective, the engineer builds bridges from an evidence-based perspective and over time bridge construction has improved. On the other hand, a politician does things from a right or left perspective, and over time politics has gotten worse. When I work with politicians and two of them are in a room together, one always thinks of the other, "will they get in my way? Will they damage my reputation? Is there a conflict of interest?" On the other hand, when two engineers meet, they say, "hello! I have a problem, can you help me?" Engineers rely on evidence. If you want to save the world, think like an engineer."* [ref 1 (Youtube Clip in Spanish)](https://youtube.com/clip/Ugkx5e13a72WjgowgmAtFieyNFuiKarXWXDp), [ref 2 (English)](https://www.rtve.es/play/videos/redes/redes-claves-para-enfrentarse-mundo-hoy-vo/1714674/), [ref 3 (Spanish)](https://www.rtve.es/play/videos/redes/redes-claves-para-enfrentarse-mundo-hoy/1714673/), [ref 4 (Spanish)](https://www.youtube.com/watch?v=7ruXlR08JZ0) - [Mark Stevenson](https://markstevenson.org), writer and businessman.
|
||||
> *"I am a big fan of the scientific method. Engineers do not build bridges from a right or left perspective, the engineer builds bridges from an evidence-based perspective and over time bridge construction has improved. On the other hand, a politician does things from a right or left perspective, and over time politics has gotten worse. When I work with politicians and two of them are in a room together, one always thinks of the other, "will they get in my way? Will they damage my reputation? Is there a conflict of interest?" On the other hand, when two engineers meet, they say, "hello! I have a problem, can you help me?" Engineers rely on evidence. If you want to save the world, think like an engineer."* [ref 1 (Youtube Clip in Spanish)](https://www.youtube.com/clip/Ugkx5e13a72WjgowgmAtFieyNFuiKarXWXDp), [ref 2 (English)](https://www.rtve.es/play/videos/redes/redes-claves-para-enfrentarse-mundo-hoy-vo/1714674//), [ref 3 (Spanish)](https://www.rtve.es/play/videos/redes/redes-claves-para-enfrentarse-mundo-hoy/1714673//), [ref 4 (Spanish)](https://www.youtube.com/watch?v=7ruXlR08JZ0) - [Mark Stevenson](https://markstevenson.org), writer and businessman.
|
||||
|
||||
??? Think like an engineer and not like a politician "Click to expand!"
|
||||
|
||||
@@ -214,6 +214,6 @@ Let's improve both the private & public IT sector and the opportunities in large
|
||||
---
|
||||
<center markdown="1">
|
||||
|
||||
[](https://www.ansible.com/blog/migrating-the-runbook-a-journey-from-legacy-to-devops)
|
||||
[](https://www.redhat.com/en/blog/channel/open-source-communities?intcmp=7015Y000003t7aWQAQ)
|
||||
|
||||
</center>
|
||||
Reference in New Issue
Block a user