El costo real de los microfrontends
Los microfrontends compran independencia entre equipos, y el precio se paga en trabajo de plataforma, coordinación y herramientas. Este es un desglose de dónde sale el costo y cómo crece.
Por qué importa un desglose honesto
La mayor parte del costo de los microfrontends no se ve en un prototipo. Cargar un remoto desde un host toma una tarde. Operar una plataforma de la que dependen varios equipos es un compromiso permanente. Los presupuestos que solo cuentan la primera parte se quedan cortos.
Este artículo no da cifras, porque dependen del tamaño del producto y de la madurez de la organización. Describe los factores de costo y cómo escala cada uno, para que puedas estimar con tus propios números.
Los factores de costo
| Factor de costo | Tipo | Escala con |
|---|---|---|
| Plataforma: host, carga, contrato | Construcción inicial y luego continuo | Casi fijo |
| Pipelines y ambientes | Plantilla una vez y luego por remoto | Cantidad de remotos |
| Design system | Continuo | Cantidad de equipos que lo consumen y variedad de UI |
| Actualización de dependencias | Continuo | Cantidad de remotos y repositorios |
| Coordinación entre equipos | Continuo | Cantidad de interfaces entre equipos |
| Trabajo de rendimiento | Continuo | Remotos por pantalla y librerías compartidas |
| Pruebas entre remotos | Continuo | Cantidad de recorridos críticos que cruzan áreas |
| Monitoreo y operación | Continuo | Cantidad de remotos |
| Onboarding y conocimiento | Continuo | Rotación de personas y complejidad de la plataforma |
Trabajo de plataforma
Alguien tiene que construir y mantener el host, la carga en ejecución, el manifiesto, la sesión compartida y las reglas de rutas. Este costo es casi fijo: es parecido para cuatro remotos y para quince. Por eso los microfrontends son caros para organizaciones pequeñas y razonables para las grandes, donde el costo fijo se reparte entre más equipos.
El error es tratarlo como un proyecto que termina. La plataforma necesita mantenimiento mientras viva el producto: actualizaciones del framework, cambios en las herramientas de federación, necesidades nuevas de los equipos.
Herramientas y pipelines
Cada remoto necesita build, pruebas, despliegue y rollback. Con buenas plantillas, el costo por remoto es pequeño. Sin ellas, cada equipo arma su propio pipeline y el costo se multiplica. Mira CI/CD para microfrontends.
Esfuerzo duplicado
Independencia significa que los equipos resuelven problemas parecidos por separado. Algo de duplicación es el precio de la autonomía: dos equipos escriben filtros de tabla parecidos, helpers de formularios parecidos, clientes de API parecidos. Intentar eliminarla toda produce librerías compartidas que vuelven a acoplar a todos.
La parte que debe ser única es la capa visual. Sin un design system compartido, cada equipo reconstruye botones y formularios, y el producto deja de verse como un solo producto. Un design system tiene su propio costo y necesita su propio dueño. Mira design system entre microfrontends.
Coordinación
Los microfrontends reducen la coordinación del día a día: los equipos publican sin pedir permiso. Agregan otra distinta: acordar contratos, versiones de dependencias compartidas, cambios incompatibles en el host y actualizaciones del framework.
Este costo crece con la cantidad de interfaces entre equipos. Los límites de negocio limpios lo mantienen bajo. Los límites pobres lo vuelven más alto que en el monolito, porque las conversaciones ahora cruzan repositorios y pipelines.
Trabajo de rendimiento
En un build único, el bundler hace la mayor parte de la optimización. Una plataforma federada necesita personas que vigilen las dependencias duplicadas, el orden de carga y los presupuestos. El trabajo es continuo, porque cada remoto nuevo y cada deriva de versiones puede traer una regresión. Mira rendimiento de microfrontends.
Costo cognitivo
Los ingenieros deben entender más cosas: la carga en ejecución, el manifiesto, las dependencias compartidas, el contrato con el host, el desarrollo local contra remotos desplegados. La depuración cruza los límites entre equipos. Las personas nuevas tardan más en ser productivas en temas de plataforma, incluso cuando su propio remoto es simple.
Qué obtienes a cambio
- Publicaciones independientes. Un equipo publica cuando su trabajo está listo, sin esperar una publicación compartida.
- Menor radio de impacto. Una mala publicación afecta un área y se revierte sola.
- Modernización incremental. Cada área se puede migrar o actualizar a su propio ritmo. En una plataforma legacy, esta suele ser la razón principal.
- Propiedad clara. Cada área tiene un equipo que responde por ella.
Cómo juzgar si vale la pena
Pregunta cuánto cuesta la situación actual:
- ¿Con qué frecuencia un equipo espera la publicación, la revisión o el arreglo de otro equipo?
- ¿Cuánto tarda un cambio desde el merge hasta producción, y cuánto de ese tiempo es espera en cola?
- ¿Con qué frecuencia el bug de un equipo bloquea la publicación de todos?
- ¿Hay una migración bloqueada porque debe ocurrir en todas partes a la vez?
Si esos costos son altos y crecen con cada equipo nuevo, el costo de la plataforma tiene algo que compensar. Si son bajos, un monolito modular con límites que se hacen cumplir entrega la mayor parte de la estructura por mucho menos. La decisión se discute en cuándo usar microfrontends.
El resultado más caro es el que queda a medio camino: se paga el costo de la plataforma y las publicaciones siguen coordinadas porque los límites o los contratos son débiles. Presupuesta para hacerlo bien, o elige la arquitectura más simple.
Más en esta sección
- Errores comunes en microfrontends y cómo evitarlos
- Checklist de preparación para microfrontends
- Seguridad en microfrontends: qué cambia y qué hacer
- Desarrollo local con microfrontends
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn