Feda /dev/ - No Javascript allowed

Primeros 4 capitulos de la serie de backend preparados.

Si quereis aprender como los grandes engineers de la industria diseñamos y programamos espero veros en el stream y oir vuestro feedback para que pueda incorporar mejoras.

Como podeis ver a continuacion todo el contenido y filosofia de mi serie va a ser respaldado por otros de los PILARES de la industria, os pongo un par de enlaces que he visto hoy mientras hacia mi ronda de research... En este caso un par de x/ooglers y SREs de borg, kuberentes y sistemas core dando los mismos consejos que yo doy.

Como ya sabeis de master classes del pasado, en mi contenido no pondre ningun tipo de fuentes o enlaces porque yo soy la mayor fuente de autoridad que necesitais y todo el contenido lo contare a mi manera, basado en mi experiencia y con mis propias teorias.

Asi que me come la polla la teoria y terminologia del pasado cuando vamos a construir la teoria del futuro.

https://blog.dave.tf/post/new-kubernetes/

I currently believe that the very best container orchestration system is no container orchestration system, and that effort would be well spent avoiding that rabbit hole at all costs.

https://timewitch.net/post/apis-dont-need-to-reflect-the-database/

Lo que hable el otro dia en #43806 y como esta aplicado a k8s

Kubernetes, as myself and many others have covered, heavily uses tiered abstractions. For example, a pod (group of containers) is the base unit of compute. Rather than handling raw pods, we normally use a ReplicaSet, which takes the instructions “I want this many pods, with this spec” and manages pods for us. The chain goes higher still, EG most users use Deployments, which create multiple ReplicaSets to perform rolling deploys. Instead of managing individual pods at all, a user can specify “I want my Deployment to be like this… now I want my Deployment to be like this…” and the system Just Does It. The “1 action = 1 API call” rule is satisfied in many places.

Aunque en el caso de k8s, estoy en contra de las tiered abstractions. Y esto lo vamos a ver en la serie. Como os conte yo prefiero un estilo de metodos sobre RPC basado en casos de uso.

http://www.oilshell.org/blog/2021/07/blog-backlog-2.html

To repeat the claim: A distributed OS that follows the Perlis-Thompson Principle would have fewer concepts. It would be easier to use, and easier to build software on. The diagram would be smaller and more intelligible!

I suggest the meme Ken Thompson vs. Kubernetes to remember this. Ken Thompson would have designed something simpler, with lasting value.

Pocos servicios, cada servicio 1 producto, que se compongan como si fuera unix y APIs publicas transparentes para el usuario diseñadas desde el punto de vista tecnico.

#43866 das pena porque es tu puto trabajo &hacer cosas mejores& que k8s, de hecho tu trabajo deberia ser evitar la necesidad de k8s en tu empresa, porque cojones necesitais k8s?

y en lugar de ponerte a la industria o tu empresa sobre los hombros te arrastras como un mediocre lamiendo las botas de google y las pollas de cuatro bloggeros que te venden sobre enginieria como la silver bullet del siglo xxi :asco:

tampoco creo que des para mucho mas. todos los devops por lo que he visto sois abuelos sysadmins reconvertidos que no sabeis tirar una linea de codigo sin romper toda la infraestructura de la empresa y haceis resume-driven development

gente con 40 años que se han pasado 20 años configurando cosas a mano y ahora se encargan del k8s, travis y github de la empresa y el unico contenedor que conocen es el estercolero de contenedor que tienen por cerebro

y luego niñatos de 20 recien salidos de la universidad haciendo sobre enginieria que para abrir una shell en una instancia necesitan 2 scripts yaml y 3 pipelines de terraform y ansible

"nada te da lo que te da k8s" demuestra que no tienes ni puta idea de ingenieria en una frase... menuda perlita. dudo que necesites k8s. imagina lo perdido que vas.

ah si que teneis un k8s montando porque vuestro VP of engineering le salio de la polla copiar a google para demostrar que sus decisiones data-driven tienen un impacto en la vertical de la empresa creando sinergias que justifican los 500k anuales que cobra

#43870 eso es mentira y eres un autentico ignorante y un fpero

eres completamente incapaz de justificar tecnicamente la decision de k8s porque sabes que tengo razon, y pasas directamente al ataque personal... imaginate lo mal que estas que no puedes ni debatir 2 mensajes ni responderme a 2 preguntas

para una empresa normal y corriente, no eres google en pico de debt comprando empresas cada semana, nomad mismo con el stack de hashi te proporciona una solucion MEJOR, mas SIMPLE y mas EFICIENTE. toma ya te he desmentido el "nada te da lo que k8s", maldito ignorante eres un mentiroso. hay que tener la cara dura para ser un mentiroso como tu.

burbua de PoCs en la que vives

mientras muevo 100 veces mas trafico que tu

como siempre soy yo quien ha sacado una alternativa viable, porque tu calladito como una puta, y ahora que yo he sacado una alternativa, en lugar de volver a justficar porque k8s es mejor vas a empezar a atacarme a mi y a esta alternativa en lugar de mantener una discusion tecnica porque eres completamente incapaz de hacer nada que no sea seguir a otro mono como tu, o de discutir nada sin cagarte en los pañales que llevas puestos

solo te basas en falacias y sofismos baratos por el foro porque sabes en el fondo que eres un ignorante fpero mediocre que no tiene ni puta idea de lo que hace y es mucho mas facil huir para adelante como acabas de hacer que tener los cojones de reconocer que eres un mierdas

#43878wdaoajw:

i no 4-5 equipos de desarrollo que trabajan sobre stacks distintos

evitar que 4-5 equipos trabajen sobre stacks distintos

mira que facil he resuelto el problema de k8s

porque ibas a necesitar 4-5 equipos trabajen sobre stacks distintos?

veo un problema de leadership y managamenet

que no digo que sea imposible tener multiples stack, pero discrepo bastante con tu idea de que es "un equipo un stack". explicamelo xq creo que no te queda claro porque un equipo usa el stack que quiere ni que significa usar un stack.

#43878wdaoajw:

poder ahorrar costes (sobretodo operacionales) y simplificar arquitecturas

si por eso para mantener el k8s necesitas un equipo de 6 ingenieros devops a 100k anuales = 600k al año... + costes de k8s te vas al millon... como ahorrais costes si... tu lo que quieres es no perder tu trabajo

que arquitectura simplificas? dime una arquitectura que necesite k8s a ver... xq no hay nada que no puedes hacer tu por ti mismo y mejor que k8s, mas simple y mas facil.

#43878wdaoajw:

que necesiten las features que da k8s

que feature te da k8s? aun no me has dicho ninguna

Síndrome de Peter Pan spotted:
https://es.wikipedia.org/wiki/Síndrome_de_Peter_Pan

Es @desu, literal.