Arquitectura que no depende de nadie
Una arquitectura no fracasa el día que se cae, sino el día que se va quien la entendía. Qué hace que un sistema sobreviva a su autor y cómo se diseña para que eso ocurra.
LeerPublicaciones
Artículos
Notas de trabajo sobre arquitectura cloud, costo y gobierno. Lo que aprendemos operando, escrito para que sirva.
Arquitectura Cloud
12 artículos
Ver línea
Arquitectura cloud que no depende de nadie
Doce artículos sobre cómo se diseña una arquitectura cloud que sobrevive a quien la hizo: decisiones y requisitos escritos, diseño por zonas, datos primero, documentación que no envejece, homologación contra un estándar, el costo como requisito y la recuperación probada antes de necesitarla.
Fundamentos
Decidir por escrito
Un registro de decisión de arquitectura ocupa una página y ahorra semanas. Qué debe contener, cuándo escribirlo y cómo evitar que se convierta en burocracia.
LeerLos requisitos que nadie dice
Nadie pide por escrito que el sistema se recupere en una hora o que no pierda más de cinco minutos de datos, pero todos lo esperan. Los atributos de calidad que deciden una arquitectura y cómo hacerlos explícitos.
LeerDiseñar
Diseñar por zonas
Antes de elegir servicios hay que dibujar fronteras. Zonas de red, de confianza y de entorno: el método para que una arquitectura se entienda de un vistazo y se pueda proteger por partes.
LeerMonolito, microservicios o algo en medio
Los microservicios no son una mejora del monolito: son otro conjunto de compromisos. Qué criterios inclinan la decisión y qué componentes exige cada opción.
LeerLos datos primero
El cómputo se mueve fácil; los datos no. Dónde vive cada dato, cuánto cuesta moverlo, cuánto tarda y qué ley lo obliga a quedarse decide la arquitectura más que cualquier servicio.
LeerMulticloud e híbrido, con criterio
Usar varias nubes o combinar nube con infraestructura propia puede ser la decisión correcta o una fuente de complejidad sin retorno. Cuándo conviene, cuándo no y qué patrón elegir.
LeerDocumentar y validar
Documentación que no envejece
La documentación de arquitectura muere el día que se separa del sistema. Tratarla como código, con una fuente única y salidas generadas, es lo que la mantiene viva.
LeerAntes de arreglar, saber qué hay
Todo sistema heredado tiene una parte documentada y otra que solo existe en producción. Cómo se hace un levantamiento que descubre lo que realmente corre antes de cambiar nada.
LeerHomologar sin frenar
Revisar arquitecturas contra el estándar de la organización no tiene por qué ser un cuello de botella. Con una norma escrita y un dictamen clasificado por severidad, la revisión ayuda en vez de frenar.
LeerOperar
El costo es un requisito de diseño
Una arquitectura que cumple todo pero cuesta el doble de lo previsto no está bien diseñada. Estimar el costo por componente antes de desplegar, y por qué corregirlo tarde sale tan caro.
LeerDiseñar para fallar
Todo falla tarde o temprano. Una arquitectura madura decide de antemano cuánto tiempo puede estar caída y cuántos datos puede perder, lo diseña para cumplirlo y lo prueba antes de necesitarlo.
LeerIngeniería FinOps
12 artículos
Ver línea
FinOps, del concepto a la operación
Doce artículos para pasar de una factura que nadie entiende a un costo cloud que se explica, se asigna y se decide. Empieza por lo que es un dato de costo, sigue con cómo se construye el pipeline que lo normaliza y lo corrige, y termina en cómo se presupuesta, se optimiza y se opera, también para la inteligencia artificial.
Fundamentos
El costo cloud no es una factura
La factura cloud dice cuánto gastaste, no por qué. Qué preguntas no responde y cómo empezar a convertir el costo en información para decidir.
LeerFinOps no es recortar costos
FinOps no es un programa de ahorro. Es una forma de trabajar que convierte el costo cloud en una decisión de negocio, con un ciclo que se repite.
LeerAnatomía de un dato de costo
Una línea de la factura cloud parece un número. En realidad combina uso, tarifa, descuentos y compromisos. Entender esas piezas es el primer paso para no sacar conclusiones equivocadas.
LeerConstrucción
FOCUS explicado
FOCUS es el estándar abierto que da a la facturación de todos los proveedores las mismas columnas y el mismo significado. Qué resuelve, qué no, y por qué conviene adoptarlo desde el principio.
LeerArquitectura de un pipeline de costos
Del archivo crudo del proveedor al dato que sirve para decidir hay seis capas, y cada una existe por una razón. Así se diseña un pipeline de costos que se puede auditar y que no depende de nadie.
LeerCorregir antes de confiar
El dato de facturación no llega listo para usarse. Duplicados, compromisos mal repartidos y cargos mal clasificados distorsionan cualquier análisis. Cómo detectarlos y corregirlos con reglas.
LeerAsignar lo que no tiene dueño
Sin asignación no hay responsables, y sin responsables el costo no baja. Etiquetas, cuentas y reglas para atribuir cada costo a un equipo, una aplicación y un producto, incluido lo compartido.
LeerDecisión
La métrica de unidad
El costo total sube cuando el negocio crece, y eso no dice nada. El costo por unidad de negocio sí: dice si cada cliente, transacción o producto cuesta más o menos que antes.
LeerPresupuesto y previsión
En cloud el gasto se decide cada vez que alguien despliega. Presupuestar es estimar antes de desplegar, prever con la tendencia real y enterarse del desvío antes de que llegue la factura.
LeerOptimizar: tarifa contra uso
Para bajar el costo cloud hay dos palancas, cuánto se consume y a qué precio. El orden en que se mueven importa, y equivocarse de orden encierra a la organización en compromisos que no necesitaba.
LeerOperación
FinOps sin equipo de FinOps
Una pyme no necesita un área de FinOps para practicarlo. Necesita responsables claros, una revisión mensual corta y decisiones registradas. Un modelo operativo mínimo que funciona.
LeerFinOps para IA
El gasto en inteligencia artificial llega por caminos distintos al cloud tradicional y crece sin que nadie lo vea completo. Cómo llevarlo al mismo formato, asignarlo y medirlo por funcionalidad.
LeerCiberseguridad
13 artículos
Ver línea
La seguridad se demuestra
Cumplimiento verificado, de la infraestructura al código: conocer lo que ve un atacante, convertir los marcos en controles propios con evidencia que se recoge sola, proteger por capas (privilegios, software, datos y acceso híbrido), registrar lo que importa, detectar con pocas alertas buenas, responder con un guion ensayado y lograr que lo seguro sea también lo más fácil.
Demostrar, no declarar
La seguridad se demuestra
«Somos seguros» no es una respuesta. La única respuesta útil a «¿cómo lo sabes?» es una evidencia: qué control existe, quién lo revisa, cuándo se comprobó por última vez y qué resultado dio.
LeerLo que ve un atacante
No se puede proteger lo que no se sabe que existe. La superficie de ataque es todo lo que alguien de fuera puede alcanzar: direcciones, puertos, dominios, servicios olvidados. Inventariarla es el primer control.
LeerDe los marcos a los controles
Un control, varios marcos
ISO 27001, NIST CSF, CIS, exigencias de clientes y de la regulación: cada marco pide lo suyo, y casi todos piden lo mismo con otras palabras. Un catálogo propio de controles, cada uno mapeado a todos los marcos, evita hacer el mismo trabajo cinco veces.
LeerControles con evidencia
Un control sin evidencia es una intención. Cada control necesita un dueño, una forma de comprobarlo, una frecuencia y un registro del resultado. Con eso, una auditoría deja de ser una búsqueda desesperada de pruebas.
LeerEvidencia que se recoge sola
El cumplimiento anual retrata un día; el continuo retrata todos. Cuando la mayoría de los controles se comprueban solos y guardan su resultado, el estado de seguridad deja de ser una sorpresa en cada auditoría.
LeerProteger por capas
Mínimo privilegio, de verdad
Todos dicen aplicar el mínimo privilegio. Casi nadie mide la distancia entre los permisos que tiene cada identidad y los que de verdad usa. Esa distancia es, en la práctica, la superficie de ataque interna.
LeerEl código también es superficie
La mayor parte del código que se despliega no lo escribió la organización: son dependencias, imágenes base y herramientas de terceros. Saber qué contiene cada artefacto, comprobarlo en cada construcción y firmar lo que se publica cierra una puerta que casi nadie vigila.
LeerCifrar no basta
Casi todo está cifrado hoy por defecto, y aun así los datos se filtran. La protección real depende de quién controla las claves, de saber qué datos son sensibles y de dónde están, y de que el acceso descifrado esté tan vigilado como el cifrado.
LeerAcceso híbrido sin red abierta
Entre la infraestructura propia y varias nubes, el acceso tradicional abre una red entera para dar acceso a un solo sistema. El acceso por aplicación, verificando identidad y dispositivo en cada conexión, da a cada persona solo lo que necesita.
LeerDetectar y responder
Registrar lo que importa
Registrarlo todo es caro y no garantiza nada; no registrar lo importante es ceguera. Qué eventos guardar, dónde, cuánto tiempo y protegidos contra quién es una decisión de diseño, no una configuración por defecto.
LeerPocas alertas, buenas
Mil alertas al día no protegen a nadie: se ignoran. La detección útil son pocas reglas, cada una ligada a un riesgo concreto, con un responsable y una acción prevista, que se afinan hasta que casi todas las alertas significan algo.
LeerResponder con un guion
Un incidente de seguridad no es el momento de decidir quién hace qué. La respuesta funciona cuando existe un guion escrito, con roles, pasos y decisiones previstas, y cuando se ha ensayado antes de necesitarlo.
LeerSeguridad que no frena
Cuando la seguridad se vive como un obstáculo, los equipos la rodean. Cuando lo seguro es también lo más fácil, porque viene incluido en la plantilla, la plataforma y las reglas, se cumple sin pedirlo.
LeerGobierno Multicloud
11 artículos
Ver línea
Organización primero, automatización después
Cómo se gobiernan varias nubes sin frenar a los equipos: responsables con nombre y decisiones en el nivel que les corresponde, una norma que se puede cumplir y evoluciona, excepciones con fecha de caducidad, estructura de cuentas, una sola identidad, políticas que se heredan y un gobierno que se mide y se versiona.
Organización primero
Organización primero, automatización después
Automatizar una organización desordenada no la ordena: multiplica su desorden a la velocidad de las máquinas. Antes de las herramientas de gobierno hacen falta tres cosas mucho más simples.
LeerDominios, roles y responsables
Un área de TI no se organiza por personas ni por herramientas, sino por dominios de responsabilidad. Cada dominio tiene roles, y cada rol tiene entregables con un dueño. Escrito y versionado, ese mapa acaba con el trabajo duplicado y con lo que nadie hace.
LeerQué se decide en cada nivel
Si todo se decide arriba, nada avanza. Si todo se decide abajo, cada equipo hace lo suyo. Separar lo estratégico, lo táctico y lo operativo, con su ritmo y su forma de escalar, es lo que permite decidir rápido sin perder el rumbo.
LeerLa norma
Una norma que se pueda cumplir
Las normas de TI suelen fallar por exceso: demasiado largas, demasiado vagas, imposibles de comprobar. Una norma útil es corta, neutra, dice qué es obligatorio y qué no, y cada regla se puede verificar.
LeerLa vida de una norma
Una norma que no cambia acaba ignorada; una que cambia sin aviso acaba incumplida. Tratarla como un producto con versiones, propuestas, revisión, periodo de transición y retirada es lo que la mantiene viva y respetada.
LeerExcepciones con fecha de caducidad
Toda norma tiene excepciones legítimas. El problema no es que existan, sino que se olviden. Una excepción sana tiene dueño, motivo, riesgo aceptado y fecha de caducidad, y vive en un registro que alguien revisa.
LeerVarias nubes, un gobierno
La estructura de cuentas es la primera política
Antes de cualquier regla automática, la forma en que se organizan cuentas, suscripciones y proyectos ya decide quién puede hacer qué, qué se aísla de qué y cómo se reparte el costo. Es la decisión de gobierno más difícil de cambiar después.
LeerUna identidad para todas las nubes
Con tres nubes y decenas de cuentas, gestionar usuarios en cada una es inviable y peligroso. Un solo origen de identidad, roles definidos una vez y accesos temporales para lo delicado resuelven la mayor parte del problema.
LeerPolíticas que se heredan
Una regla aplicada en lo alto de la jerarquía de cuentas llega sola a todas las de abajo, incluidas las que se creen mañana. Combinar reglas que impiden con reglas que detectan permite gobernar decenas de cuentas sin revisarlas una por una.
LeerMedir y evolucionar
Medir el gobierno
Un gobierno que no se mide se juzga por anécdotas: el bloqueo de la semana pasada, el incidente del mes anterior. Cuatro indicadores sencillos dicen si la norma se cumple, si las excepciones están bajo control y si el gobierno ayuda o estorba.
LeerEl gobierno también se versiona
El gobierno no es un proyecto que se termina, sino un sistema que evoluciona con la organización. Versionarlo, anunciar sus cambios y medir cómo se adoptan es lo que evita tanto el estancamiento como el caos.
LeerAutomatización e IaC
14 artículos
Ver línea
Infraestructura que se puede reconstruir
Del clic manual en una consola a una infraestructura que se puede reconstruir desde su código: declarar en lugar de ordenar, cuidar el estado, reutilizar con módulos, leer el plan y su costo antes de aplicar, mantener cada servidor como debe ser, cambiar sin miedo y automatizar la operación con criterio, incluido saber qué no automatizar.
Del clic al código
Infraestructura que se puede reconstruir
Si mañana desaparece todo el entorno, ¿cuánto se tarda en tenerlo igual que hoy? La respuesta mide mejor que ninguna otra la madurez de una infraestructura.
LeerEl problema de los clics
Las consolas web de los proveedores cloud son cómodas y peligrosas a la vez. Cada clic cambia la infraestructura sin dejar un rastro útil, y con el tiempo cada entorno se convierte en una pieza única que nadie sabe reproducir.
LeerDeclarar, no ordenar
Un script dice qué pasos dar; una declaración dice cómo debe quedar. La diferencia parece pequeña y lo cambia todo: qué pasa si se ejecuta dos veces, si algo ya existía o si a mitad de camino falla.
LeerEl código de la infraestructura
El estado, la memoria de la infraestructura
Entre el código y la infraestructura real hay una tercera pieza que casi nadie ve hasta que falla: el estado. Dónde se guarda, quién puede escribirlo y cómo se protege decide si la infraestructura como código es segura o un riesgo.
LeerMódulos, piezas que se reutilizan sin copiar
Copiar el código de un entorno para crear otro funciona una vez. A la tercera copia, cada una es distinta y corregir un error obliga a buscarlo en todas. Los módulos resuelven eso con una sola definición y parámetros por entorno.
LeerVer el plan antes de aplicar
Antes de tocar la infraestructura, la herramienta puede decir exactamente qué va a crear, modificar y destruir. Leer ese plan, y exigir aprobación cuando incluye algo destructivo, evita la mayoría de los desastres.
LeerEl costo, dentro del plan
Si el plan de un cambio dice qué recursos se crean, también puede decir cuánto costarán al mes. Mostrar esa cifra en la revisión cambia conversaciones que antes se tenían cuando ya llegaba la factura.
LeerCada servidor como debe ser
Líneas base, el servidor que debe ser
Crear un servidor con código es la mitad del trabajo. La otra mitad es que, meses después, siga configurado como se definió: paquetes, usuarios, accesos, parches. Eso se escribe como una línea base y se comprueba con regularidad.
LeerDetectar la deriva
La deriva es la distancia entre lo que dice el código y lo que existe de verdad. Siempre aparece; lo que distingue a una infraestructura sana es que la detecta pronto y decide qué hacer con cada diferencia.
LeerCambiar sin miedo
Vuelta atrás de verdad
Todo plan de cambio dice cómo avanzar; pocos dicen cómo retroceder. En infraestructura, volver atrás no siempre es deshacer: a veces es mantener lo anterior vivo hasta estar seguro de lo nuevo.
LeerReglas como código
«Ningún almacenamiento público», «todo cifrado», «nada sin etiquetas de costo». Si estas reglas solo están en un documento, se incumplen. Si están en código, se comprueban en cada cambio, antes de aplicarlo.
LeerLo heredado también entra
Casi nadie empieza de cero. Hay años de infraestructura creada a mano que también tiene que entrar en el código. No se hace de golpe ni se reconstruye todo: se incorpora por partes, empezando por lo que más riesgo tiene.
LeerAutomatizar la operación
Procedimientos que se ejecutan solos
Un procedimiento escrito en un documento depende de que alguien lo encuentre, lo lea bien y no se salte un paso a las tres de la mañana. El mismo procedimiento como código se ejecuta igual cada vez, y llama a una persona solo cuando hace falta criterio.
LeerQué no conviene automatizar
Automatizar no siempre compensa. Hay tareas tan raras, tan variables o tan arriesgadas que el script cuesta más de lo que ahorra, o hace más daño del que evita. Saber distinguirlas es parte del oficio.
LeerIngeniería de Plataforma
15 artículos
Ver línea
Software que se puede auditar
La vida de una aplicación dentro de una plataforma gobernada: por qué una plataforma es un producto, cómo nace una aplicación, de dónde saca su verdad, cómo se construye y se despliega sin sorpresas, cómo se aprende de cada fallo y cómo trabaja la IA cuando las reglas las escriben las personas.
Por qué
Software que se puede auditar seis meses después
Seis meses después de desplegar, alguien pregunta qué versión corre, quién la aprobó y por qué se hizo así. Si la respuesta depende de la memoria de alguien, la plataforma no está gobernada.
LeerUna plataforma es un producto interno
Una plataforma interna fracasa cuando se impone y triunfa cuando se elige. Tratarla como un producto, con usuarios, un camino recomendado y algo que ganar al usarlo, es lo que la diferencia de una lista de prohibiciones.
LeerAntes del código
Fases y compuertas
Una aplicación pasa por fases reconocibles, de la idea a producción. Entre fase y fase hay una compuerta con nombre, criterio y responsable. Así se sabe siempre en qué punto está cada cosa y quién dijo que podía avanzar.
LeerLa especificación manda
Escribir qué se va a construir antes de construirlo parece lento. Es lo más rápido que existe, porque cada ambigüedad resuelta en un párrafo es una semana de rehacer código que no se pierde.
LeerEmpezar siempre igual
Cuando cada aplicación nace con la misma estructura, cualquiera del equipo sabe dónde está cada cosa en cualquier repositorio. La plantilla de aplicación es la pieza más modesta de una plataforma y una de las que más tiempo ahorra.
LeerUna sola verdad
Un solo registro para todo
Qué aplicaciones existen, en qué puerto escuchan, con qué dirección se publican y quién es su dueño. Si esa información vive en cinco sitios, tarde o temprano dos dirán cosas distintas.
LeerSecretos con nombre, nunca con valor
Una contraseña en un repositorio es una contraseña publicada, aunque el repositorio sea privado. El repositorio debe saber qué secretos necesita cada aplicación; solo un gestor de secretos debe saber su valor.
LeerEstado y bitácora, la memoria del proyecto
Dos documentos sencillos sostienen la continuidad de un proyecto. El estado dice dónde está hoy; la bitácora cuenta cómo llegó hasta ahí. Uno se sobrescribe, el otro nunca se edita.
LeerConstruir y desplegar
Construir una vez, desplegar por digest
Si en producción se despliega algo distinto de lo que se probó en aceptación, la aceptación no sirvió de nada. Construir una sola vez y mover siempre el mismo artefacto, identificado por su huella, cierra esa puerta.
LeerEntornos que se parecen de verdad
Aceptación solo sirve si se parece a producción. Qué puede cambiar entre entornos, qué no debe cambiar nunca y cómo mantener esa diferencia escrita y pequeña.
LeerQue falle la construcción, no la producción
Todo lo que se puede comprobar sin criterio humano debe comprobarse antes de publicar, y si falla, debe detenerlo todo. Mejor un despliegue roto con un mensaje claro que un error en manos de un usuario.
LeerOperar y aprender
Qué corre, dónde y por qué
Desde cualquier servicio en producción debería poder recorrerse el camino hacia atrás hasta el requisito que lo justifica. Esa cadena de trazabilidad es lo que convierte una auditoría de semanas en una consulta de minutos.
LeerCada fallo deja una regla
Un incidente resuelto que no cambia nada volverá a ocurrir. La forma de aprender de los fallos es convertir cada uno en algo permanente: una prueba, una validación, una regla o una decisión escrita.
LeerIA en la plataforma
Agentes que ejecutan, personas que deciden
Los asistentes de IA ya escriben código, despliegan y documentan. Dentro de una plataforma gobernada pueden hacer mucho trabajo de forma autónoma, siempre que las compuertas que requieren criterio sigan siendo de personas.
LeerLas reglas las escriben las personas
La IA no debería decidir cómo trabaja una organización. Debería aplicar y comprobar las reglas que la organización escribe. Cuando las dos interpretaciones no coinciden, esa diferencia es justo lo que hay que mirar.
Leer