¿Estamos eligiendo la arquitectura que necesita el negocio o simplemente la tecnología que está de moda?

Una decisión que va mucho más allá del código

A lo largo de mi trayectoria profesional en el desarrollo de sistemas, he aprendido que algunas de las decisiones más importantes de un proyecto se toman antes de escribir la primera línea de código.

No siempre se trata de elegir el lenguaje de programación, el framework o la base de datos. En muchas ocasiones, la decisión que marcará el futuro de una aplicación es mucho más profunda: definir cómo estará construida, cómo evolucionará y quién tendrá la responsabilidad de mantenerla funcionando.

He tenido la oportunidad de trabajar en el desarrollo de software, colaborar con clientes de diferentes sectores y conocer las necesidades de organizaciones privadas y entidades del Estado. Mi experiencia en Alvore, empresa de desarrollo de software, así como mi trabajo en dos ministerios del Gobierno, me ha permitido reflexionar sobre algo que considero fundamental: una buena solución tecnológica comienza por comprender el problema que necesitamos resolver.

Imaginemos una situación bastante común.

Una empresa necesita desarrollar un sistema para administrar sus operaciones. Tiene procesos que automatizar, usuarios que atender, información que proteger y una fecha de entrega que cumplir.

Durante las primeras reuniones aparece una propuesta que parece resolverlo todo: construir el sistema utilizando microservicios.

La idea suena atractiva. Cada módulo funcionará de manera independiente, será posible escalar componentes por separado y los equipos podrán trabajar con mayor autonomía. Además, se utilizarán tecnologías modernas que, al menos sobre el papel, parecen preparar a la organización para el futuro.

Pero antes de aprobar la propuesta, hay preguntas que necesitamos responder.

• ¿Realmente necesitamos distribuir el sistema en varios servicios independientes?

• ¿Tenemos el personal capacitado para desarrollar, desplegar y mantener esa arquitectura?

• ¿Contamos con presupuesto para infraestructura, monitoreo, seguridad y operación?

• ¿Conocemos suficientemente los procesos del negocio?

• ¿Qué ocurrirá cuando uno de los servicios falle?

• ¿Cuánto costará mantener la solución durante los próximos cinco o diez años?

Si no tenemos respuestas claras, estamos asumiendo un riesgo que podría terminar pagando la empresa, el equipo de desarrollo y, en última instancia, los usuarios.

Por eso quiero abordar este tema desde una perspectiva práctica, no como una discusión sobre qué tecnología es mejor, sino como una reflexión sobre cómo tomar decisiones responsables.

La arquitectura correcta no es necesariamente la más moderna. Es la que responde a las necesidades reales del negocio y podemos mantener de forma segura y sostenible.

El error de confundir una arquitectura moderna con una arquitectura adecuada

En el mundo del desarrollo de software aparecen constantemente nuevas herramientas, metodologías y arquitecturas. Muchas aportan beneficios importantes, pero ninguna debería adoptarse sin comprender el problema que pretende resolver.

Los microservicios son un buen ejemplo.

Se han convertido en una alternativa conocida para construir plataformas distribuidas, especialmente cuando existen múltiples equipos, necesidades de escalamiento independientes y dominios de negocio que pueden evolucionar por separado.

El problema aparece cuando comenzamos a tratarlos como la solución obligatoria para cualquier sistema nuevo.

En las organizaciones, un cambio de liderazgo puede venir acompañado de nuevas propuestas tecnológicas. Un nuevo jefe, director o responsable de informática llega con ideas diferentes, quiere modernizar los sistemas y propone cambiar una arquitectura que ha funcionado durante años.

La modernización es necesaria. Ningún sistema debería permanecer obsoleto simplemente porque siempre ha funcionado de la misma manera.

Pero modernizar no significa reemplazar automáticamente lo existente.

Antes de proponer una transformación, necesitamos conocer qué hace el sistema, qué procesos sostiene, qué dependencias tiene, cuáles son sus riesgos y qué consecuencias tendría una migración.

Un sistema que funciona para una organización puede ser inadecuado para otra, aunque ambas tengan presupuestos similares y utilicen tecnologías parecidas.

Por eso debemos separar nuestras preferencias personales de las necesidades reales del negocio.

No se trata de demostrar que dominamos una tecnología. Se trata de demostrar que sabemos elegir la herramienta adecuada para resolver un problema.

Monolito: una arquitectura que todavía tiene mucho que ofrecer

Un monolito es una aplicación que se construye y despliega como una unidad. Puede tener múltiples módulos internos, pero estos forman parte de una misma aplicación desplegable.

Imaginemos un sistema empresarial que administra clientes, productos, inventario, facturación y reportes.

Podemos desarrollar estas funcionalidades dentro de una aplicación, organizando el código en módulos con responsabilidades claras. Los componentes pueden compartir una base de datos y comunicarse directamente dentro del mismo proceso, según el diseño elegido.

Esta alternativa puede funcionar muy bien cuando el alcance del negocio está definido, el equipo es pequeño o mediano y las funcionalidades no necesitan escalar de manera independiente.

Entre sus principales ventajas están:

• Menor complejidad inicial de infraestructura.

• Pruebas de integración y depuración generalmente más sencillas.

• Menos comunicaciones de red entre componentes internos.

• Transacciones de base de datos más simples cuando varias operaciones deben ejecutarse de forma atómica.

• Menores costos operativos en muchos proyectos pequeños y medianos.

• Mayor facilidad para comenzar, siempre que exista un diseño interno adecuado.

Sin embargo, sería un error pensar que cualquier monolito es fácil de mantener.

Un monolito mal diseñado puede convertirse en una aplicación donde todo depende de todo. Un pequeño cambio en facturación puede afectar inventario; una modificación en usuarios puede romper reportes y cada nueva funcionalidad puede requerir revisar una gran cantidad de código.

Cuando eso ocurre, el problema puede estar en la falta de modularidad, el acoplamiento excesivo, las responsabilidades mal definidas o la ausencia de pruebas automatizadas.

La solución no siempre consiste en dividir la aplicación en microservicios. En muchos casos, comenzar por reorganizar el código, establecer límites entre módulos y automatizar las pruebas puede aportar mejoras importantes.

Por eso considero que el monolito modular merece especial atención.

Un monolito modular mantiene una única unidad de despliegue, pero organiza sus funcionalidades en módulos con responsabilidades y dependencias controladas. Esto permite construir una base sólida sin asumir desde el principio toda la complejidad de una arquitectura distribuida.

Microservicios: independencia, escalabilidad y nuevos desafíos

Los microservicios dividen una solución en servicios relativamente pequeños, organizados alrededor de capacidades o dominios del negocio.

Por ejemplo, una plataforma empresarial podría contar con servicios para gestionar clientes, facturación, inventario, notificaciones y autenticación.

Cada servicio puede desarrollarse, desplegarse y escalarse de manera independiente, siempre que la arquitectura esté diseñada para permitirlo.

Pero hay un detalle importante: dividir una aplicación por funcionalidades no basta para crear una buena arquitectura de microservicios.

Cada servicio necesita contratos de comunicación claros, mecanismos de autenticación, registros, métricas, trazabilidad, despliegues controlados y una estrategia para gestionar sus datos.

Una llamada que antes era una función dentro de la misma aplicación puede convertirse en una petición de red que depende de la disponibilidad de otro servicio, de sus credenciales, de los tiempos de respuesta y de posibles fallas de comunicación.

Si una operación depende de cinco servicios consecutivos, la lentitud o caída de uno de ellos puede afectar el resultado completo.

Por eso debemos considerar tiempos de espera, reintentos controlados, idempotencia, circuit breakers cuando correspondan y mecanismos de recuperación.

Los microservicios pueden aportar beneficios importantes cuando existen necesidades reales de independencia, pero también introducen nuevos costos y responsabilidades.

Entre sus ventajas están:

• Escalamiento independiente de componentes.

• Despliegues independientes cuando los servicios están bien delimitados.

• Mayor autonomía para equipos responsables de dominios diferentes.

• Posibilidad de aislar determinadas fallas.

• Flexibilidad para evolucionar componentes con requisitos distintos.

Entre sus desafíos están:

• Mayor complejidad operativa.

• Comunicación de red y fallas distribuidas.

• Necesidad de monitoreo y trazabilidad centralizados.

• Gestión más exigente de identidades, secretos y permisos.

• Consistencia de datos y transacciones distribuidas.

• Mayor esfuerzo de automatización, pruebas y mantenimiento.

Por eso, antes de distribuir una aplicación, debemos hacernos una pregunta: ¿el negocio necesita realmente esta independencia o estamos creando una complejidad que todavía no podemos justificar?

Mi experiencia en Alvore: comprender al cliente antes de elegir la tecnología

Durante mi etapa en Alvore, trabajando en desarrollo de software y acompañando a clientes, comprendí la importancia de analizar las necesidades de cada organización antes de definir cómo construir una solución.

Cuando desarrollamos software para terceros, debemos recordar que dos clientes pueden solicitar sistemas aparentemente similares y, aun así, necesitar arquitecturas diferentes.

Pensemos en dos contextos que requieren un análisis cuidadoso.

Una empresa privada de alto prestigio

Una empresa privada puede depender de sus sistemas para administrar operaciones comerciales, inventarios, facturación, clientes y procesos internos.

Una interrupción puede representar pérdidas económicas, afectar la atención al cliente o comprometer la continuidad operativa.

En un escenario así, no basta con preguntar qué tecnología quiere utilizar el cliente. Debemos identificar cuáles son sus procesos críticos, qué disponibilidad necesita, cuántas transacciones espera manejar, qué integraciones existen y cuáles son las consecuencias de una interrupción.

Si la empresa tiene un sistema de alcance controlado, un equipo pequeño y procesos relativamente integrados, un monolito modular puede ser una alternativa razonable.

Si algunas capacidades necesitan escalar por separado, existen equipos autónomos responsables de dominios distintos y la organización puede sostener la operación distribuida, los microservicios podrían aportar beneficios concretos.

Lo que no deberíamos hacer es recomendar una migración completa únicamente porque la tecnología propuesta es más reciente.

Una entidad pública del Gobierno

En una institución pública, el análisis también debe considerar los procedimientos administrativos, los expedientes, los registros históricos, las autorizaciones, las auditorías y las obligaciones normativas.

A esto se suman las integraciones con otras plataformas, los procesos de contratación y la necesidad de garantizar la continuidad del servicio a los ciudadanos.

Una decisión arquitectónica equivocada puede provocar más que un inconveniente técnico. Puede retrasar trámites, interrumpir procesos institucionales, dificultar auditorías o generar gastos no contemplados.

Por eso es indispensable evaluar quién administrará la solución una vez finalizado el proyecto, si existe personal capacitado, cómo se gestionarán los cambios de proveedores y qué ocurrirá si el equipo que desarrolló la plataforma deja de prestar sus servicios.

Mi experiencia trabajando en dos ministerios del Gobierno ha reforzado mi convicción de que debemos comprender el contexto institucional antes de proponer cambios tecnológicos.

Esto no significa que las entidades públicas deban utilizar monolitos ni que las empresas privadas deban adoptar microservicios. Significa que cada organización necesita una decisión fundamentada en su realidad.

Lo que nos enseñan los casos reales

La historia de la industria del software nos muestra que una arquitectura no debería evaluarse únicamente por sus ventajas teóricas.

En 2023, el equipo de Amazon Prime Video explicó cómo rediseñó un servicio de monitoreo de calidad de audio y video para reducir costos y mejorar su escalabilidad. En aquel caso, consolidar componentes distribuidos en un servicio de mayor duración ejecutado en contenedores permitió reducir considerablemente los costos de infraestructura.

La lección no es que los microservicios sean malos. Es que una solución distribuida puede resultar innecesariamente costosa cuando sus componentes necesitan comunicarse constantemente y no obtienen suficiente beneficio de la independencia.

Otro ejemplo es el incidente de Knight Capital en 2012. Una implementación incorrecta de software provocó órdenes erróneas en su sistema automatizado de negociación bursátil y pérdidas superiores a los 460 millones de dólares en aproximadamente 45 minutos, según la Comisión de Bolsa y Valores de Estados Unidos.

Este caso no demuestra que una arquitectura sea mejor que otra. Demuestra que las decisiones técnicas deben acompañarse de controles de despliegue, pruebas, monitoreo y mecanismos de recuperación.

En ambos escenarios encontramos una lección que vale la pena recordar: no basta con construir un sistema. También debemos preparar la organización para operarlo, actualizarlo y responder cuando algo falle.

Fuentes para profundizar:

• Amazon Prime Video: análisis de su cambio de arquitectura y costos.

• Comisión de Bolsa y Valores de Estados Unidos: investigación y sanción relacionada con Knight Capital.

La pregunta que debemos hacernos antes de continuar

Después de revisar ambos enfoques, queda claro que no existe una respuesta universal.

Un monolito modular puede ser la mejor opción para un sistema empresarial que necesita comenzar con una estructura clara, costos controlados y una operación sencilla.

Los microservicios pueden resultar apropiados cuando hay dominios bien delimitados, necesidades de escalamiento independientes y equipos preparados para operar una plataforma distribuida.

Pero ¿cómo podemos evaluar objetivamente cuál de estas alternativas conviene a nuestro proyecto? ¿Qué debemos revisar en materia de ciberseguridad? ¿Cómo calculamos el costo real de una migración? ¿Y qué ocurre cuando una nueva dirección decide cambiar la arquitectura sin comprender el sistema existente?

Estas son preguntas que no podemos responder únicamente desde el código.

En la segunda parte veremos cómo evaluar las alternativas, identificar riesgos de seguridad, calcular los costos a largo plazo y reconocer cuándo una migración realmente tiene sentido.

Porque elegir una arquitectura es importante. Pero saber cuándo cambiarla y cómo hacerlo sin perjudicar al negocio es todavía más importante.

Continuará en la Parte 2: Cómo elegir la arquitectura correcta: negocio, seguridad y costos.