Ingeniería SaaS

Modernizar el stack tecnológico sin reescribirlo todo: migración progresiva, Go y Next.js

Por Mostafa EL MouaddinePublicado el 12 de octubre de 202611 min de lectura

Modernizar el stack tecnológico consiste en sustituir de forma progresiva lo que frena las entregas, la seguridad o el crecimiento, sin detener el servicio ni reescribirlo todo de golpe. El método más seguro es la migración progresiva: una fachada delante del sistema existente y, después, un módulo tras otro. Para una arquitectura SaaS, Go en los servicios, Next.js y TypeScript en la interfaz y Python para la IA y los datos forman una combinación sólida, siempre que el equipo sepa sacarle partido, algo que no siempre ocurre.

¿Qué señales indican que un stack tecnológico debe modernizarse?

Una tecnología antigua no es un problema en sí misma. Un stack se convierte en un problema cuando cuesta más de lo que aporta: cada cambio lleva más tiempo del previsto y el equipo dedica más esfuerzo a sortear el sistema que a hacerlo avanzar. Las señales que importan son observables:

• Entregas lentas y arriesgadas: cada puesta en producción se hace a mano, a menudo de noche, con el temor de romper otra cosa.
• Dependencias al final de su vida útil: framework, lenguaje o sistema operativo que ya no reciben parches de seguridad.
• Conocimiento concentrado: solo una o dos personas entienden el núcleo del sistema, y contratar perfiles con esa tecnología se vuelve difícil.
• Escalado costoso: la única respuesta a más usuarios es un servidor más grande, y los picos de tráfico se traducen en incidencias.
• Bloqueos de producto: resulta imposible abrir una API a un socio, añadir un idioma, alojar a un segundo cliente en la misma plataforma o conectar limpiamente un modelo de IA.

Una señal aislada suele resolverse de forma local. Cuando se acumulan varias, la pregunta ya no es si hay que modernizar, sino en qué orden. Antes de elegir tecnologías, formalice los objetivos de negocio y las restricciones: esa es la función de un buen pliego de condiciones de software.

Rediseño de una aplicación: ¿por qué evitar la reescritura completa?

La tentación de tirarlo todo y empezar de cero es grande. En la práctica, una reescritura «big bang» congela el producto durante meses: el sistema antiguo sigue evolucionando para los clientes, el nuevo persigue un objetivo en movimiento y la migración final concentra todos los riesgos en un solo fin de semana. Las reglas de negocio implícitas, nunca documentadas pero bien presentes en el código, son además las primeras en desaparecer.

La alternativa probada es la migración progresiva, a menudo llamada strangler pattern (por la higuera estranguladora, imagen popularizada por Martin Fowler): el nuevo sistema crece alrededor del antiguo y lo sustituye función a función.

1. Colocar una fachada (proxy inverso o pasarela de API) delante de la aplicación existente, sin cambiar nada para los usuarios.
2. Elegir un primer ámbito limitado, útil y de bajo riesgo: la búsqueda, las notificaciones o un módulo de informes, por ejemplo.
3. Reconstruirlo en el nuevo stack y enrutar después ese tráfico hacia él a través de la fachada.
4. Medir, corregir y repetir con el siguiente ámbito.
5. Eliminar el código antiguo a medida que se avanza; de lo contrario, el equipo mantendrá dos sistemas indefinidamente.

Cada etapa aporta valor y es reversible: si el nuevo servicio se comporta mal, la fachada devuelve el tráfico al antiguo mientras se corrige. El punto delicado está en otra parte: durante la transición, el código antiguo y el nuevo suelen compartir los mismos datos. Defina desde el principio qué sistema es la referencia para cada dato y aísle el código nuevo de las particularidades del modelo histórico mediante una capa de traducción (una «capa anticorrupción»); de lo contrario, la deuda técnica migra junto con el código.

¿Por qué Go y Next.js para una arquitectura SaaS?

Next.js, Go, Python y TypeScript forman el stack principal de Codevista Innovations. Los motivos son operativos y valen para cualquier equipo que esté evaluando esta combinación.

Go para los servicios de backend

• Concurrencia sencilla: las goroutines y los channels permiten procesar en paralelo peticiones, colas de mensajes y llamadas externas sin gestionar hilos a mano.
• Un único binario: un servicio Go se compila en un ejecutable autónomo, que puede ser totalmente estático. El contenedor sigue siendo ligero y no hay que instalar ningún runtime en el servidor.
• Rendimiento predecible: lenguaje compilado, arranque rápido y, por lo general, un consumo de memoria modesto. La infraestructura se dimensiona con más facilidad.
• Operación sencilla: biblioteca estándar completa (HTTP, JSON, criptografía), herramientas integradas para pruebas, formateo y perfilado, y compilación cruzada hacia otros sistemas.
• Código legible para todo el equipo: el lenguaje es deliberadamente reducido, lo que facilita las revisiones de código y la incorporación de nuevos desarrolladores.

Go encaja especialmente bien en API, servicios de integración (pagos, ERP, mensajería), procesos asíncronos y componentes que deben soportar carga.

Next.js y TypeScript para el frontend

Next.js añade a React el renderizado en el servidor y la generación estática. Las páginas públicas llegan al navegador ya construidas, algo que cuenta para el posicionamiento orgánico (SEO), para el tiempo de carga en móvil y para compartir en redes sociales. El ecosistema React, uno de los más extendidos del frontend, aporta componentes y bibliotecas de interfaz, y facilita la contratación.

TypeScript aporta contratos tipados: los datos que se intercambian con el backend se describen una sola vez, por ejemplo a partir de un esquema OpenAPI generado por los servicios Go. Un campo renombrado en la API rompe entonces la compilación, no la producción. Por último, Next.js facilita la migración progresiva: sus reglas de reescritura sirven las páginas nuevas y redirigen las demás a la aplicación histórica, página a página.

Python allí donde viven la IA y los datos

Python sigue siendo el lenguaje de referencia para los datos y la inteligencia artificial: tratamiento de datos, aprendizaje automático, SDK de los proveedores de modelos de lenguaje. En lugar de forzar ese trabajo en Go, es mejor aislarlo en servicios Python dedicados, invocados mediante una API interna o una cola de mensajes. Esta división mantiene cada lenguaje en su terreno y permite aplicar reglas de seguridad más estrictas al ámbito que maneja datos sensibles, por ejemplo cuando se orquestan agentes de IA. El precio: un lenguaje más que mantener, probar y supervisar. Si la IA se reduce a unas cuantas llamadas a la API de un proveedor de modelos, un servicio en Go o TypeScript suele bastar.

¿Cuándo no elegir Go y Next.js?

Ningún stack sirve para todo. Estos son los casos en los que otras opciones, o mantener lo que hay, resultan más razonables:

• El equipo ya domina un stack sano. Una aplicación Laravel, Django, Java o .NET bien mantenida, con pruebas y desplegada con regularidad no justifica un cambio de lenguaje. Modernice las prácticas antes que las tecnologías.
• Un back-office interno sencillo. Para una herramienta de gestión sin exigencias de carga, un framework «todo incluido» con panel de administración generado suele entregar más rápido que unos servicios Go.
• Una aplicación completamente tras autenticación. Sin páginas públicas, el argumento SEO de Next.js desaparece; una aplicación React clásica puede bastar y es más sencilla de alojar.
• Un dominio de negocio con muchas reglas. Go prioriza la sencillez a costa de algo de repetición; algunos equipos prefieren un lenguaje más expresivo para modelar un dominio complejo.
• Sin capacidad de operación. Varios servicios implican monitorización, registros centralizados y despliegue automatizado. Sin esa base, un monolito bien estructurado es más seguro que unos microservicios mal supervisados.

Tenga en cuenta también el ritmo de Next.js: sus versiones principales evolucionan rápido y seguir esas actualizaciones exige tiempo planificado.

Arquitectura multi-tenant: prepararse para el crecimiento internacional

Un SaaS multi-tenant da servicio a numerosas organizaciones cliente, los tenants (inquilinos), en una misma plataforma. Apuntar a varios países multiplica los tenants y las exigencias de separación. El modelo de aislamiento se elige pronto, porque después es difícil cambiarlo:

• Base compartida con identificador de tenant: el modelo más económico, pero cada consulta debe filtrar correctamente; la seguridad a nivel de fila de PostgreSQL añade una salvaguarda útil.
• Un esquema por tenant: mejor separación, pero migraciones más pesadas de orquestar.
• Una base de datos por tenant: aislamiento fuerte y posibilidad de localizar los datos país por país, a cambio de una operación más compleja.

Más allá de la base de datos, lo internacional impone decisiones concretas: varios idiomas, entre ellos el árabe, que se escribe de derecha a izquierda; zonas horarias, divisas, medios de pago (el CMI, el Centre Monétique Interbancaire, para los pagos con tarjeta en Marruecos, y otros proveedores como Stripe según los países donde esté establecida la entidad que factura) y cumplimiento normativo. En Marruecos, la ley 09-08 regula el tratamiento de datos personales, incluida su transferencia al extranjero; la CNDP, la Comisión Nacional de Control de la Protección de Datos Personales, es la autoridad de control a la que conviene consultar. Cada país de destino puede añadir sus propias normas: verifíquelas antes de decidir dónde alojar los datos. Nuestra guía sobre el desarrollo de SaaS a medida en Marruecos detalla estas decisiones.

¿Cómo secuenciar la modernización de una aplicación?

El orden de las etapas importa tanto como las tecnologías elegidas. Una secuencia que limita los riesgos:

1. Auditoría y mapa del sistema: inventario de componentes, dependencias, flujos de datos y puntos problemáticos, clasificados por valor de negocio y por riesgo.
2. Base de entrega: integración y despliegue continuos, pruebas automatizadas en los recorridos críticos y monitorización. Sin esa red de seguridad, cada migración es una apuesta.
3. Fachada y primer ámbito: puesta en marcha del proxy y, después, migración de un módulo de alto valor y bajo riesgo para validar el enfoque.
4. Frontend Next.js progresivo: primero las páginas públicas, donde el renderizado en el servidor influye en el SEO y en el tiempo de carga; después, las pantallas de la aplicación.
5. Los datos, al final: la base de datos es la parte más arriesgada; mígrela dominio a dominio, con scripts de verificación y un plan de vuelta atrás.
6. Retirada y transferencia: cada módulo sustituido desaparece del sistema antiguo, y el equipo interno adquiere competencias sobre el nuevo a lo largo del proyecto, no al final.

Lleve a cabo este proyecto en iteraciones cortas, con un método como Scrum: cada sprint entrega un ámbito verificable en un entorno de preproducción (staging) antes de pasar a producción. Si confía todo o parte del trabajo a un proveedor, nuestros criterios para elegir una agencia de desarrollo en Casablanca le ayudarán a plantear las preguntas adecuadas, en particular sobre la seguridad de los datos.

Codevista Innovations acompaña este proceso, desde el diagnóstico de su stack actual hasta el diseño de arquitecturas multi-tenant en Go y Next.js, desde Casablanca para Marruecos y el mercado internacional. Nuestros proyectos arrancan con una fase de descubrimiento y diseño, y después avanzan en sprints de dos semanas entregados en staging para su validación. Para analizar su situación, cuéntenos su proyecto.

Preguntas frecuentes

¿Cuánto tiempo se tarda en modernizar una aplicación existente?

Depende del tamaño del sistema, de la calidad del código existente y de la disponibilidad del equipo: ninguna cifra genérica es fiable. La ventaja de la migración progresiva es precisamente no depender de una única fecha de cambio. Un primer ámbito puede pasar a producción mucho antes de que termine el proyecto, y los módulos siguientes se encadenan según su valor. Una auditoría inicial permite establecer una secuencia y una estimación realistas.

¿Se puede conservar la base de datos actual al pasar a Go y Next.js?

Sí, y al principio suele ser lo recomendable. Go dispone de drivers maduros para las principales bases de datos relacionales, entre ellas PostgreSQL, MySQL y SQL Server. Los nuevos servicios pueden, por tanto, leer y escribir en la base existente durante la transición. Después, el esquema se migra dominio a dominio, una vez estabilizados los servicios, con scripts de control de coherencia y un plan de vuelta atrás.

¿Go o Node.js para el backend de un SaaS?

Ambos son defendibles. Node.js permite compartir TypeScript entre frontend y backend, lo que simplifica la vida de un equipo pequeño. Go aporta un único binario y una concurrencia nativa que aprovecha todos los núcleos del procesador sin configuración especial, algo útil para API con mucha carga y servicios de integración. El criterio decisivo suele ser las competencias del equipo y las restricciones de operación, más que el rendimiento bruto.

¿Es útil Next.js para una aplicación de gestión sin necesidades de SEO?

Menos. El renderizado en el servidor de Next.js beneficia sobre todo a las páginas públicas: posicionamiento, tiempo de carga y difusión en redes sociales. Para una herramienta interna completamente tras autenticación, una aplicación React clásica puede bastar. Next.js sigue siendo pertinente si el mismo producto combina un sitio público y un área de clientes, o si desea un único framework para el enrutamiento, la internacionalización y las llamadas al servidor.