Desarrollo e Implementación de Sistemas en la Nube: Guía de Estudio Integral

Este documento constituye un material de estudio exhaustivo basado en las directrices académicas para el desarrollo de proyectos en la nube. Explica desde los fundamentos de la arquitectura de sistemas distribuidos hasta la implementación técnica de la comunicación entre servicios.

1. Introducción General

El desarrollo de sistemas en la nube no se limita únicamente a la escritura de código; implica la capacidad de diseñar, documentar y defender una arquitectura donde múltiples componentes (frontend, diversos backends y bases de datos) interactúan de manera fluida. El enfoque de esta unidad es la Práctica Profesionalizante, donde el estudiante asume el rol de desarrollador frente a un "Líder Técnico" (CTO) o "Director Ejecutivo" (CEO), priorizando el entendimiento de los flujos de datos y la calidad de la documentación sobre la mera codificación.

2. Contexto del Tema y Relevancia

En el entorno laboral actual, el uso de la Inteligencia Artificial (IA) se ha convertido en un multiplicador de productividad (estimado en hasta 100 veces). Por ello, el foco educativo se desplaza de la escritura manual de código hacia la capacidad de:

• Analizar requerimientos.
• Diseñar arquitecturas escalables.
• Interpretar y defender el código generado por herramientas de IA.
• Garantizar la comunicación correcta entre sistemas distribuidos mediante protocolos estandarizados (HTTP).

3. Marco Conceptual y Definiciones Clave

Para abordar el desarrollo en la nube desde cero, es fundamental comprender los siguientes términos:

Conceptos Fundamentales

• Frontend: La capa de presentación (interfaz de usuario) que interactúa con el cliente.
• Backend: La lógica de negocio y procesamiento de datos que corre en el servidor.
• API (Application Programming Interface): Interfaz que permite que dos aplicaciones se comuniquen entre sí. En este contexto, se utilizan para resolver problemas o funciones específicas.
• Microservicios (Nivel Académico): Aunque un microservicio estricto debería resolver una sola función atómica y ser autónomo, en este nivel se trabaja con APIs funcionales (varios backends que dividen responsabilidades, por ejemplo, una API de Usuarios y una API de Gastos).
• La Nube (Cloud): Físicamente, son servidores (computadoras) alojados en centros de datos remotos. Alquilar "la nube" es usar la infraestructura de terceros (Google, Amazon, etc.) para no administrar el hardware físico.

Herramientas y Protocolos

• Axios: Librería de JavaScript utilizada para realizar peticiones HTTP (GET, POST, PUT, DELETE) desde un sistema a otro.
• JSON (JavaScript Object Notation): Formato estándar de intercambio de datos que utilizan las APIs para responder a las solicitudes.
• JWT (JSON Web Token): Método para transmitir información de forma segura entre partes como un objeto JSON, utilizado frecuentemente para autenticación.
• Cuentas de Conexión (Connection Strings): Cadenas de texto que contienen el protocolo, usuario, contraseña, dirección del servidor y puerto necesarios para conectar un backend con una base de datos.

4. Desarrollo del Tema: Arquitectura y Comunicación

4.1. Comunicación entre Backends

Una de las bases de los sistemas distribuidos es que un backend pueda solicitar información a otro.

Proceso de conexión paso a paso:

1. Instanciación: Se levantan los servicios en puertos diferentes (ej. Backend A en puerto 3000, Backend B en puerto 3001).
2. Petición (Request): El Backend A utiliza una librería como Axios para hacer un get a la URL del Backend B.
3. Procesamiento: El Backend B recibe la petición, busca los datos (en su memoria o base de datos) y responde un JSON.
4. Transformación: El Backend A recibe el JSON, puede modificar los datos (ej. agregarles un cálculo o vincularlos con otros datos) y finalmente entrega la respuesta al Frontend.

4.2. Persistencia de Datos

Los sistemas en la nube deben ser distribuidos. Esto implica que la base de datos no reside en el mismo servidor que el código del backend.

• Bases de Datos No Relacionales (Ej. MongoDB): Organizan la información en colecciones y documentos.
• Bases de Datos Relacionales (Ej. PostgreSQL en Superbase/Neon): Utilizan tablas y lenguaje SQL para consultas (SELECT, INSERT).

5. Relaciones entre Conceptos

El sistema funciona como una red de dependencias lógicas:

1. El Usuario interactúa con el Frontend.
2. El Frontend hace peticiones al Backend/API Gateway.
3. El Backend puede comunicarse con otros Backends para obtener información complementaria.
4. Cada Backend tiene su propia conexión a una Base de Datos (principio de responsabilidad única).
5. Todo este flujo se valida mediante Códigos de Estado HTTP (ej. 200 OK, 201 Created, 404 Not Found, 500 Server Error).

6. Ejemplos Prácticos

Caso: Sistema de Gestión de Gastos Personales

• Componente 1 (Frontend): Pantallas de Login, Registro y Tablero de Gastos.
• Componente 2 (API Usuarios): Maneja la creación de cuentas y sesiones. Se conecta a una DB de usuarios.
• Componente 3 (API Gastos): Maneja el listado y categorías de gastos. Se conecta a una DB de movimientos financieros.
• Flujo: Cuando el usuario logueado quiere ver sus gastos, el Frontend le pide a la API de Gastos, la cual podría validar con la API de Usuarios si el token es válido antes de entregar la información.

Caso: Catálogo de Autos (Comunicación entre servicios)

Si el Servicio A tiene los datos básicos de autos (Fiat, Toyota) y el Servicio B necesita mostrar esos autos pero con un cálculo de impuestos o asignación de dueño:

1. Servicio B llama a GET http://localhost:3001/autos.
2. Servicio B recibe el array de autos.
3. Servicio B aplica un .map() en JavaScript para agregar la propiedad dueño: "Juan Pérez" a cada objeto.
4. Servicio B responde al cliente el objeto modificado.

7. Errores Comunes y Aclaraciones

• Confusión entre "La Nube" y "Tiempo Real": Estar en la nube significa que el sistema es accesible vía internet en servidores remotos. "Tiempo real" se refiere a la velocidad de respuesta (milisegundos) y notificación instantánea de cambios. No son sinónimos, aunque suelen coexistir.
• Subestimar la Documentación: Un error frecuente es creer que el código es lo único que importa. En una defensa técnica, si el código funciona pero el desarrollador no puede explicar el Diagrama de Secuencia o por qué eligió un código HTTP específico, el proyecto no se considera aprobado.
• Manejo de Errores: No devolver un código de error adecuado. Si un recurso no existe, el sistema debe devolver un 404, no un 500 (que indica que el servidor se rompió) ni un 200 (que indica éxito).

8. Síntesis y Conclusiones (Resumen Modo Estudio)

• Objetivo: Crear un producto mínimo viable (MVP) vendido como una solución de negocio, respaldado por documentación técnica sólida.
• Arquitectura: Sistemas distribuidos (Frontend, Múltiples Backends, Bases de Datos remotas).
• Documentación Obligatoria: Diagramas de arquitectura de alto nivel, diagramas de secuencia por cada historia de usuario, wireframes (diseño de pantallas) e historias de usuario.
• Evaluación: Se realiza mediante la inspección del tráfico de red (Network tab del navegador) para verificar que los pedidos y respuestas cumplan con el diseño documentado.

9. Preguntas de Repaso

Básicas

1. ¿Qué es una API y para qué sirve en un sistema de nube?
2. ¿Cuál es la diferencia física entre un servidor local y "la nube"?
3. ¿Qué significa el código HTTP 201?

Intermedias

4. Explique el flujo de datos cuando un Backend A requiere información del Backend B usando Axios.
5. ¿Para qué sirve un "Connection String" y qué elementos lo componen?
6. ¿Cuál es la función de un Balanceador de Carga (Load Balancer)?

Avanzadas

7. En un diagrama de secuencia para un proceso de Login, ¿qué actores y componentes deberían intervenir y qué métodos HTTP se utilizarían?
8. Si una base de datos devuelve un valor nulo al buscar un ID, ¿qué lógica debe aplicar el backend antes de responder al frontend?
9. Explique la relación entre el Modelo OSI y la capa de Aplicación (HTTP) donde trabajan los desarrolladores de software.

10. Fechas Importantes y Avisos Académicos

Fecha	Tipo de Evento	Descripción Detallada
10 de noviembre	Entrega Final (PP3)	Fecha límite para la presentación del proyecto integrador completo.

Recordatorios e Indicaciones del Profesor:

• Metodología Recomendada: Trabajar de forma iterativa e incremental. Empezar por algo pequeño y ampliarlo.
• Sincronización: Se recomienda unificar el tema del proyecto con otras materias (Backend, Frontend e Ingeniería de Software) para ahorrar tiempo de documentación y desarrollo.
• Uso de IA: Está permitido y se fomenta el uso de IA para generar código y documentación, siempre que el estudiante sea capaz de defender y explicar cada línea y concepto ante el profesor.
• Defensa Técnica: El profesor actuará como CEO/CTO. Se evaluará la venta del producto y la solidez técnica de la arquitectura. No se revisará el código línea por línea, sino el comportamiento del sistema en la consola de red del navegador.
• Temas Pendientes: La próxima clase se profundizará en JWT (JSON Web Tokens) y métodos para subir el backend a servidores como Versel o Render.

1. Video resumen

2. Infografía

3. Presentación