La suite de pruebas lleva tres semanas en verde. Hoy npm test falla en una aserción que no tiene nada que ver con lo que acabas de cambiar, y git log v1.4.0..HEAD muestra 340 commits de cuatro personas desde la última release que alguien confirmó que funcionaba. Leer cada diff te cuesta un día entero. Hacer checkout de commits al azar es más rápido, pero sigue sin ser un plan. ...
Qué hace el DNS en cada petición Toda petición a example.com empieza con una búsqueda que no tiene nada que ver con tu aplicación: algo tiene que convertir ese nombre en una dirección IP antes de que un solo paquete TCP salga de la máquina. Esa traducción es el DNS, el Domain Name System, y se ejecuta en cada petición, sea el cliente un navegador, curl o un servicio backend que llama a otro por hostname. ...
Qué protege TLS realmente en una conexión HTTPS Carga una página por http:// sin cifrar en una red que no controlas, un aeropuerto o el router de una cafetería, y todo lo que envías viaja como texto legible. La ruta de la URL, las cookies, los campos del formulario, la contraseña en un POST de login: cualquiera en esa red con un sniffer de paquetes lo lee al vuelo. TLS, Transport Layer Security, es el protocolo que corta eso. Se sitúa entre TCP y el protocolo de aplicación, así que cuando HTTP empieza a hablar, la conexión ya está cifrada y ligada a una identidad de servidor verificada. HTTPS es HTTP corriendo sobre esa conexión en lugar de una en texto plano. ...
Un endpoint de checkout que redimensiona la imagen de un producto, envía un email de confirmación y actualiza un motor de recomendaciones antes de responder con 200 OK es tan rápido como su paso más lento. Si uno solo hace timeout, toda la petición falla. Una cola de mensajes permite que el endpoint entregue ese trabajo como mensajes y responda de inmediato, mientras workers separados lo recogen a su propio ritmo. ...
Cualquier recurso cloud que hayas creado haciendo clic en una consola web (una VM, un load balancer, un registro DNS) también se puede describir en un archivo de texto y crear con un solo comando. El archivo vive en git, pasa por una pull request y reproduce el mismo setup en una segunda cuenta sin que nadie tenga que recordar qué nueve ajustes cambió a mano. Eso es lo que hace Terraform. ...
Una consulta que tarda 200ms contra tu base de datos sigue tardando 200ms la millonésima vez que alguien la ejecuta, y cada una de esas ejecuciones compite por las mismas conexiones, el mismo I/O de disco y la misma CPU. Redis guarda la respuesta en memoria, en un servidor que no hace nada más, así que la lectura número un millón cuesta un round trip de red en lugar de un plan de consulta. ...
Qué hay entre el navegador y tu app Apunta el navegador a example.com y la petición nunca toca el proceso que ejecuta tu código. Primero llega a otra cosa: un servidor que lee la petición, decide qué backend debe responder, la reenvía ahí y devuelve la respuesta como si la hubiera generado él mismo. Ese servidor es un reverse proxy. Nginx, Caddy, Traefik y HAProxy hacen todos este trabajo, igual que el load balancer que se sienta delante de un clúster de Kubernetes. El esquema no cambia nunca: los clientes hablan con el proxy y con nada más. Los servidores reales quedan detrás, sean los que sean y estén donde estén. ...
Haces pull del último main y Git se detiene con CONFLICT (content): Merge conflict in checkout.js. Resuelves el conflicto y el log muestra ahora un commit llamado Merge branch 'main' into feature/checkout, sentado encima de los tres commits que en realidad escribiste tú. Cuatro commits, un solo cambio real. Un compañero que lea ese historial el mes que viene no puede saber cuál es cuál. git merge y git rebase responden a la misma pregunta: cómo pongo mi rama al día con los cambios hechos en otro sitio. Dejan rastros muy distintos, y elegir el equivocado en una rama compartida causa daño real. ...
docker build && docker push desde tu portátil funciona hasta que otra persona tiene que publicar la misma imagen, o hasta que tiene que pasar en cada merge sin que tú estés delante del teclado. GitHub Actions ejecuta esa build en los runners de GitHub, etiqueta la imagen según lo que haya disparado el workflow y la publica en un registry desde el que tu paso de deploy puede hacer pull. Nada se ejecuta en local. ...
Ejecuta kubectl run nginx --image=nginx:1.27 y Kubernetes crea exactamente un Pod llamado nginx. Bórralo con kubectl delete pod nginx y desaparece para siempre — nadie se entera, nadie lo reemplaza. Un Pod es la unidad mínima desplegable en Kubernetes: uno o más contenedores que comparten un namespace de red y un conjunto de volúmenes, programados juntos en un mismo nodo. Ese Pod aislado es un callejón sin salida en producción. Si el contenedor que hay dentro falla, el kubelet lo reinicia en el mismo sitio. Si el nodo se reinicia, o alguien borra el Pod, nada lo vuelve a crear. Un Pod desnudo no tiene memoria de que debería seguir existiendo. ...