Compartimos nuestro criterio técnico, casos de implementación y aprendizajes de proyectos reales. Contenido orientado a equipos TI y líderes de empresas que enfrentan decisiones tecnológicas complejas
Pregúntale a tu administrador quién entró al clúster Proxmox la semana pasada. En la mayoría de los entornos que revisamos, la respuesta es un nombre de usuario compartido y ningún registro real.
Antes de que la Ley 21.719 te obligue directamente, es probable que te llegue un correo de un cliente grande preguntando cómo estás protegiendo sus datos. Eso ya está pasando en otras industrias.
Julio completo estuvo dedicado a Proxmox: cómo asignar servicios entre VMs y contenedores, cómo construir un respaldo que realmente se pueda restaurar, cuándo el almacenamiento distribuido aporta y cuándo agrega complejidad sin retorno, y cómo mantener el clúster actualizado sin interrumpir la operación.
La pregunta que genera más ansiedad cuando hay que actualizar la infraestructura: ¿cuánto tiempo van a estar caídos los sistemas? En un clúster Proxmox de varios nodos bien diseñado, la respuesta correcta es ninguno.
Hay algo que cambia con la Ley 21.719 en diciembre y que va más allá de las políticas de privacidad y los registros de tratamiento: la forma en que se evalúa si una empresa tomó medidas de seguridad adecuadas para proteger los datos que tiene.
El cliente había hecho la tarea. Tres nodos Proxmox funcionando hacía más de un año, respaldo operativo, un administrador dedicado.
La decisión de arquitectura de almacenamiento en Proxmox siempre tuvo cuatro variables: qué protege cada opción ante una falla, cuánto cuesta operarla, qué red exige, y qué capacidad del equipo requiere. Desde diciembre, con la Ley 21.719 en vigor, hay una quinta: dónde viven los datos y si eso requiere análisis adicional.
Cuando una empresa chilena almacena datos de sus clientes en AWS Virginia, Azure Irlanda o Google Cloud São Paulo, esos datos están bajo la jurisdicción del país donde vive el servidor — no bajo la jurisdicción chilena. Desde diciembre, eso tiene implicancias concretas que muchas empresas medianas no han evaluado.
La frase apareció en la primera reunión, dicha con total tranquilidad: los respaldos funcionan, corren todas las noches y nunca han dado problemas. Era verdad.
Una estrategia de respaldo se puede evaluar en una página. Si tu empresa puede marcar cada punto de este checklist con evidencia — no con la palabra del proveedor, no con la memoria del administrador, sino con un registro verificable — el respaldo de los datos de tus clientes y empleados es demostrable ante la Ley 21.719.
Hay una conversación que se repite en casi cada diagnóstico de infraestructura que hacemos. Preguntamos: ¿tienen respaldos de sus sistemas críticos? La respuesta es sí, con frecuencia acompañada de una pantalla que muestra una lista de trabajos completados exitosamente la noche anterior.
La conversación empezó con un diagnóstico claro del equipo técnico del cliente: el hardware estaba al límite, la memoria superaba el noventa por ciento de ocupación, y la única salida visible era agregar un servidor. Venían por la cotización.
Hay una forma de asignar servicios entre máquinas virtuales y contenedores LXC que genera evidencia. Y hay una forma que no.
El 1 de diciembre de 2026 entra en vigor la Ley 21.719. La forma en que hoy se segrega datos entre máquinas virtuales y contenedores LXC en Proxmox puede ser, o no, evidencia demostrable de las medidas técnicas que la ley exige. Explicamos por qué la arquitectura de virtualización es la primera línea de cumplimiento.
En la mayoría de las empresas medianas con las que conversamos, la respuesta a la pregunta «¿Tienen respaldos de sus sistemas críticos?» es un rotundo sí. Generalmente, el encargado de TI abre una consola y nos muestra un panel limpio, lleno de “checks” verdes que indican que la copia de seguridad de la noche anterior se completó con éxito.
Open source no es una categoría de herramientas: es un modelo de desarrollo. Usarlo bien requiere el mismo rigor de evaluación que cualquier otra decisión de infraestructura. Elegirlo solo porque es gratuito puede generar más problemas que la solución que reemplaza. Este artículo describe el criterio que Aleph Server aplica antes de recomendar cualquier herramienta open source, y por qué esa distinción importa para una empresa mediana.
La primera reunión con un cliente nuevo en Aleph Server raramente empieza con una propuesta técnica. Empieza con preguntas que a veces incomodan. No para complicar el proceso, sino porque la calidad de la implementación depende en gran medida de la calidad del diagnóstico que la precede. Este artículo describe esas conversaciones y por qué ocurren antes de cualquier propuesta.
La dependencia de una o dos personas clave en TI es el riesgo operacional más frecuente y menos gestionado en empresas medianas. Todos lo identifican. Pocos lo abordan antes de que se materialice como crisis. Este artículo presenta el diagnóstico estructurado y el plan de acción concreto para reducirla de forma progresiva sin interrumpir la operación del negocio.
Los errores más costosos en infraestructura TI de empresas medianas no son técnicos. Son de criterio: herramientas sobredimensionadas para el equipo que las va a operar, procesos sin documentar que dependen de personas clave, y decisiones tomadas bajo presión sin el análisis que las justifique. Este artículo describe los tres patrones más frecuentes, por qué se repiten con consistencia, y qué los detiene.
No todos los proyectos de automatización tienen el mismo ritmo de implementación. La diferencia no está en la complejidad técnica del DAG ni en la capacidad del equipo que lo construye. Está en el estado en que llega el proceso al momento de implementar. Este artículo describe dos proyectos reales con resultados distintos y el aprendizaje que cambió cómo Aleph Server estructura el trabajo previo a cualquier automatización.
Apache Airflow no es solo para ingeniería de datos a escala. Hay procesos de negocio en empresas medianas que dependen de datos, corren de forma manual o con scripts sin monitoreo, y son candidatos directos a orquestación. Este artículo describe tres de esos procesos, la estructura del DAG en cada caso, y el punto de entrada recomendado para implementar sin sobredimensionar.
El mercado de orquestación de datos tiene más opciones que hace tres años. Prefect, Dagster y Mage AI tienen propuestas técnicas sólidas y casos de uso legítimos. Y sin embargo Apache Airflow mantiene su posición como el orquestador más utilizado en producción.
Implementar Proxmox en una empresa mediana chilena tiene particularidades que no aparecen en la documentación técnica internacional. No porque la plataforma sea diferente, sino porque el contexto sí lo es: hardware disponible en el mercado local, capacidad técnica de los equipos, y realidad del soporte disponible en Chile. Este artículo comparte los aprendizajes de proyectos reales.
Una migración a Proxmox bien ejecutada reduce los riesgos al mínimo. Una mal planificada puede generar más problemas de los que resuelve. La diferencia no está en la complejidad técnica de la plataforma: está en la calidad del trabajo previo a la migración. Este artículo presenta el checklist que Aleph Server aplica antes de cualquier proyecto de migración a Proxmox, ordenado por bloques de evaluación con criterio de prioridad.
Migrar a AWS se convirtió en sinónimo de transformación digital para muchas empresas medianas. El problema es que “migrar todo a la nube” es una estrategia de marketing, no una estrategia técnica. Este artículo revisa los escenarios donde cloud público entrega valor real para empresas medianas, los casos donde el costo operacional supera el beneficio, y el criterio que falta en la mayoría de las evaluaciones.
Hay una diferencia entre adoptar una herramienta porque la conoces bien y adoptarla porque pasó el mismo análisis que aplicarías antes de recomendarla a un cliente. En Aleph Server, Proxmox llegó a ser nuestra plataforma de referencia para infraestructura virtualizada por la segunda razón, no por la primera.
La adquisición de VMware por Broadcom en 2023 no fue solo un movimiento corporativo. Para empresas medianas con infraestructura virtualizada, fue un cambio de condiciones concreto: eliminación de las licencias perpetuas, migración forzada a modelos de suscripción por socket, y elevación del mínimo de licenciamiento de 16 a 72 cores. Para una empresa con servidores de baja densidad —que es el escenario habitual en empresas medianas— eso representa un sobrecosto real sin ningún valor adicional.
Cuando una empresa mediana evalúa Proxmox como alternativa a VMware, la primera pregunta que aparece es: ¿qué pierdo? Este artículo revisa las capacidades que las empresas medianas más valoran de VMware, cuáles de ellas Proxmox entrega con resultados equivalentes, y cuáles siguen siendo ventaja de VMware en contextos específicos.
En Aleph Server usamos herramientas open source porque pasan un análisis de criterios concretos, no porque sean gratuitas. Este artículo describe ese proceso de evaluación y por qué la distinción importa para empresas medianas
Apache Airflow no construye agentes de IA: orquesta los procesos que los mantienen confiables en producción. Este artículo describe cómo estructurar un DAG de monitoreo de calidad para agentes de IA, con criterios de diseño y punto de entrada recomendado.
Un agente de IA que funcionó bien en el piloto puede degradar su calidad en producción de forma silenciosa. Este artículo explica por qué ocurre, qué dimensiones debe cubrir el monitoreo y cómo diseñarlo antes del despliegue.
Un cliente llegó convencido de que necesitaba un clúster Proxmox con alta disponibilidad. La recomendación de Aleph Server fue no implementarla todavía. Este artículo explica el análisis detrás de esa decisión y el resultado concreto.
La alta disponibilidad en Proxmox no es solo una configuración: requiere hardware mínimo, red dedicada, almacenamiento compartido y capacidad operacional para ser una garantía real. Este artículo describe los requisitos, los errores frecuentes y cuándo no tiene sentido implementarla todavía.
Proxmox VE lleva más de diecisiete años en producción en entornos enterprise. Este artículo revisa qué muestran las comparaciones de rendimiento disponibles, dónde se producen diferencias reales, y qué criterio aplica Aleph Server al recomendarlo para empresas medianas.
En la mayoría de los proyectos de ML, el monitoreo llega tarde. En Aleph Server se define antes de construir el pipeline. Este artículo explica por qué esa diferencia cambia la calidad del sistema en producción.
Un modelo de ML en producción depende de un proceso orquestado que garantice datos actualizados, transformaciones reproducibles y evaluación continua. Este artículo describe cómo Aleph Server estructura ese pipeline con Apache Airflow.
Entre los datos crudos y el modelo entrenado hay una etapa que define en gran medida la calidad del resultado. Este artículo explica qué es el feature engineering, por qué consume la mayor parte del tiempo en proyectos de ML y cuáles son las consecuencias de hacerlo mal.
Un cliente llegó con la decisión tomada: migrar todo a AWS. Aleph Server frenó la propuesta, hizo el análisis y recomendó algo diferente. Este artículo describe lo que aprendimos de ese proceso.
La dependencia de una o dos personas clave en TI es el riesgo operacional más frecuente y menos gestionado en empresas medianas. Este artículo presenta el diagnóstico y las acciones concretas para reducirlo de forma progresiva.
Es un patrón que se repite: una empresa mediana recibe una propuesta de migración total a la nube. El proveedor
Este artículo describe la implementación de un proceso de automatización de reportes operacionales en una empresa mediana con operaciones en
La automatización de procesos de negocio es una de las iniciativas TI con mayor potencial de impacto en empresas medianas, y también una de las que más frecuentemente se implementa en el orden equivocado. No por falta de criterio técnico, sino porque la presión operacional del día a día hace difícil detenerse a evaluar qué tiene más sentido atacar primero.
La documentación técnica es probablemente el entregable más subestimado en proyectos TI. No el plan previo al proyecto, que suele estar bien desarrollado. Lo que se subestima es la documentación de lo que realmente quedó implementado: la arquitectura resultante, las decisiones que se tomaron en el camino, y los procedimientos que el equipo del cliente necesita para operar el sistema de forma autónoma.
Una migración de infraestructura de virtualización es uno de los proyectos TI con mayor potencial de impacto operacional si se ejecuta sin el orden correcto. No por la complejidad técnica de Proxmox, sino porque los servicios que corren sobre esa infraestructura son críticos y cualquier interrupción tiene consecuencias directas para el negocio.
La adquisición de VMware por Broadcom en 2023 cambió el mercado. Los precios aumentaron entre 3 y 10 veces; el mínimo de licenciamiento pasó de 16 a 72 cores. Para empresas medianas con servidores de baja densidad, eso es un sobrecosto sin valor. Proxmox emerge como alternativa real: 17+ años de desarrollo, código abierto, robustez en producción, y costo accesible.
No todos los clientes llegan con un listado técnico de requerimientos. Algunos llegan con agotamiento. La solicitud real detrás de
¿Tu proceso está listo para Apache Airflow, o vas a crear más problemas de los que resuelves? En Aleph Server usamos un checklist de cinco preguntas para evaluar si un proceso justifica orquestación — y cuándo una solución más simple es la respuesta correcta.
La mayoría de los proyectos de automatización no llegan a producción estable. El patrón se repite con suficiente consistencia como
Parte del trabajo de un partner TI confiable es saber cuándo no recomendar la herramienta más compleja. Este artículo describe cómo Aleph Server evalúa si Apache Airflow es la solución adecuada para un caso específico, y qué alternativas considera cuando no lo es.
Un LLM bien configurado con datos desactualizados producirá resultados incorrectos de forma silenciosa. La orquestación es lo que convierte un piloto funcional en un sistema confiable en producción.
En Aleph Server usamos Apache Airflow como orquestador de referencia para pipelines de Data Science y flujos de IA. No es una apuesta ciega: es una decisión que revisamos en cada proyecto y que se sostiene por razones concretas. Aquí están.