Cómo tomar decisiones técnicas sin vender tu alma al hype

Publicado el 16 de marzo de 2026  •  15 minutos  • 3036 palabras

Hay decisiones técnicas que se toman con datos, tiempo y algo de criterio.

Y luego están las otras: las que se toman después de ver tres charlas, dos hilos de X y un caso de estudio mal leído, y acaban en frases como “bueno… ahora ya que lo tenemos montado, habrá que aprovecharlo, ¿no?”.

Un día estás feliz con tu API en un VPS normalito y, al siguiente, te descubres montando una arquitectura serverless-event-driven-data-mesh-multi-cloud porque viste un video donde decía que “así lo hace Netflix”.

El problema no es usar cosas nuevas; el problema es cuando tus decisiones responden más a “queda bien en mi curriculum” que a “le viene bien a mi sistema” (lecciones de migraciones reales , coste oculto de los microservicios ).

Este artículo va de cómo decidir tecnología sin venderle tu alma al hype. De cómo mirar propuestas seductoras como “pásalo todo a serverless”, “vayamos a microservicios”, “montemos un Data Mesh” y ser capaz de responder con algo mejor que un “pues depende”. Para eso, vamos a trataar con cinco criterios muy concretos: coste, complejidad, equipo, lock-in y ROI, y luego a usarlos como filtro cuando llegue el hype del mes.

Coste: cuánto te cuesta de verdad (no solo en euros)

La película suele empezar con una diapositiva muy bonita. Alguien enseña un gráfico donde, después de migrar a serverless , la línea de coste de infraestructura cae como si le hubieran quitado el gluten. “Pagas solo por lo que usas”, te dicen, y durante unos segundos te preguntas por qué sigues pagando ese VPS como si vivieras en 2009.

Empiezan los experimentos. Primero mueves un endpoint a funciones, luego otro, luego el cron job nocturno, luego “ya que estamos” el procesamiento de informes. Y es verdad: en muchos casos la factura de servidores baja… hasta que empiezas a sumar el resto de costes .

Te das cuenta de que has invertido semanas de gente cara desentrañando modelos de tarifas ("¿por request, por GB-segundo, por región?"), ajustando tiempos de espera a servicios externos, peleando con arranques en frío y reestructurando código para que encaje en funciones diminutas. A la vez, aparece una nueva categoría de “infra intangible ”: tiempo montando paneles nuevos, centralizando logs de decenas de funciones, afinando alarmas que ahora saltan desde tres sitios distintos .

Con las migraciones a microservicios pasa algo parecido: muchos estudios de “7 lecciones duramente aprendidas ” reconocen que el coste real no fue solo levantar más instancias, sino el sobreprecio en complejidad operativa y depuración que nadie había presupuestado.

Por eso, cuando alguien venda una decisión como “más barata”, la pregunta útil no es solo “¿cuánto nos ahorramos en cloud?”, sino:

“Si descontamos lo molón, ¿cuántas horas de personas y cuánta atención vamos a meter aquí de ahora a un año, y qué dejamos de hacer mientras tanto?”

Si la respuesta se parece a “bueno, ya veremos, pero el diagrama está hermosote”, eso es hay más hype que realidad.

Complejidad: cuántas cosas tienes que entender a la vez

La complejidad arquitectónica es como la humedad: entra despacio y cuando te quieres dar cuenta la tienes en todas partes. Nadie se levanta y dice: “propongo aumentar nuestra carga cognitiva hasta el colapso”. Se hace a base de pequeños “solo un servicio más”, “solo un topic más”, “solo un CRD más”.

Empiezas con una aplicación en una VM. Pasas a contenedores “para estar al día”: ahora tienes imágenes, un registry, redes virtuales. Luego alguien propone meter todo en Kubernetes, que “es el estándar”: aparecen deployments, services, ingress, configmaps, operators, CRDs y un diccionario nuevo que aprender para seguir sirviendo el mismo JSON de siempre.

Con serverless está pasando algo similar: en artículos recientes se habla del “trilema” de coste, rendimiento y complejidad y de cómo, a medida que crecen las soluciones, los equipos terminan con una telaraña de funciones, colas y permisos donde nadie tiene ya la foto completa en la cabeza. La promesa era “menos cosas que gestionar”; la realidad, en muchos sitios, es “otras cosas que gestionar, pero poco visibles”.

La pregunta clave no es “¿podemos hacerlo?”, sino:

“¿Nuestro equipo puede seguir razonando sobre este sistema sin tener que estudiar un máster cada vez que entra alguien nuevo?”

¿Puedes seguir el camino de una petición sin saltar entre cinco paneles? ¿Puedes explicarle a una persona recién llegada cómo fluye un dato sin necesitar tres pizarras?

En los relatos sobre migraciones fallidas a microservicios siempre se repite lo mismo: nadie calculó bien la envergadura real de la complejidad añadida, tanto técnica como mental.

Cuando un cambio tecnológico convierte tu sistema en algo que solo entienden dos personas, y a ratos, la complejidad ya ha ganado. El diagrama puede ser muy moderno, pero el trabajo diario se ha vuelto francamente más frágil.

Equipo: con las personas que tienes, no con las que querrías tener

Hay arquitecturas que quedan espectaculares… en organizaciones de mil personas.

Data Mesh, por ejemplo, se ha vendido como el futuro de los datos : dominios distribuidos, equipos dueños de sus productos de datos, plataformas autoservicio. Suena fantástico si tienes varios equipos de datos, analistas, SREs de plataforma y un presupuesto serio.

En empresas más pequeñas, algunos arquitectos hablan ya de “el lado oscuro del hype de Data Mesh” : mucho ruido organizativo, roles nuevos mal definidos, inversiones grandes en herramientas… para acabar, en la práctica, con cuatro pipelines rotos y una confusión generalizada sobre quién es responsable de qué datos .

Con los microservicios ha pasado lo mismo. Los casos de Netflix, Amazon o Uber son reales, pero van acompañados de años construyendo equipos de plataforma , invirtiendo en observabilidad , definiendo bounded contexts y repartiendo guardias entre gente muy experimentada. Cuando un equipo de cinco personas intenta copiar la arquitectura de una multinacional, lo que hereda no es la velocidad, es el cansancio.

Decidir con el equipo real en la cabeza es hacerse preguntas que a veces nadie quiere decir en voz alta: ¿quién va a operar esto cuando esté en producción? ¿Cuánta experiencia tenemos ya en sistemas distribuidos, tracing, permisos finos de cloud, incident response? Y, sobre todo, ¿qué curva de aprendizaje añadimos, y a cambio de qué?

Lo que dice cualquiera que haya trabajado con Data Mesh en serio es justamente eso: que no es un “patrón plug-and-play”, sino un modelo organizativo pesado que solo tiene sentido por encima de cierto tamaño. Lo mismo se aplica a muchas decisiones “enterprise”: pueden ser geniales a gran escala y un estorbo en equipos pequeños.

Aceptar que la arquitectura tiene que estar a la altura del equipo, y no al revés, es menos resultón, pero mucho más sano. Mejor una solución que tu equipo entienda y pueda mantener, que una catedral que solo conoce una persona y a medias.

Lock-in: a qué le estás entregando las llaves

Lock-in se ha convertido en la palabra comodín para asustar a cualquiera que use algo que no sea infraestructura pelada. “Si usas Lambda, estarás atrapado en AWS”, “si usas la base de datos gestionada X, nunca podrás irte”, “si apuestas por esta plataforma low-code, estás perdido”.

Pero si lees con calma a gente que lleva años en serverless, verás matices interesantes. Algunos hablan del “conundrum del lock-in y la complejidad en espiral”: si intentas evitar completamente el lock-in, acabas construyendo tantas capas de abstracción que pierdes casi todas las ventajas del servicio gestionado… y sigues estando atado, pero ahora a tu propia capa casera. Otros, desde empresas grandes , cuentan cómo han mitigado el lock-in usando estándares donde importa (datos, contratos, formatos) y aceptando cierta dependencia donde el beneficio es claro.

También existe el fenómeno contrario, el lock-out, del que advierten algunos ingenieros de cloud: tunear tanto tus sistemas (bases de datos, runtimes) que, cuando quieres aprovechar algo gestionado, descubres que ya no encajas en ningún sitio y te has autoexcluido de casi todas las opciones razonables.

La cuestión, entonces, no es “¿tenemos lock-in?”, porque la respuesta siempre es “sí, a algo”. La verdadera pregunta es:

“¿A qué nos estamos atando, con qué beneficio ahora, y cuánto nos costaría movernos si un día necesitamos hacerlo?”

Si usar el orquestador serverless propio de un cloud te ahorra meses de trabajo y te da resiliencia y escalado a coste bajo, quizá te compensa aceptar que migrar eso a otro proveedor no va a ser gratis. Si meter tu lógica de negocio en un entorno no-code propietario te saca las castañas del fuego en un caso interno, igual es perfecto… siempre que sepas que reescribirlo en otro sitio será el precio de crecer más adelante.

La experiencia acumulada en este tema suele apuntar en la misma dirección: “sácale partido a la plataforma, pero sabiendo lo que haces”. Saca partido a lo que el proveedor hace mejor que tú (infra, seguridad base, escalado), pero mantén tu dominio y tus datos en formas que no hagan imposible una futura migración.

ROI: qué te devuelve esto, más allá del ego arquitectónico

En muchos equipos hay algo que late por debajo y que nadie saca a la mesa. Dos años después de una gran re-arquitectura – monolito a microservicios, data warehouse a data mesh, VMs a serverless – alguien mira hacia atrás y se pregunta: “¿todo este esfuerzo nos ha devuelto lo que prometía?”.

Quien se ha tomado la molestia de medir el coste real de los microservicios ha confirmado lo que muchos intuían: en no pocos casos, el retorno no ha estado a la altura de la inversión. Equipos que se han pasado años peleando con despliegues, observabilidad, contratos entre servicios, para terminar con un sistema más caro y más complicado… que no entrega valor al usuario mucho más rápido que antes.

Algunas empresas han decidido incluso dar marcha atrás en parte: consolidar microservicios demasiado finos en servicios más gruesos, o volver a un monolito modular para rebajar coste y carga cognitiva. En varios casos de estudio, esa simplificación ha ahorrado un porcentaje escandaloso del gasto en infraestructura y ha reducido incidentes, sin sacrificar verdaderamente la capacidad de escalar.

El problema es que el ROI rara vez sale en las charlas. Vemos más fácilmente el “antes/después” del diagrama que el “antes/después” de los KPIs que importan: tiempo de entrega, tiempos de recuperación, satisfacción del usuario, coste operativo.

Por eso, una forma útil de aterrizar cualquier decisión de arquitectura es formularla en términos de “dentro de 6-12 meses, deberíamos notar esto”: menos interrupciones por incidentes, despliegues más frecuentes, menor tiempo para lanzar nuevas funcionalidades, menos gasto en infra para el mismo tráfico.

Si lo único que puedes prometer es “seremos más cloud-native, event-driven y alineados con lo que se lleva”, quizá el principal beneficiado es tu curriculum, no tu sistema.

Aplicando el filtro al hype del mes

Con estos cinco ejes en la cabeza – coste, complejidad, equipo, lock-in y ROI –, ya tienes algo con lo que responder cuando llegue el hype del mes.

Alguien propondrá pasar todo a serverless porque “así lo ha hecho tal banco/megaempresa”. Puedes tirar de casos donde serverless ha traído ahorros y velocidad, sí, pero también de análisis que advierten del aumento de complejidad y de la sensibilidad de costes cuando el volumen sube. En lugar de un “sí/no” visceral, puedes tener una conversación concreta: nuestro patrón de tráfico, nuestros tiempos de respuesta, nuestras habilidades, nuestra capacidad de observabilidad.

O llega la propuesta de ir a microservicios “porque somos modernos”. Puedes contraponer experiencias reales de migración donde se subestimó masivamente la complejidad, se acabó con más fallos y se aprendió, a base de porrazos, a ir más despacio y de forma gradual. Puedes preguntarte si ya habéis exprimido de verdad vuestro monolito modular, como recomiendan muchos autores… o si estáis intentando saltar etapas solo para no parecer “viejunos”.

Con Data Mesh pasa igual: frente al relato aspiracional, tienes voces que explican cuándo no es el enfoque adecuado, especialmente para organizaciones pequeñas o sin una cultura de datos madura. Eso te permite preguntarte si tu empresa se parece más a las que lo han hecho bien… o a las que han descubierto su lado oscuro.

Incluso con opciones que nadie suele poner en la portada de una charla, como no-code/low-code, es el mismo ejercicio: para ciertos casos internos, puede ser muy rentable a corto plazo; para sistemas centrales, puede convertirse en el mayor lock-in de tu historia. Depende de qué estés intentando resolver.

La idea no es coleccionar artículos para ganar discusiones, sino tener contexto: ver que, detrás de cada hype, hay historias de éxito y de fracaso, y que las segundas casi siempre tienen en común haber ignorado exactamente estos cinco factores.

Un detector de humo para el hype

No existe una fórmula infalible para tomar decisiones técnicas; si existiera, ya tendríamos un framework npm con ese nombre y un par de certificaciones muy caras detrás (la pela es la pela).

Lo que sí puedes tener es un buen detector de humo.

Cada vez que aparezca una gran idea arquitectónica – serverless, microservicios, Data Mesh, Event Sourcing, la que toque esa semana –, enciéndelo y hazte estas preguntas antes de que el humo te llegue a los ojos:

• ¿Qué problema concreto de coste queremos mejorar, y cómo sabremos que lo hemos logrado?
• ¿Qué complejidad añadimos y quién va a cargar con ella día a día?
• ¿Nuestro equipo, tal y como es hoy, puede operar esto sin quemarse?
• ¿A qué proveedor, patrón o plataforma nos estamos atando, y dónde nos compensa?
• ¿Qué retorno esperamos en 6-12 meses, más allá de la satisfacción de decir “lo hemos hecho”?

Si encuentras respuestas claras, puede que ese hype, para ti, no sea hype, sino la herramienta adecuada en el momento adecuado. Si todo suena a “porque lo han hecho otros” o “porque parece el futuro”, quizá lo más moderno que puedes hacer es seguir con algo más sencillo, mejorar lo que ya tienes y revisitar la idea más adelante.

Al final, no se trata de ser cínico con toda tecnología nueva (aunque a mí me encanta criticar), ni de convertirse en el abuelo que dice que todo tiempo pasado fue mejor (¡que vivan los 8 bits!).

Se trata de algo más difícil de vender y bastante más raro: practicar arquitectura orientada a la realidad.

Puede que eso no quede tan épico en las diapositivas de la próxima charla. Pero, con un poco de suerte, te ahorrará unas cuantas noches en vela y el disgusto de mirar atrás y no encontrar una razón técnica sólida para lo que hiciste.

Glosario rápido

Glosario de urgencia para que nadie se quede fuera de la conversación cuando el hype apriete.

• Bounded context: Límite lógico dentro del cual un modelo de datos y su lenguaje tienen sentido. Concepto central de Domain-Driven Design.
• ConfigMap: Recurso de Kubernetes para almacenar configuración (claves, variables) separada del código de la aplicación.
• CRD: Custom Resource Definition. Extensión de Kubernetes que permite definir tus propios tipos de recursos.
• Data Mesh: Modelo organizativo de datos donde cada equipo de dominio es dueño de sus datos como producto, en vez de centralizarlos en un único equipo de datos.
• Event Sourcing: Patrón de arquitectura que almacena cada cambio de estado como un evento inmutable, en lugar de guardar solo el estado final.
• Incident response: Proceso estructurado para detectar, contener y resolver incidentes en producción.
• Ingress: Recurso de Kubernetes que gestiona el tráfico de entrada HTTP/HTTPS hacia los servicios del clúster.
• KPI: Key Performance Indicator. Métrica clave que mide si algo importante va bien o mal.
• Lock-in: Dependencia técnica con un proveedor o plataforma que hace dolorosa (y cara) la migración a otro.
• Lock-out: Lo contrario del lock-in: personalizar tanto tu infraestructura que te autoexcluyes de usar servicios gestionados o estándar.
• Monolito modular: Arquitectura donde toda la aplicación se despliega como una sola unidad, pero su código interno está organizado en módulos bien delimitados y desacoplados entre sí.
• Observabilidad: Capacidad de entender el estado interno de un sistema a partir de sus salidas externas (logs, métricas, trazas). Va más allá del simple monitoring: no solo sabes que algo falla, sino por qué.
• ROI: Return on Investment. Lo que te devuelve una inversión respecto a lo que has puesto.
• Tracing: Seguimiento del recorrido de una petición a través de múltiples servicios, para diagnosticar problemas en sistemas distribuidos.
• VPS: Virtual Private Server. Servidor virtual que alquilas a un proveedor, con acceso root y control total sobre el sistema operativo.

Fuentes y referencias

Porque opinar sobre arquitectura sin referencias es como migrar a microservicios sin motivo: suena valiente, pero acaba regular.

• Seven Hard-Earned Lessons Learned Migrating a Monolith to Microservices - Garden.io. Lecciones prácticas de una migración real de monolito a microservicios.
• Lessons Learned from a Monolith to Microservices - InfoQ. Experiencias y errores comunes al adoptar microservicios desde un monolito.
• The True Cost of Microservices - SoftwareSeni. Análisis del coste real en complejidad operativa y debugging.
• Serverless Architectures: Comparison, Pros, Cons and Case Studies - AgileEngine. Comparativa de arquitecturas serverless con pros, contras y casos de uso.
• The Serverless Trilemma: Cost, Performance and Complexity - Luc van Donkersgoed. El trilema de coste, rendimiento y complejidad en serverless.
• Is Cost a Real Concern in Serverless? - Sheen Brisals. Reflexión sobre si el coste es realmente un problema en serverless.
• The Conundrum of Serverless Lock-in, Spiralling Complexity - Serverless Advocate. El dilema del lock-in y la complejidad creciente en serverless.
• Serverless Under Fire: Complexity, Costs, Cloud Confusion - Bran Kop. Crítica a serverless desde la complejidad, costes y confusión cloud.
• Microservices Migration Case Study - Software Modernization Services. Caso de estudio de migración a microservicios con resultados reales.
• The State of Data Mesh in 2026: From Hype to Hard-Won Maturity - ThoughtWorks. Estado actual de Data Mesh: del hype a la madurez.
• Data Mesh: The Dark Side of the New Hype - Zoltan Horkay. El lado oscuro del hype de Data Mesh.
• When Data Mesh Isn’t the Right Approach - Yugank Aman. Cuándo Data Mesh no es la solución adecuada para tu organización.
• 12-Factor Environment Automation - UDX. Automatización de entornos siguiendo los 12 factores.
• DORA Metrics - LinearB. Explicación de las métricas DORA para medir rendimiento de equipos.
• Mitigating Serverless Lock-in Fears - ThoughtWorks. Cómo mitigar el miedo al lock-in en serverless.
• Serverless Reduces Collaboration Cost - Capital One. Cómo serverless reduce el coste de colaboración entre equipos.