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. ...

Cada llamada a una API de LLM alojada envía tu prompt al servidor de otra persona y te cobra por token. Se cae la red y deja de responder. Ollama elimina los dos problemas: descarga un modelo de pesos abiertos en tu máquina y lo sirve mediante una API REST en localhost:11434. Un solo binario hace de gestor de modelos, cliente de chat y servidor. Qué hace Ollama en realidad Ollama envuelve llama.cpp y motores de inferencia similares, así que nunca tocas un flag del compilador ni una ruta de biblioteca CUDA. ollama pull llama3.2 descarga un archivo de modelo cuantizado (formato GGUF) desde el propio registro de Ollama en lugar de Hugging Face, aunque también puede importar archivos GGUF desde allí. Ejecutar el modelo pasa esos pesos a un servidor en segundo plano, que los carga en RAM (o VRAM, si encuentra una GPU compatible), los mantiene en memoria unos minutos después de tu última petición para que la siguiente sea rápida, y los libera en cuanto dejas de preguntar. ...

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. ...

Qué hace un CDN realmente con una petición Un usuario en Tokio que carga una página alojada en un servidor de Virginia paga esa distancia dos veces: una vez para que la petición llegue, otra para que la respuesta vuelva. La fibra viaja a una fracción fija de la velocidad de la luz, y ese trayecto por sí solo cuesta entre 150 y 200ms de ida y vuelta antes de que el origen haya hecho ningún trabajo. Añade una consulta a la base de datos y algún salto lento de más, y una página que se siente instantánea a la vuelta de la esquina se siente lenta al otro lado del planeta. ...

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. ...

Pregúntale a un LLM genérico por la política de devoluciones de tu empresa o por los tickets de soporte de la semana pasada, y dirá que no lo sabe o inventará algo plausible. Su conocimiento termina en lo que había en sus datos de entrenamiento. Nunca ha visto tus documentos y no puede ir a consultarlos a mitad de la conversación. La retrieval-augmented generation (RAG) soluciona justo esto: antes de que el modelo responda, un paso separado busca el texto relevante en tus propios datos y se lo entrega como parte del prompt. ...

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. ...