Hace unos años, pasar información de una computadora a otra era una tarea impensable. Y se crearon protocolos para eso: SOAP, APIs, microservicios.
En realidad no pasa nada cuando se caen unas pocas gotas no confidenciales. Los sistemas de protocolos usan paridad, desde la memoria hasta mecanismos de recuperación de paquetes si falla uno en llegar a su destino. Un ejemplo clásico eran los módems antes de las conexiones DSL y de fibra óptica. Se adaptaban sobre la marcha.
Y los respaldos de información nos permiten duplicar la información. Ejemplo: los repositorios. Pero son SÍMBOLOS. No porque copies en un Excel el saldo de tu tarjeta, ese importe se va a duplicar. Aunque tengas libro1.xls, libro2.xls… libro10, todo apunta a la realidad.
Por eso el primer fundamento de la categoría Fundamentos es “ver la realidad”.
Los contenedores de información empezaron siendo modas. Que discos extraíbles Zip, que sistemas de archivos .jar o .war, luego empezaron los antecesores de las máquinas virtuales y nos convertimos en malabaristas. Luego sistemas de contenedores reales, como tupperwares de un refrigerador. Que si Docker, que si Kubernetes.
En la escala LATAM, a menos que estés en una empresa que venda más de un millón de USD al mes, es probable que no necesites Docker ni Kubernetes, mucho menos Redis o Cassandra.
Desde 2020, más o menos, he visto que las personas entienden mal el problema de la redundancia. No puedes cambiarle la llanta a un coche en movimiento. Tienes que pararlo.
Mi padre tenía dos coches antes de que existiera el Hoy No Circula. Así que si uno fallaba, se subía al otro.
¿No deberíamos estar haciendo lo mismo?
Tenemos una estructura de microservicios y red donde dependemos de la nube, de us-east-1 de Amazon, o de que el proveedor de internet no se caiga. Me ha tocado ver varias empresas y al mismo gobierno empeorando la calidad de la red y de su software. Por ejemplo, en una paraestatal en 2025, México, no podías entrar a google.com muchas veces por un sistema de DNS mal configurado. Literalmente era más rápido conectarme por túnel IP a una máquina externa.
Y pagaban unos cuatro sueldos a personas monitoreando la red.
Después de que salieran los primeros Docker, empezaron los problemas de compartir IP, escalación de privilegios, etc. Algo parecido a entornos shared de sistemas de hospedaje web, donde podías tener la misma dirección que cualquiera que pagara.
Un ejemplo que no se me olvida es cuando una persona empezó a atacar a mi esposa por razones desconocidas en 2002. Insultos por internet. La persona ofensora/agresora tenía un dominio de internet; descubrí que lo hospedaba en un servidor malísimo que se vendía por el equivalente de Mercado Libre, que a su vez lo rentaba a quién sabe dónde. Usando herramientas de internet encontré que en esa dirección IP había otros revendedores, e incluso sitios porno de fetiches como sexo con amputados y sexo con disfraces de extraterrestres.
No puedes poner tus datos en un lugar donde el recipiente está sucio. Se te echa a perder la comida, o los datos.
En el ejemplo del agresor de mi pareja, encontré varios proveedores desde donde podía contratar el host en el mismo servidor. Contraté un paquete y revisé. Podía hacer escalación de privilegios y tomar el control del dominio. Preferí documentar pruebas de otros delitos en el mismo servidor y pasarlos al gobierno de EUA. Eran unos dos meses que llevaba documentando. Cuando iba a pasar el reporte al HSI/FBI por la ley RICO de EUA, el servidor desapareció.
Regresando aDocker, el problema es que en su momento usar los lineamientos simples de defensa de Docker llegó a ser tan complicado que incluso hay guías del Departamento de Defensa de EUA para hacer un hardening de Kubernetes o de Docker. No es bonito y no es rápido.
Tener vecinos es relativamente peligroso. Como vivir en un departamento: tienes a veces más trato con vecinos que siendo dueño de tu casa. Yo tengo de los dos y lo veo a cada rato. En una casa sigues menos normas que en un departamento. Cada uno tiene su lugar.
Los contenedores a su vez son importantes para mover mercancías de un lugar a otro, como los que van en barcos. Quizás has oído de la forma de enviar mercancía agrupada por pallets, o términos de compras como INCOTERMS, que son datos comerciales de cómo pasas de un lado a otro.
Pero a un ladrón, corrupto, o empleado descuidado no les importan las salvaguardas. Algunos piensan que es más fácil entrar a robar una casa si no estás, que a un edificio. Lo que importa realmente es dónde están tus valores, como una caja fuerte.
Cuando sirves agua de jamaica en un vaso, sí, se pierden algunas gotas. Pero no puedes hacer nada real si estás basándote en una jarra rota. Puedes duplicar la jarra, echarle más agua, pero no cambia tu saldo del banco. En realidad sí, pero lo disminuye. Baja tu capacidad de control y suben tus gastos.
En la paraestatal que he mencionado de la vida real, el servidor fallaba de manera regular cada tres meses, uno o dos días. Lo que yo hacía era tener listo un VPS en otro lugar, que me tardaba 15 minutos en levantar con LAMP, 10 minutos en subir código y respaldo, y podían trabajar de manera más eficiente con un VPS de 10 USD que con la tecnología de Kubernetes, Azure y Docker.
El entorno donde sueltas tu código es muy importante. Tus vecinos son parte de ese entorno. Por ejemplo, supe que una facultad del IPN se negó a usar servidores compartidos por el manejo del IP en 2020. Los entiendo.
Tienes otro caso que yo pongo como ejemplo: el servicio social. ¿Qué pasa si estás en una universidad o trabajo donde hacen prácticas de salud? O sea, universidad de medicina, odontología, enfermería, o incluso en un rastro de aves como el ejemplo que mencionamos. Necesitas un botiquín básico, alguien que sepa dar primeros auxilios, y tú como sistemas una conexión de internet independiente, porque de ello puede depender salvar una vida humana.
No arreglas nada limpiando una posible jarra derramada cuando tu jarra está rota.
Si tu máquina virtual pasa por diez o doce firewalls dentro de tu oficina para llegar a Azure o a AWS, no tienes un punto de falla: tienes demasiados puntos de falla. Todo funciona siempre y cuando lo demás funcione. Y detectar problemas puede ser caótico. Yo evito usar AWS, Google Cloud o Azure porque no tengo control sobre las jarras rotas en medio. Que no paguen a tiempo, que el internet esté mal. Una cadena se rompe por lo más delgado.
Veo mientras escribo esto personas que se preparan para el concierto de Shakira del 27 de febrero. Que publican videos, y no es malo. Esto es Africa. Esto es euforia. Puedes sentirte a la última moda de la tecnología usando tu iPhone 25, o poniendo en tus estados que vas al concierto de Shakira y subir un video de TikTok. No es malo Shakira, no es malo el iPhone.
El problema es si tienes una jarra rota.
Hay un libro interesante llamado “Los elefantes no muerden”, que se basa en la idea de que descuidamos los detalles. Que casi todos los humanos sensatos corren porque ven venir al elefante, pero no ven los mosquitos, que son los que te dan molestias. Es un equilibrio entre evitar mosquitos y literalmente atender al elefante en la habitación que nadie quiere ver.
¿Cuánto tiempo te tardas en replicar tu stack o tecnología si se rompe? No te cases con la tecnología de Azure o Amazon, no te cases con la tecnología de un LLM. Por ejemplo, a veces Claude no me responde, y hoy tuve que revisar los números de una cotización de hospedaje web con Gemini porque Copilot se negó a funcionar en el navegador.
Mi padre y yo nos cambiamos de coche si uno se descompone y arreglamos el otro. Levantaba yo un VPS de 10 USD mejor que el servidor Azure oficial en 20 minutos, y tres horas en total. Me he tenido que cambiar de un proveedor a otro cuando el servicio queda con 9 horas sin conexión. Yo me doy cuenta; el proveedor no se da cuenta.
La mayor parte de los negocios destruidos que he visto, de empresas que no pueden operar, incluido gobierno, y empresas que cierran, es porque tienen una jarra rota, o cambian de jarra perdiendo datos en cada una de ellas. “Sin obras no hay sobras”, dice un refrán de un político mexicano. Hay muchas cosas innecesarias porque alguien recibe comisión.
Tú respondes de la integridad de los datos, de la mesa, del mantel. Pero si quieren que hagas eso sin pagarte por la responsabilidad de la nube, no lo hagas. No seas un chivo expiatorio si no quieren tener una conexión de red redundante.
Hoy el hype son los Agentes. Supuestos empleados a los que supuestamente no les pagas.
Pero un agente es un empleado que toma decisiones en tu entorno. Si tu entorno es una jarra rota o un servidor compartido con ‘extraterrestres’, el agente solo va a acelerar el desastre. No puedes delegar la inteligencia a una IA si no tienes el control del suelo donde pisa.
No todos los empleados son iguales. El junior te formatea la PC por error. Hay cierta paranoia o realismo. No todos deben poder ver todo. Si usas agentes vas a terminar mordido por el elefante en la habitación. Y tu pusiste allí el elefante.
Los agentes en programación actual no funcionan por dinero en México y LATAM. Te casas con una tecnología, y ya han habido casos actuales de personas que pierden el contenido de su correo o que les formatean el disco.
Los agentes no tienen el entorno amplio. Y si les das control total van a ser varias jarras rotas que no deberías tener en primer lugar. No puedes poner todos los huevos en una sola canasta.
Hay una manera diferente de hacerlo. Empieza por pensar cuánto tiempo te tardas en recuperarte de un desastre de infraestructura, y si no es menos de 12 horas, empieza a moverte ya. El elefante te va a morder.
En el siguiente episodio de “Domando la Caja Negra” verás la gran ventaja de tener LLMs en lugar de sistemas de agentes, que es la moda de los últimos cuatro meses y que no funciona en la realidad LATAM por dinero.
Fundamento: No te sirve de nada una jarra rota, ni tener la información en cuatro jarras astilladas diferentes que se van a romper en cualquier momento. “Sin obras no hay sobras” te llevó a eso.
Esto son los fundamentos: Decisiones técnicas con consecuencias reales, sin hype, con casos reales.
