Datos de producto estructurados significa que cada dato del producto vive en un atributo tipado, con…
10 años de microservicios en el comercio: en qué acertó Goetsch
Octubre de 2016. Kelly Goetsch, por entonces en commercetools, publica un breve eBook de O'Reilly: Microservices for Modern Commerce. 76 páginas, patrocinado por commercetools, con un prólogo de Jean-Jacques van Oosten, en aquel momento Chief Digital Officer del grupo Rewe. La tesis central: los microservicios remodelarán de forma permanente el stack del comercio, los monolitos backend morirán, las API se convertirán en la nueva infraestructura.
Diez años después, esa tesis es consenso. Headless, MACH, Composable: todo el vocabulario de categoría que usamos hoy surgió directamente de este planteamiento. Y es precisamente por eso que el libro merece una retrospectiva a una década de distancia: ¿qué predicciones resultaron acertadas? ¿Cuáles fueron superadas por la realidad? ¿Y qué carencia describió Goetsch con demasiada ligereza, una carencia que desde entonces se ha convertido en el verdadero cuello de botella de la diferenciación?
En qué acertó Goetsch
1. La ley de Conway es el factor decisivo, no la tecnología
En la página 3, Goetsch cita la célebre observación de Mel Conway de 1968: "Cualquier organización que diseña un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la propia organización." Después nombra los microservicios directamente como "Hacking Conway's Law".
En 2016, plantear esto dentro de un debate predominantemente técnico era notable. Una década después, la idea es sencillamente innegable: los proyectos composable fracasan en la práctica no por las herramientas, sino por los silos organizativos. El equipo de frontend por un lado, el equipo de backend por otro, el equipo de contenidos en algún punto intermedio, y el stack composable vuelve rápidamente a ser un monolito, solo que con muchas más piezas en movimiento.
Si hoy planificáis un replatforming con equipos aún estructurados por capas horizontales (equipo de desarrollo, equipo de operaciones, equipo de contenidos), no lograréis aprovechar la flexibilidad técnica de las arquitecturas composable. La estructura organizativa decide. Siempre.
2. Complejidad interna frente a complejidad externa: el desplazamiento es real
Uno de los conceptos más agudos del libro es la distinción entre Arquitectura interna y Arquitectura externa. Goetsch escribe: "En esencia, los microservicios desplazan la complejidad hacia afuera, cambiando complejidad externa por simplicidad interna." Cada microservicio individual se vuelve más simple. La red que los conecta, service discovery, eventing, API gateways, orquestación de contenedores, se vuelve mucho más compleja.
Ese desplazamiento se ha concretado por completo en 2026. Kubernetes es ya una herramienta estándar. El event streaming mediante Kafka es una disciplina propia. Las configuraciones de los API gateway llenan repositorios enteros. La simplicidad interna se ha materializado. Pero la complejidad externa ha adquirido un peso que muchos equipos subestimaron en 2016.
3. La omnicanalidad necesita una única fuente de verdad por función
Goetsch describe la verdadera omnicanalidad así: un único sistema por cada capacidad de negocio (precios, inventario, promociones) y, por encima de eso, "interfaces de usuario más o menos desechables." La tesis sobre el backend ha resultado del todo correcta. Hoy ningún stack de e-commerce serio gestiona precios, inventario y promociones de forma simultánea con un único sistema monolítico.
Shopware, commercetools, SFCC en configuración headless, Algolia para la búsqueda, Stripe para los pagos: la desagregación del backend es una realidad consolidada. En este punto el mercado le ha dado a Goetsch la máxima nota.
En qué se equivocó Goetsch, o qué infravaloró
4. Las "interfaces desechables" fueron el error más caro de la década
Aquí es donde la cosa se pone interesante. En 2016 Goetsch escribe que, en la verdadera omnicanalidad, las interfaces de usuario son "más o menos desechables." Basta con construir una vez API backend limpias y las nuevas interfaces de usuario, para Apple Watch, quioscos, chatbot, pueden ensamblarse en cuestión de días.
Esa suposición resultó ser errónea. No en teoría, sino en la práctica.
Lo que realmente ocurrió: la desagregación del backend generó una enorme nueva complejidad en el frontend. Cada nuevo frontend tiene ahora que coordinar llamadas API contra decenas de microservicios, implementar estrategias de caching por cada tipo de dato, incorporar lógica de personalización, respetar los performance budget y gestionar de forma simultánea los rollouts globales entre mercados e idiomas. Construir hoy un storefront composable sobre Next.js, commercetools y Algolia significa escribir bastante más código frontend que cualquier desarrollo custom sobre Shopware 6, con una complejidad operativa notablemente mayor.
La "interfaz desechable" en la práctica no era desechable. Sencillamente era menos visible en el debate centrado en el backend de 2016.
5. Hoy la capa de frontend es el verdadero cuello de botella de la diferenciación
Cuando los backends son estandarizables y adquiribles como SaaS, y lo son, esa es la confirmación de la tesis MACH, la diferenciación competitiva se desplaza hacia el frontend. Quien lanza nuevas experiencias más rápido, quien aplica la personalización más cerca del rendering, quien ejecuta A/B test sin deployment del backend, quien realiza composición de contenidos asistida por IA sin intervención de desarrolladores: ese es quien gana.
Esa es exactamente la capa que Goetsch infravaloró en 2016. Y hoy es el cuello de botella.
Lo que Goetsch describía como el API gateway en el papel de "Backend for your Frontend" ha evolucionado para 2026 hacia las Frontend Management Platform. Una FMP asume la Arquitectura externa de la capa de frontend, routing, composición, caching, personalización, deployment, de forma análoga a lo que la orquestación de contenedores hizo por la capa de backend.
La analogía es directa: igual que en 2016 no querríais gestionar un deployment de microservicios sin orquestación de contenedores, en 2026 no queréis gestionar un storefront composable sin un estándar para la capa de frontend.
Qué significa esto para vuestro replatforming
Si hoy planificáis un stack composable, la retrospectiva sobre Goetsch arroja tres preguntas útiles:
Pregunta 1: ¿está vuestra estructura organizativa preparada para la ley de Conway? Los equipos de producto multifuncionales por cada capacidad de negocio no son un lujo opcional. Sin ellos no lograréis aprovechar la flexibilidad del stack composable, con independencia de las herramientas que elijáis. Ampliamos esto en nuestro artículo La ley de Conway en el replatforming composable.
Pregunta 2: ¿tenéis un plan para la arquitectura externa de vuestro frontend? Los microservicios backend necesitaban un plan, orquestación de contenedores, API gateways, service discovery. Vuestro frontend necesita un plan equivalente. Sin un estándar para la capa de frontend, el TCO del composable se dispara. Ampliamos esto en Headless por sí solo no basta.
Pregunta 3: ¿quién posee la capa de frontend como capacidad? No como "el equipo de frontend" que despacha tickets, sino como una capacidad de negocio diferenciada, con su propia ownership, su propia influencia sobre la roadmap, sus propias decisiones sobre herramientas. Es el principio de ownership que Goetsch describía para los microservicios, aplicado a la capa de frontend.
Conclusión: Goetsch tenía razón, y dejó una carencia
Microservices for Modern Commerce fue un libro importante en 2016. Desencadenó un debate que condujo al movimiento MACH, al crecimiento de commercetools, a Shopware headless y a todo un ecosistema de API especializadas para el comercio.
Las tesis sobre el backend resultaron correctas. La ley de Conway sigue vigente. La distinción entre complejidad interna y externa sigue siendo un marco útil.
Pero la suposición de las "interfaces desechables" fue el punto ciego del libro, y ese punto ciego ha tenido ocupado al mundo del comercio durante una década. Hoy la capa de frontend es el cuello de botella de la diferenciación, y la respuesta no es otro desarrollo custom más, sino un estándar para la capa de frontend.
En Laioutr lo llamamos Agentic Frontend Management Platform, nacido del reconocimiento de que lo que Kubernetes hizo por los microservicios todavía tiene que ocurrir para la capa de frontend.
[Reserva una demo y descubre cómo lo aborda Laioutr](https://www.laioutr.com/demo)
Fuente: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.
Contenidos relacionados
Recursos relacionados: Content Management y Composable Digital Experience Platform.