Ingeniería de plataforma
La plataforma detrás de cada equipo rápido.
Plataformas internas, herramientas para desarrolladores y caminos dorados — la infraestructura que convierte "funciona en mi máquina" en "salió esta mañana". Construida para mantenerse, no para admirarse.
Qué construimos
- Plataformas internas de desarrollo y caminos dorados
- CI/CD en el que tu equipo confía lo suficiente para desplegar un viernes
- Entornos, herramientas y plantillas que hacen del camino correcto el camino fácil
- Documentación como parte del entregable, no como algo que se agrega después
Pruebas
Auth0
Dentro del producto de Auth0, durante siete años construimos el trabajo de plataforma que ningún usuario ve y del que depende cada equipo: el Admin Panel, el Support Center, siete extensiones y las librerías de Python y Node.js sobre las que construyen otros ingenieros.
Lee el caso- Admin Panel · Support Center · 7 extensiones
- Librerías sobre las que construyen otros equipos
Cuándo nos buscan los equipos
- Cada despliegue es un evento
- Incorporar a un ingeniero toma semanas
- Cada equipo resuelve el mismo problema de infraestructura de forma distinta
Por qué cada equipo lo resuelve distinto
Nadie decide tener cinco formas de desplegar un servicio. Pasa de a una decisión razonable por vez: un equipo necesitaba entregar, la forma compartida era lenta o no estaba documentada, así que construyeron la suya — y funcionó, para ellos. Dos años después un ingeniero nuevo tarda tres semanas en hacer su primer despliegue, porque la respuesta a "cómo hacemos esto acá" depende de a qué equipo le preguntes, y cada incidente empieza por averiguar cuál de las cinco formas usa este servicio.
Una plataforma no arregla eso con un mandato. Lo arregla haciendo que la forma compartida sea mejor que la propia: una plantilla que arranca un servicio con logging, pruebas, CI y un destino de despliegue ya puestos; entornos que aparecen para una rama en minutos; un pipeline lo bastante rápido y confiable como para que nadie quiera el suyo. Los equipos se mudan al camino porque es más rápido, y se quedan porque irse significa devolver todo eso. La adopción es la única métrica que cuenta — una plataforma que hay que imponer ya fracasó.
Cómo lo construimos
Auditoría de fricción
dónde pierden tiempo tus ingenieros de verdad
Primero los caminos dorados
hacer del camino correcto el camino fácil
Automatizar lo aburrido
entornos, plantillas, chequeos
Medir la adopción
una plataforma que nadie usa es decoración
Qué es un camino dorado
Lo que viene por defecto es lo correcto
un servicio nuevo arranca de una plantilla que ya tiene logging, pruebas, CI y un destino de despliegue. El ingeniero que sigue el camino recibe todo eso gratis; el que se sale tiene que justificar por qué.
Entornos a demanda
una rama recibe su propio entorno, con datos que se parecen a producción, en minutos. "Funciona en mi máquina" deja de ser un argumento porque ya no hay diferencia.
Se confía en el pipeline
chequeos que corren en menos de diez minutos, tasa de inestabilidad cerca de cero y un rollback que es un solo comando. Eso es lo que hace que desplegar un viernes sea algo común en vez de algo valiente.
La adopción es la métrica
una plataforma que nadie usa es decoración. Medimos el tiempo hasta el primer despliegue de un ingeniero nuevo, la frecuencia de despliegue por equipo y cuántos servicios están en el camino — antes y después.
La meta no es un equipo de plataforma. Es que cada equipo entregue como si tuviera uno.
Funciona bien con
Preguntas frecuentes
¿Esto es DevOps con otro nombre?
DevOps opera sistemas; la ingeniería de plataforma hace más rápido a cada equipo. Relacionados, no idénticos.
¿Construir o comprar la plataforma?
Componer: comprar donde es estándar, construir donde tu flujo de trabajo es específico.
¿Cómo sabemos que funcionó?
Tiempo hasta el primer despliegue, tiempo de incorporación, frecuencia de despliegue — medidos antes y después.
¿Dónde entra la IA en esto?
En dos lugares. El pipeline y las plantillas son lo que hace seguro el desarrollo asistido por IA a esa velocidad: especificaciones en el repositorio, cada cambio revisado por una persona, chequeos automáticos antes de que algo salga. Y cuando un equipo corre sus propios modelos, la plataforma es lo que los sirve — versionados, monitoreados, reversibles — igual que sirve todo lo demás.
Nuestros equipos son chicos. ¿Esto es exagerado?
La plataforma escala hacia abajo: para un equipo chico suele ser una plantilla, un pipeline y una receta de entorno — una semana de trabajo que le quita una hora a cada día siguiente. Lo exagerado es armar un equipo de plataforma; el punto es que no necesitas uno.
¿Quién es dueño de la plataforma después de que se van?
Tus ingenieros, y está construida para eso: plantillas en tus repositorios, pipelines en las herramientas que ya usas, documentación que es parte del entregable. La meta nunca fue un equipo de plataforma; es que cada equipo entregue como si tuviera uno, sin un departamento nuevo que financiar.