Matthew Liste, vicepresidente ejecutivo y responsable global de infraestructura en American Express, considera que una plataforma tecnológica exitosa no se mide por el número de sus componentes, sino por su capacidad para ocultar la complejidad y ofrecer a los desarrolladores una experiencia estable y clara. Liste basó su presentación en QCon San Francisco en los más de 20 años que ha dedicado a construir plataformas e infraestructuras para sistemas críticos en Goldman Sachs, JPMorgan Chase y American Express.
Las plataformas de las que habló Liste dan servicio a un gran número de desarrolladores internos: unos 20.000 usuarios en American Express y unos 60.000 en JPMorgan Chase. Aunque la escala difiere de la de los proveedores de servicios en la nube, considera que los principios fundamentales se aplican por igual a cualquier equipo que construya una capa de la que dependan otros.
Una buena plataforma oculta la complejidad sin ocultar lo que ocurre
Liste comienza definiendo la plataforma como un conjunto integrado de tecnologías que constituye la base sobre la que se construyen las aplicaciones. La compara con los servicios de agua y saneamiento: el usuario no piensa en la infraestructura que hay detrás mientras funcione, pero la nota inmediatamente cuando deja de funcionar.
Por ello, la experiencia de la plataforma debe ser intuitiva y utilizar componentes compartidos e intercambiables, como bases unificadas para la observabilidad, la identidad y los espacios de nombres. Esta capacidad de composición hace que la plataforma se parezca más a bloques de Lego que a un conjunto de servicios independientes que solo funcionan juntos con un esfuerzo adicional.
La estabilidad, la seguridad y la escalabilidad no son opcionales
Liste identifica lo que denomina «los tres pilares»: estabilidad, seguridad y escalabilidad. El nivel de disponibilidad requerido varía según el valor del sistema; según su presentación, los sistemas de autorización de tarjetas de crédito de American Express funcionan con niveles de hasta seis nueves y siete, mientras que otros sistemas pueden tolerar un mayor tiempo de inactividad.
También hace hincapié en que el éxito inicial puede ocultar problemas de escalabilidad. Una plataforma que funciona bien al principio puede sufrir cuellos de botella cuando aumenta su uso, lo que repercute directamente en la estabilidad. Por eso, los objetivos de nivel de servicio (SLO) deben definirse con los consumidores y cumplirse con el tiempo, no solo el día del lanzamiento.
Actualización continua y reducción del trabajo no diferenciador
Liste considera que mantener la plataforma actualizada es una de las tareas más difíciles y más propensas a posponerse. La acumulación de actualizaciones aplazadas puede encarecer la migración a una versión más reciente y afectar a los clientes. Propone un criterio interno que denomina 0114: cero personas para el mantenimiento periódico gracias a la automatización, capacidad para actualizar todos los componentes de la flota, completar la actualización en menos de un día y realizar un ciclo de actualización cada 14 días o menos.
También insta a no reconstruir aquello que ya está disponible con una calidad suficiente. En lugar de escribir un nuevo motor de PostgreSQL, ofrece como ejemplo la creación de una capa de control que ejecute copias de seguridad diarias en un almacén de objetos, que es la parte necesaria para cumplir los requisitos normativos. La idea es centrarse en el valor que necesita la organización, no en la tarea más interesante desde el punto de vista de la ingeniería.
Decisiones claras y una relación contractual con los consumidores
Los responsables de las plataformas deben escuchar a los clientes, pero no ejecutar todas las solicitudes. Los recursos son limitados, y mantener las funciones antiguas sin retirarlas acumula deuda técnica e impide desarrollar lo que es más importante. Por ello, la plataforma debe tener una «postura» clara: definir qué admitirá, qué dejará de admitir y qué sirve a la mayoría de los usuarios.
Esto incluye establecer límites formales de responsabilidad mediante interfaces de programación, acuerdos de nivel de servicio y procesos. No basta con que el equipo sepa qué ofrece; el consumidor también debe saber qué le corresponde y cuáles son los límites que la plataforma no sobrepasará. Liste compara las plataformas con componentes de formas fijas: un equipo limitado no puede construir un producto personalizado para cada cliente.
Experiencia práctica: experimentar pronto y utilizar la abstracción sin ocultar los detalles
Liste recomienda fallar rápido y con frecuencia después de decidir construir, protegiendo a los clientes durante la transición. Cita experiencias tempranas con contenedores de Linux y distintas herramientas de orquestación que terminaron con la adopción de Kubernetes; la experimentación temprana permitió al equipo aprender antes de esperar a que madurara una única solución.
En cambio, las capas de abstracción no deben ocultar lo que ocurre debajo. Se puede ofrecer una interfaz de usuario, interfaces API e Infrastructure as Code, como Terraform, pero debe proporcionarse suficiente visibilidad y detalle para comprender los fallos y modificar el comportamiento cuando sea necesario. Liste concluye insistiendo en construir sobre fuentes abiertas y estándares abiertos, para que el equipo de la plataforma se concentre en la integración y el valor añadido en lugar de recrear cada capa desde cero.
¿Por qué importan estos principios?
El valor fundamental del planteamiento de Liste es que transforma la construcción de plataformas: deja de ser un proyecto para lanzar un conjunto de herramientas y se convierte en un compromiso operativo a largo plazo. La plataforma afecta a muchos equipos una vez que se adopta, por lo que la capacidad de actualización, la claridad de las responsabilidades y la gestión de la retirada pasan a ser más importantes que añadir rápidamente una nueva función. Estos principios siguen siendo orientaciones basadas en la experiencia práctica, no un estándar unificado que garantice el éxito; el nivel de disponibilidad, el alcance de la automatización y las decisiones de abstracción continúan estando vinculados a la naturaleza del sistema y a las necesidades de sus usuarios.