Clase 5 - Martes, 08 de septiembre de 2026 (08 09 26) - Desarrollo e Implementación de sistemas en la nube
Desarrollo e Implementación de Sistemas en la Nube: Arquitectura, Diagramación y Documentación Técnica
Este documento constituye una guía exhaustiva sobre el desarrollo de sistemas modernos basados en la nube, centrándose en la arquitectura de microservicios, la documentación técnica obligatoria y las mejores prácticas de implementación discutidas en el ámbito académico especializado.
1. Introducción General
El desarrollo de sistemas en la nube requiere una transición del pensamiento monolítico hacia estructuras distribuidas y desacopladas. Este enfoque permite que diferentes componentes (Frontend y múltiples Backends) interactúen de manera eficiente, garantizando escalabilidad y seguridad. La clave de un proyecto exitoso no reside solo en el código, sino en la calidad de la documentación técnica y la claridad de la arquitectura propuesta.
2. Contexto del Tema
En el marco del desarrollo de sistemas actuales, se espera que una aplicación no sea un bloque único, sino un ecosistema de servicios que se comunican a través de protocolos estandarizados (como REST). El uso de servicios en la nube (PaaS y SaaS) facilita la delegación de responsabilidades de infraestructura, permitiendo a los desarrolladores centrarse en la lógica de negocio y en la orquestación de servicios.
3. Importancia y Relevancia
La correcta implementación de estos sistemas es crítica por tres razones fundamentales:
- Independencia de Componentes: Permite que un error en un servicio no derribe el sistema completo.
- Seguridad de Datos: El aislamiento de bases de datos previene accesos no autorizados por descuido o desconocimiento.
- Escalabilidad: Cada parte del sistema puede crecer de forma independiente según la demanda del usuario.
4. Marco Conceptual
Definición de Conceptos Clave
- Frontend: La interfaz con la que interactúa el usuario (puede ser web, mobile, de escritorio o incluso para dispositivos como relojes inteligentes). Su función principal es la presentación y la interacción inicial.
- Backend (API): El servidor que resuelve la lógica de negocio, procesa información y se comunica con la base de datos. Un sistema robusto suele tener múltiples APIs especializadas (ej. una para usuarios, otra para turnos).
- Diagrama de Arquitectura/Componentes: Representación visual de la estructura física y lógica del sistema, mostrando dónde reside cada servicio y cómo se conectan.
- Diagrama de Secuencia: Representación de la interacción temporal entre objetos o componentes en un escenario específico, mostrando el orden de los mensajes intercambiados.
- Desacoplamiento: Práctica de mantener los componentes del sistema lo más independientes posible.
- JWT (JSON Web Token): Estándar para la transmisión segura de información entre partes como un objeto JSON, comúnmente usado para autenticación.
5. Desarrollo del Tema
5.1. Estrategia de Diagramación
La documentación debe ser lo más completa posible. La regla general es: "cuanto más, mejor", siempre que aporten valor y no sean redundantes.
- Cantidad y Profundidad: Se recomiendan entre 10 y 15 diagramas de secuencia para las funciones más importantes. La profundidad depende de la complejidad del negocio:
- Negocio complejo: Menos diagramas, pero con mayor profundidad técnica.
- Negocio simple: Más diagramas, pero con menor profundidad.
- Legibilidad: Un diagrama debe ser legible en una sola pantalla o en una hoja de Word. Si se vuelve demasiado denso, se deben utilizar referencias (Ref) para delegar partes de la lógica (como el manejo de errores) a subdiagramas.
5.2. Arquitectura de Conectividad y Seguridad
Un principio innegociable es que un Backend nunca debe acceder directamente a la base de datos de otro Backend.
- Acceso a Datos: Cada API es dueña de su base de datos. Si una API necesita datos de otra, debe solicitarlos a través de un llamado REST (HTTP), no mediante una conexión SQL directa a la base ajena.
- Analogía del Edificio: Si el sistema fuera un edificio, lo correcto es que cada desarrollador tenga la llave solo de su habitación (su base de datos) y no la llave maestra del edificio que permite entrar a todas las habitaciones. Esto evita errores de acceso por descuido.
- Orquestación: En grupos grandes (ej. 5 personas), se puede implementar un Gateway. Este componente centraliza la seguridad (validación de JWT) y orquesta los llamados a los distintos microservicios para devolver una respuesta consolidada al Frontend.
5.3. Comunicación Frontend-Backend
La comunicación se realiza mediante peticiones HTTP. Es vital configurar correctamente las cabeceras:
- Accept:
application/json - Content-Type:
application/json - CORS (Cross-Origin Resource Sharing): Un error común que debe resolverse para permitir que el Frontend (ej. en Vercel) hable con el Backend (ej. en Render).
6. Relaciones entre Conceptos
El sistema funciona como una cadena de dependencias lógicas:
- El Frontend dispara una acción del usuario.
- Se realiza un Request a una API específica.
- La API realiza Validaciones (de formato y de negocio).
- Si es exitoso, la API interactúa con su Base de Datos.
- Se devuelve un Status Code adecuado (200 OK, 201 Created, 400 Bad Request, etc.).
7. Ejemplos Prácticos
Caso: Proceso de Sacar un Turno
Un diagrama de secuencia técnico para esta funcionalidad debe seguir estos pasos lógicos:
- Petición Inicial: El usuario solicita "Sacar Turno" en la web.
- Validación de Formato: El Backend verifica que los datos recibidos (ID de profesional, fecha) sean correctos. Si fallan, devuelve un
400 Bad Request. - Validación de Negocio: El Backend verifica internamente la disponibilidad del profesional y el horario. Si el usuario no es válido o hay conflicto, puede devolver un
422 Unprocessable Entity. - Persistencia: Se realiza el
INSERTen la base de datos de turnos. - Respuesta Final: Se devuelve un
201 Createdcon el objeto del turno generado.
Estructura de Hosting Recomendada
Para demostrar la independencia del sistema, se sugiere distribuir los componentes en diferentes plataformas:
- Frontend: Netlify o Vercel (solo contenido estático HTML/JS).
- Backend A (Usuarios): Render (con su propia base de datos).
- Backend B (Turnos): Railway o AWS (con su propia base de datos).
- Base de Datos: MongoDB Atlas o Supabase.
8. Errores Comunes y Confusiones
- Acceso Cruzado de Bases de Datos: Es el error más grave. Cada API debe ser estricta con su propia persistencia.
- Error 500 (Internal Server Error): En una entrega académica, ver un error 500 es motivo de reprobación directa, ya que indica un fallo no controlado en el servidor.
- Falta de validación de formato: Enviar datos vacíos o con tipos incorrectos y que el servidor no responda con un error claro (400).
- Confusión entre Wireframe y Mockup:
- Wireframe: Estructura básica en blanco y negro para validar funcionalidad y navegación.
- Mockup: Diseño visual final con colores y datos simulados para validar la experiencia de usuario.
9. Síntesis y Conclusiones
El desarrollo en la nube se basa en la especialización y el aislamiento. La documentación técnica (diagramas de secuencia y arquitectura) no es un trámite administrativo, sino la hoja de ruta que garantiza que el sistema sea comprensible y mantenible. Un buen sistema debe manejar correctamente los códigos de estado HTTP, validar cada entrada de datos y mantener una separación clara entre las responsabilidades de cada microservicio.
10. Fechas Importantes y Avisos Académicos
| Evento / Acción | Detalle / Indicación del Profesor |
| Tiempo Restante | Quedan aproximadamente 8 clases (2 meses). Se recomienda "meter pata" (acelerar el ritmo). |
| Estado Actual Esperado | A esta altura, el diagrama de arquitectura y el primer diagrama de secuencia ya deberían estar resueltos y el mockup visual iniciado. |
| Entrega Final | Debe incluir la aplicación funcional (links de hosting) y documentación completa (PDF, MD o HTML). |
| Evaluación de Código | El profesor no evaluará el código línea por línea para la nota, pero sí validará que los endpoints funcionen y que la arquitectura documentada coincida con la realidad. |
| Presentación Final | Será de carácter presencial, con instancias de refuerzo virtual para correcciones menores si fuera necesario. |
11. Preguntas de Repaso
Básicas
- ¿Cuál es la diferencia principal entre un Frontend y un Backend?
- ¿Por qué es importante el desacoplamiento en un sistema en la nube?
- ¿Qué plataformas se mencionan para hostear un Frontend estático?
Intermedias
- Explique la analogía del "edificio y las llaves" en relación con las bases de datos.
- ¿Qué sucede si un diagrama de secuencia se vuelve demasiado complejo de leer?
- ¿Para qué sirve el código de estado HTTP 422?
Avanzadas
- En un grupo de 5 personas, ¿qué rol cumple un "Gateway" y qué beneficios aporta a la arquitectura?
- Describa el flujo de validaciones que debería tener un método POST para crear un recurso antes de llegar a la base de datos.
- ¿Por qué el uso de diferentes plataformas de hosting para cada backend (ej. Render y Vercel) se considera una buena práctica académica en esta materia?