La persona que de verdad diseña el comportamiento operativo de tu plataforma —los modos de falla, la curva de costo, la latencia que el cliente termina viendo— casi nunca es la persona que firma el diagrama de arquitectura. Esa asimetría no es cosmética: define cuándo tu plataforma se rompe, cuánto cuesta y a quién despiertan a las 2 AM.
La tesis es incómoda: el platform engineer es el arquitecto real de tu plataforma, pero la organización está estructurada para no dejarlo decidir como tal. Eso produce una zona gris donde la responsabilidad operativa y la autoridad de diseño viven en personas distintas, y la plataforma paga la cuenta.
Nombrar servicios no es diseñar
Una caja con "Lambda" en un diagrama de arquitectura no es un diseño. Es un sustantivo. Diseñar con Lambda significa, como mínimo, decidir cinco cosas que el diagrama no muestra:
- El límite de concurrencia reservada por función y qué pasa cuando se excede (throttling, no degradación gradual).
- El comportamiento de retry para invocaciones asíncronas: 3 intentos por default, con DLQ obligatoria si no querés pérdida silenciosa.
- El path de IAM trust entre el invocador y la función, y cómo se renuevan credenciales dentro de la VPC.
- El cold-start tax del runtime elegido: Python ronda los 200-400 ms (sub-200 ms en arm64); Java sin SnapStart se va a ~5 segundos — SnapStart lo baja a ~180 ms.
- El presupuesto de file descriptors y conexiones outbound contra el límite regional de NAT Gateway.
Nada de eso aparece en el diagrama. Aparece en el postmortem.
Y ese era solo Lambda. El patrón se repite cada vez que el arquitecto traza una flecha entre dos servicios. Una sola línea —"esta función accede a este bucket"— se ramifica en seis superficies de policy distintas que alguien tiene que diseñar, validar contra least-privilege y firmar:
El arquitecto que pinta Lambda → DynamoDB sin enumerar al menos esos cinco aspectos no está diseñando: está jugando a un Pictionary caro. Y el platform engineer —el que sí los enumera— termina tomando esas decisiones por defecto, en commits, sin firma. Las decisiones existen; solo no tienen autor reconocido.
El RACI que falla en producción
La separación entre arquitecto y operador no es estúpida. En organizaciones grandes distribuye carga cognitiva y permite especialización. El problema empieza cuando la autoridad de decisión y la responsabilidad operativa viven en personas distintas, y la persona con responsabilidad operativa no tiene firma.
Eso se ve concretamente así: el arquitecto firma el diagrama; el platform engineer ajusta silenciosamente el config para que el diagrama funcione; el incidente ocurre; el postmortem dice "configuración incorrecta"; la decisión arquitectónica original que forzó esa configuración nunca se discute. Repetí el ciclo durante seis meses y vas a tener un sistema cuya forma real nadie reconoce como propia.
Y acá hay un punto que merece ser explícito: "ajustar la config" debería ser una conversación en una reunión real, no un commit en silencio. Cuando el platform engineer cambia un retry budget, un IAM condition key, una grant de KMS o el concurrency limit de una función, está tomando una decisión arquitectónica. Pero el lenguaje de la organización —"tunear", "ajustar", "configurar"— la disfraza de tarea menor. El cambio no entra a una agenda, no se discute en una reunión de diseño, no requiere acuerdo previo. Pasa CI verde y se asume como detalle. Si rompe, todos descubren al mismo tiempo que era una decisión arquitectónica disfrazada de configuración — y que nadie la firmó porque nadie la registró como tal.
La pregunta práctica que separa orgs maduras de las que no: ¿qué ajustes de config requieren acuerdo previo en una reunión, y cuáles no? El default —"si es grande va a reunión, si es chico no"— falla porque casi todo se siente "chico" cuando lo mirás de cerca. Una org seria escribe una lista explícita (cambios de IAM policy, retry budgets, concurrency limits, tipos de instancia productivos, ventanas de mantenimiento) y trata al resto como rutina. Sin esa lista, el operador decide solo y la org pretende no haber decidido.
Es un patrón que Dan Davies, en The Unaccountability Machine (2024), llama accountability sink: el rol con autoridad nominal no asume las consecuencias, y el rol con consecuencias no tiene autoridad nominal. En seguridad de aviación se eliminaron estos patrones hace décadas mediante checklists firmados por la persona que opera. En plataformas siguen siendo norma.
Counterargument honesto: a veces el arquitecto sí tiene contexto que el operador no — visión cross-equipos, decisiones de compliance, restricciones contractuales con el cliente. La crítica acá no es "saquemos al arquitecto"; es "que firme también la persona que va a operar la decisión, o que reasignen la firma a quien sí la opera". Una de las dos. No las dos a la vez.
Dos disciplinas, un mismo título
"DevOps" como título oculta dos disciplinas distintas. Vale la pena nombrarlas porque la confusión la paga el negocio.
La primera es el ingeniero de sistemas vuelto cloud: persona que pasó años configurando kernel parameters, leyendo dmesg, dimensionando IOPS contra discos físicos, sabiendo cuándo TIME_WAIT empieza a doler. Cuando esta persona mira AWS, ve hardware abstracto pero hardware al fin: SQS tiene una garantía de entrega, no magia; RDS tiene un IOPS budget, no infinito; Lambda tiene un límite de concurrencia, no elasticidad sin techo. Razona en blast radius y en presupuestos finitos.
La segunda es el pipeline engineer: persona que vino de desarrollo de aplicación y aprendió cloud vía CI/CD. Domina GitHub Actions, conoce los hooks de Terraform, sabe configurar runners. Su modelo mental del cloud es declarativo: si el YAML pasa, el sistema funciona. La parte operativa —qué pasa cuando AWS devuelve un 5xx intermitente, cómo se degrada el sistema bajo presión, cómo se comporta un retry budget agotado— es menos natural.
Ambas son necesarias. El error es asumir que son intercambiables. La primera está siendo subestimada en muchas orgs porque la segunda produce artefactos visibles (PRs verdes, pipelines colorados, dashboards limpios). La primera produce ausencia de incidentes — un output más difícil de notar y casi imposible de premiar en un ciclo de performance review.
Cuando los planes de carrera tratan a ambas como un solo "DevOps Engineer L4", la organización está diciendo, sin darse cuenta, que prefiere la disciplina visible.
El cliente no sabe con quién está hablando
Hay un cuarto rol implícito que pocas orgs quieren nombrar: el platform engineer como interface técnico con el cliente.
Cuando algo falla y el cliente quiere una explicación, no llaman al arquitecto. Llaman a quien sepa responder. Y la persona que sabe responder es la que tocó el sistema. El platform engineer termina en calls con clientes, explicando por qué us-east-1 tuvo un evento, por qué la migración tomó cuatro horas en vez de una, por qué no se puede subir el throughput sin dispararse el costo.
Eso no aparece en su job description. No aparece en su compensación. Pero la empresa cobra por ese tiempo —y el cliente lo percibe como parte del servicio.
Este es el caso más claro de extracción silenciosa de valor en plataformas: la persona hace trabajo de customer engineer sin el título ni el pago de customer engineer. La org lo factura, pero internamente lo etiqueta como "soporte interno".
Cómo se ve el gris en el calendario
Algunos síntomas concretos para diagnosticar si estás en la zona gris:
- El arquitecto pregunta "¿podemos usar X?" al platform engineer, y ese sí/no es la decisión real aunque no aparezca firmada.
- Los tickets se asignan a "Platform" sin propietario nominal; el platform engineer los autoasigna por defecto.
- Los diagramas de arquitectura no muestran IAM, no muestran VPC, no muestran quotas, no muestran límites de servicio.
- Los postmortems atribuyen incidentes a "configuración" sistemáticamente, pero nunca cuestionan la decisión arquitectónica original.
- Las calls técnicas con clientes requieren tu presencia "para apoyo", aunque seas quien lleva la conversación.
- Los ADRs (Architecture Decision Records) los escribe quien no los va a operar.
Si más de tres aplican, no es una percepción: es el patrón.
Qué hacer si sos el gris
El cierre tiene que ser accionable. Tres movimientos que no requieren reorganización pero sí incomodidad:
1. Documentá tus decisiones implícitas como ADRs públicos. Si tomás la decisión —porque sos quien sabe que el path A escala y el path B no— escribila. Un ADR con tu nombre vale más que cien commits silenciosos. Si la decisión es importante, debe tener firma. Si tu firma molesta a alguien, esa es exactamente la conversación que la org necesita tener.
2. Pedí la firma de quien la asume nominalmente. Cuando el arquitecto delega ("decidí vos"), convertí esa delegación en un comentario en el ADR o un correo. La forma exacta importa menos que el rastro. Si la decisión sale mal, la atribución existe; si sale bien, también.
3. Negociá explícitamente el rol de interface con el cliente. Si tu calendario tiene más de dos horas semanales con clientes técnicos, eso es un rol, no un favor. Pedí que aparezca en el job description, en el título o en la compensación. La empresa cobra por ese tiempo; vos también deberías.
El problema no es de orgullo. Es de seguridad operacional. Una plataforma diseñada por alguien que no la opera, que no habla con el cliente que la usa y que no paga el costo cuando se rompe, tiene un componente crítico no documentado: la persona invisible que la mantiene viva.
Esa persona tiene un nombre. Probablemente es el tuyo.
Fuentes
- The Unaccountability Machine — Wikipedia — resumen del libro de Dan Davies (2024) donde introduce el concepto de accountability sink, con sus raíces en la cibernética de Stafford Beer.
- Dan Davies on accountability sinks — Bloomberg (2024) — entrevista de fondo con el autor explicando el concepto y por qué proliferan.
- Under the hood: how AWS Lambda SnapStart optimizes function startup latency — AWS Blogs — fuente primaria de los números de SnapStart citados.
- AWS Lambda Cold Start Optimization in 2025 — Zircon Tech — benchmarks que corroboran 200-400 ms en Python y ~5 s en Java sin SnapStart.
Comentarios
Enviando…