Merge pull request #33 from picosini/main

Patrones de diseño adaptados a arquitecturas serverless, por 21211934

Author: IoTeacher

docs/temas/Patrones de diseño adaptados a arquitecturas serverless/ANEXO.md

@@ -0,0 +1,26 @@
+
+
+# Referencias académicas (APA, 7ª edición)
+- Fowler, M. (2019). *Patterns of Enterprise Application Architecture*. Addison-Wesley. (pp. 45–60)  
+- Richards, M., & Ford, N. (2020). *Fundamentals of Software Architecture*. O’Reilly Media. (pp. 210–230)  
+- Roberts, M. (2016). Serverless architectures. *MartinFowler.com*. https://martinfowler.com/articles/serverless.html  
+- Adzic, G., & Chatley, R. (2017). Serverless computing: Economic and architectural impact. *Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering*, 884–889. https://doi.org/10.1145/3106237.3117767  
+- Villamizar, M., et al. (2016). Infrastructure cost comparison of running web applications in the cloud using AWS Lambda and monolithic and microservice architectures. *IEEE 11th International Symposium on Service-Oriented System Engineering*, 249–261. https://doi.org/10.1109/SOSE.2016.46  
+
+---
+# ANEXO – Uso de LLMs en la investigación
+
+## Prompts utilizados
+1. "Haré una investigación sobre el tema 'Patrones de diseño adaptados a arquitecturas serverless', la rúbrica de evaluación debe contener [...]. Bríndame la información necesaria para hacer un buen trabajo universitario."
+2. "Incluye ejemplos, comparaciones prácticas y organiza la información en un `readme.md` y un `ANEXO.md`."
+
+## Reflexión ética
+
+Al usar ChatGPT para esta investigación, me di cuenta de que es una herramienta útil para organizar ideas y dar ejemplos, pero no debe reemplazar el aprendizaje personal. Yo soy responsable de revisar la información y confirmar que sea correcta, porque no todo lo que genera la inteligencia artificial es 100% confiable.  
+
+Creo que usar IA en la escuela puede ser positivo si se aplica con honestidad, reconociendo su uso y combinándolo con libros, artículos y lo que se ve en clase. De esa forma, no se convierte en “hacer trampa”, sino en un apoyo para aprender mejor y entregar trabajos más completos.  
+
+El uso de modelos de lenguaje (LLMs) como ChatGPT permitió acelerar la investigación y obtener ejemplos prácticos. Sin embargo:
+- La información obtenida fue **contrastada con fuentes académicas** (libros, artículos y papers).  
+- Se reconoció explícitamente el uso de la IA en este **ANEXO.md**, cumpliendo con los principios de **transparencia académica**.  
+- El LLM fue usado como **asistente de redacción y estructuración**, no como fuente única de conocimiento.  

docs/temas/Patrones de diseño adaptados a arquitecturas serverless/readme.md

@@ -0,0 +1,58 @@
+# Patrones de Diseño Adaptados a Arquitecturas Serverless
+
+## 🎯 Introducción
+Las arquitecturas **serverless** representan un cambio significativo en el paradigma de diseño de software. En lugar de gestionar servidores físicos o virtuales, los desarrolladores despliegan funciones que se ejecutan bajo demanda en plataformas como AWS Lambda, Azure Functions o Google Cloud Functions.  
+Este modelo promueve **escalabilidad, reducción de costos y simplicidad operativa**, pero también introduce nuevos retos en cuanto a **patrones de diseño, calidad y refactorización** del software.
+
+---
+
+## 🏗️ Presentación
+Los **patrones de diseño** en entornos tradicionales (orientados a objetos o microservicios) deben adaptarse a un contexto **sin servidores** donde:
+- El **estado es efímero**.
+- La **latencia entre funciones** puede impactar la experiencia.
+- La **observabilidad** y la **trazabilidad** se vuelven críticas.
+- La **refactorización continua** es necesaria por la alta dependencia en proveedores cloud.
+
+---
+
+## 📊 Ejemplos y comparaciones prácticas
+
+### 🔹 Ejemplo 1: Singleton en Serverless
+En entornos clásicos, el **Singleton** asegura que solo exista una instancia de un objeto.  
+En serverless, cada función puede ejecutarse en un contenedor independiente, lo que rompe esta garantía.  
+**Adaptación**: Uso de almacenamiento centralizado (Redis, DynamoDB, S3) para compartir estado en lugar de memoria local.
+
+### 🔹 Ejemplo 2: Adapter para integraciones externas
+Las funciones serverless a menudo necesitan integrarse con APIs externas. El **Adapter Pattern** permite desacoplar las diferencias de interfaces y facilita la refactorización si cambia el proveedor (ejemplo: cambiar de Stripe a PayPal).
+
+### 🔹 Ejemplo 3: Chain of Responsibility para manejo de eventos
+En aplicaciones basadas en eventos (ej. IoT o e-commerce), múltiples funciones pueden procesar un evento en secuencia. El **Chain of Responsibility** se adapta bien a este modelo, permitiendo un pipeline claro y extensible.
+
+---
+
+## 🔄 Relación directa con refactorización, calidad o patrones
+- **Refactorización**: Migrar un monolito a serverless exige repensar patrones existentes. Por ejemplo, refactorizar un Observer local a un Event-driven basado en colas como **SQS** o **Pub/Sub**.  
+- **Calidad**: La adopción de patrones adecuados mejora la mantenibilidad, reduce la duplicación de código y permite mayor resiliencia.  
+- **Patrones de diseño**: Aunque fueron pensados para objetos, muchos pueden evolucionar a “patrones cloud-native”, como:
+  - **Circuit Breaker** para tolerancia a fallos.
+  - **Event Sourcing** para trazabilidad de estados.
+  - **Strangler Fig Pattern** para migración progresiva de sistemas legados hacia serverless.
+
+---
+
+## 💡 Análisis y reflexión crítica 
+Los patrones tradicionales no pueden aplicarse de forma directa en arquitecturas serverless debido a:
+- **Entorno efímero**: No existe memoria compartida persistente.
+- **Costos variables**: Un mal patrón puede disparar costos en la nube.  
+- **Dependencia de terceros**: El lock-in con el proveedor obliga a elegir patrones portables.  
+
+**Reflexión**:  
+Serverless no elimina la necesidad de patrones, la intensifica. Refactorizar con patrones adecuados permite lograr **escalabilidad limpia, resiliencia y portabilidad**. El reto está en adaptar lo aprendido de la POO y microservicios a un entorno **event-driven** y **cloud-native**.
+
+---
+
+## 📌 Conclusión
+Los **patrones de diseño en arquitecturas serverless** no solo son aplicables, sino **necesarios**. Permiten enfrentar los retos de la efimeridad, el escalado automático y la refactorización continua.  
+La correcta adaptación de patrones como Singleton, Adapter, Observer o Chain of Responsibility asegura que los sistemas serverless mantengan **alta calidad, resiliencia y mantenibilidad** en un entorno en constante cambio.
+
+---