Módulo 2 Clase 3 Corrección supuesto MUESTREOS IGAE microservicios

Arquitectura Lógica y Diagrama de Casos de Uso

Introducción a la Arquitectura Lógica

• Se retoma el tema de la arquitectura lógica, enfocándose en los diagramas de paquetes y componentes.

• Se menciona que aunque el examen puede variar, el conocimiento requerido es similar entre las versiones A1 y A2.

Diferencias entre Exámenes A1 y A2

• En los últimos años, se ha observado que en el examen A1 no se utilizan diagramas de casos de uso, lo cual representa un cambio significativo.

• La experiencia personal del hablante indica que es crucial adaptarse a estos cambios para poder realizar un diagrama efectivo durante el examen.

Importancia del Vocabulario en Modelado

• El vocabulario utilizado en los diagramas debe reflejar nombres relevantes al negocio modelado, evitando términos genéricos como "paquete 23".

• Se enfatiza la necesidad de utilizar un vocabulario específico del enunciado para nombrar casos de uso y subsistemas.

Modelado Efectivo con Diagramas

Proceso de Identificación

• Al analizar un caso práctico, se deben identificar claramente las interfaces web necesarias para diferentes tipos de usuarios.

• Se propone una estructura clara: capa de presentación con módulos específicos para cada tipo de usuario identificado.

Agrupación y Diseño

• La agrupación adecuada de casos de uso permite crear subsistemas coherentes dentro del modelo general.

• Ejemplos prácticos incluyen la gestión de fondos y operaciones, donde cada módulo tiene funciones específicas relacionadas con su propósito.

Estrategias para el Examen

Toma Decisiones Rápidas

• Durante el examen, es importante tomar decisiones rápidas sobre cómo agrupar operaciones dentro de módulos sin perder tiempo excesivo.

• Cada estudiante puede tener una solución diferente basada en su comprensión del material; sin embargo, todos deben seguir una lógica coherente.

Coherencia en Modelado

• La coherencia en la forma en que se modela es clave para obtener buenos resultados. Esto incluye mantener consistencia tanto en nomenclatura como en estructura.

• Finalmente, se menciona la importancia de cerrar adecuadamente el modelo con una arquitectura física bien definida.

Subsistema de Gestión de Control y Servicios Funcionales

Introducción al Subsistema de Gestión de Control

• Se presenta un subsistema para la gestión del control de operaciones, que incluye creación, asignación, seguimiento y firma del control.

• Se menciona la capa de datos con una única base de datos relacional, sin data warehouse debido a la falta de explotación de datos.

Módulos Específicos

• El módulo de firma en el subsistema funcional se compone de componentes reutilizables; la firma del control es específica para el interventor.

• Se utiliza Java para desarrollar comunicaciones con sistemas externos como Switch SV, facilitando interacciones entre subsistemas.

Diferenciación entre Módulos

• La diferencia entre el módulo de firma y el módulo específico para el control es crucial; se enfatiza en la reutilización y reducción de dependencias.

• Un argumento clave es que cambiar el formato de firma no afectará al subsistema principal si se utilizan módulos independientes.

Importancia del Examen y Estrategias

Preparación para el Examen

• Se discute cómo responder preguntas en exámenes técnicos utilizando diagramas para identificar módulos o dominios lógicos.

• La importancia radica en leer cuidadosamente las preguntas y entender su estructura, ya que pueden variar año tras año.

Estrategias durante el Examen

• Los nervios pueden afectar la capacidad analítica; se compara a un burro con viseras que solo ve lo que tiene enfrente.

• Es esencial leer hasta el final del examen, ya que información crucial puede estar oculta en párrafos finales.

Evaluación y Ponderación

• Hay que considerar cuántos puntos vale cada pregunta; algunas tienen más peso y son críticas para obtener una buena calificación.

• La primera pregunta puede situar al candidato favorablemente ante el tribunal, por lo tanto debe ser respondida con atención.

¿Cómo abordar la lógica de negocio en un sistema?

Introducción a la pregunta y enfoque práctico

• La importancia de formular preguntas concretas en lugar de hipotéticas para una mejor comprensión del tema.

• Se sugiere que los estudiantes utilicen textos literales, pero con el riesgo de que otros hagan lo mismo, enfatizando la necesidad de personalizar las respuestas.

• Se presenta una arquitectura de tres capas: presentación, lógica de negocio y datos, destacando su ventaja en la disponibilidad de profesionales capacitados.

Detalles sobre módulos y funcionalidades

• Se recomienda estructurar las respuestas comenzando con diagramas para facilitar la lectura y comprensión por parte del tribunal.

• Enfatiza la necesidad de describir los módulos del sistema, detallando sus funcionalidades e identificando interfaces e integraciones entre ellos.

• Se hace hincapié en separar arquitectura tecnológica y funcionalidad al responder preguntas.

Diferencias entre A1 y A2

• En el examen A2 se orienta más hacia aspectos tecnológicos, mientras que el A1 se centra en descripciones funcionales.

• Ejemplos anteriores muestran cómo las preguntas pueden mezclar aspectos arquitectónicos y tecnológicos, lo que requiere versatilidad en las respuestas.

Preparación para el examen

• La preparación debe centrarse no solo en escribir pliegos o programar, sino también en aprobar con buenas calificaciones.

• Es crucial ser capaz de identificar rápidamente lo que se está preguntando para responder adecuadamente a cada sección del examen.

Conclusiones sobre arquitectura lógica

• La discusión se centra exclusivamente en arquitectura lógica antes de pasar a temas tecnológicos específicos.

• El objetivo es asegurar que los estudiantes comprendan bien tanto la arquitectura como la tecnología subyacente antes del final del módulo.

Arquitectura del Sistema de Gestión de Fondos

Capa de Presentación

• La capa de presentación incluye las interfaces web que permiten el acceso a los empleados desde cualquier ubicación y a los interventores a través de la red Sara.

• La comunicación entre la capa de presentación y la lógica de negocio se realiza mediante HTTPS, asegurando una conexión segura.

Capa de Lógica de Negocio

• Se divide en subsistemas lógicos, incluyendo el subsistema de gestión de fondos, que gestiona tanto los fondos comunitarios como los empleados asociados.

• El módulo para la gestión de usuarios permite el mantenimiento (alta, baja y modificación) con roles específicos para cada empleado.

Subsistemas Específicos

• El subsistema de gestión de operaciones maneja las operaciones financieras a través del módulo para carga y muestreo. Este último selecciona algoritmos para controlar las operaciones.

• Se enfatiza que al crear diagramas o descripciones funcionales, es crucial traducir correctamente el enunciado en un diagrama arquitectónico.

Estrategias para Exámenes

• Se recomienda tener versatilidad en la creación de diagramas y descripciones detalladas, incluso si no se solicita explícitamente un diagrama específico.

• La forma personal del presentador ha demostrado ser efectiva en exámenes previos, sugiriendo que su método puede ser útil para otros estudiantes.

Control y Servicios Funcionales

• El subsistema dedicado al control abarca funcionalidades como la creación y asignación del control por parte del interventor.

• Los servicios funcionales son transversales e interactúan con servicios externos; esto incluye un módulo específico para autenticación.

Autenticación y Seguridad

• El módulo se encarga de identificar y autorizar usuarios mediante diferentes métodos como certificados digitales o claves PIN.

• Aunque no se han preguntado aspectos sobre seguridad en exámenes anteriores, es importante incluir información relevante sobre autenticación según normativas vigentes.

Módulos de Autenticación y Firma Digital

Opciones de Autenticación

• Se discute el uso de identificadores europeos en la comunicación, donde se intercambian tokens para los interventores, permitiendo opciones de autenticación como clave con certificado digital.

• La elección del método de autenticación debe ser adecuada; por ejemplo, ofrecer un PIN a un interventor puede no ser práctico comparado con un certificado software.

Diseño y Toma de Decisiones

• El presentador enfatiza que está tomando decisiones de diseño basadas en el enunciado del problema que está resolviendo, lo cual es crucial para la claridad ante el tribunal.

• Se menciona que las notificaciones se enviarán por correo y SMS a través del módulo SIM, destacando la importancia de este módulo en la gestión.

Transparencia y Legislación

Leyes Relevantes

• Se introduce el concepto de RIS transparencia y su relación con la legislación europea y española sobre reutilización de información del sector público.

• La ley 37/2007 establece obligaciones para las administraciones públicas respecto a la publicación de datos abiertos.

Publicación y Acceso a Datos

• Las administraciones deben cumplir con la ley 19/2013 sobre transparencia, acceso a información pública y buen gobierno mediante módulos específicos.

• Se destaca que es necesario generar informes desde diferentes fuentes como CSV o Excel para cumplir con los requisitos legales.

Integración y Comunicación entre Subsistemas

Arquitectura Técnica

• Los subsistemas se comunicarán entre sí utilizando interfaces APIRES a través de HTTPS, asegurando una integración desacoplada.

• La redacción técnica debe ser impersonal; se recomienda evitar frases personales al describir sistemas o procesos.

Capa Lógica y Persistencia

• La capa lógica del negocio interactuará con una base de datos relacional mediante ORM (Object Relational Mapping), garantizando independencia tecnológica.

• Todos los datos gestionados serán almacenados en esta base relacional, incluyendo la gestión de usuarios.

Comunicación y Seguridad en Sistemas

Capas Transversales y Cumplimiento Normativo

• Se discute la importancia de las capas transversales en la arquitectura de sistemas, sin mencionar tecnologías específicas como Oracle o PostgreSQL.

• Se enfatiza el cumplimiento del Esquema Nacional de Seguridad (Real Decreto 311/2022) y la Ley Orgánica de Protección de Datos (LOPDGDD 3/2018), así como el RGPD.

Interoperabilidad y Normativas

• Se menciona el cumplimiento del esquema nacional de interoperabilidad NTIS, destacando su relevancia para la comunicación con otras administraciones y la Unión Europea.

• La evolución del programa Interoperable Europe se menciona, indicando su anterior denominación como ISA y ISA 2.

Monitorización y Gestión de Logs

• Se plantea el uso de herramientas para la búsqueda, gestión y visualización de logs, permitiendo monitorizar los niveles deseados de acuerdo al servicio.

Preguntas y Dudas sobre Servicios Web

• Durante una sesión interactiva, se plantean dudas sobre cómo enfrentar preguntas relacionadas con servicios web en un examen.

• Se discuten los tipos de servicios web: SOAP/WSDL frente a REST. La tendencia actual es hacia REST debido a su simplicidad.

Implementación Práctica

• Se aclara que muchos servicios comunes aún utilizan SOAP, lo que puede ser confuso para quienes piensan que está obsoleto.

• La implementación práctica implica conocer detalles técnicos como endpoints, parámetros requeridos en las llamadas y autenticación mediante certificados X509.

Correcciones y Sugerencias en Proyectos de Sistemas

Revisión de Proyectos

• Se mencionan correcciones específicas para los proyectos de Hana y Ana, destacando la necesidad de un apellido para el "empleado fondo" o "empleado de".

• Se aprueba el diseño del cuadradito, resaltando que debe ser descriptivo e incluir subsistemas como control, muestreo y servicios.

Estructura del Sistema

• Se discute la ubicación del módulo algoritmo dentro del subsistema de muestreo, sugiriendo una mejor organización.

• En las defensas se espera que los estudiantes expliquen interacciones entre módulos, no solo conceptos teóricos.

Detalles Técnicos

• Se menciona la falta de un servicio común (SV), sugiriendo incluir autenticación y firma dependiendo del método utilizado.

• La carga de datos implica subir ficheros a la base de datos; es importante anotar las dependencias entre paquetes.

Almacenamiento y Explotación de Datos

• El data warehouse se plantea como almacenamiento desde donde se puede explotar información mediante herramientas externas como Power BI.

• Se discute cómo el data warehouse podría ser utilizado por directivos o personal externo para consultas estadísticas.

Interfaz y Consulta

• Se sugiere crear un módulo para consulta estadística con una interfaz web dedicada.

• Dudas sobre quién tiene la responsabilidad en el sistema respecto al manejo del data warehouse; se enfatiza que los subsistemas pueden servir a múltiples interfaces.

Observaciones Finales

• Ana presenta su proyecto con varios subsistemas; hay confusión sobre si algunos son equivalentes.

• La integración continua es relevante para el desarrollo; se planea proporcionar plantillas en futuras clases.

¿Qué es la integración continua en el desarrollo de software?

Conceptos básicos de integración continua

• La integración continua se refiere a un proceso en el desarrollo de software donde se establecen tres entornos: desarrollo, preproducción y producción. Este enfoque permite una mejor gestión del ciclo de vida del software.

• Se discute que la integración continua es más relevante para los entornos de desarrollo y preproducción, aunque también puede aplicarse a producción. El enfoque actual es conceptual, no técnico.

• Se plantea la idea de un repositorio para la integración continua como una base de datos que almacena todos los cambios realizados en los programas, enfatizando su pertenencia al entorno de desarrollo.

Arquitectura y lógica del sistema

• La conversación gira en torno a cómo el repositorio de integración continua no pertenece a la capa de datos del sistema, sino que debe considerarse como un componente externo dentro del sistema general.

• Se mencionan herramientas específicas como GitLab, Maven y Jenkins que son utilizadas para gestionar el proceso de integración continua, pero se aclara que estas herramientas no forman parte directa del sistema principal.

Confusiones comunes sobre la integración continua

• Hay confusión entre diferentes fuentes sobre lo que implica la integración continua. Se destaca la importancia de entender correctamente estos conceptos para evitar contradicciones en el aprendizaje.

• La discusión resalta que aunque algunos pueden querer ser originales en sus enfoques, es crucial tener claridad sobre qué representa realmente la integración continua dentro del contexto del desarrollo ágil.

Gestión de proyectos y su relación con la tecnología

• Se menciona cómo integrar sistemas de gestión como Scrum con procesos automáticos de integración continua durante la gestión de proyectos. Esto será abordado más adelante en el módulo correspondiente.

• Aclaraciones sobre cómo el repositorio forma parte integral del flujo operativo dentro del proyecto sin estar directamente relacionado con las arquitecturas técnicas discutidas previamente.

Preparación para futuros temas

• Enfocándose en cómo gestionar proyectos eficientemente, se habla sobre las entregas y compilaciones necesarias utilizando herramientas adecuadas como Nexus para almacenar artefactos generados durante el proceso.

• Finalmente, se introduce el tema siguiente: microservicios. Se establece un marco conceptual previo necesario antes de profundizar en este nuevo tema relacionado con servicios web e integraciones.

¿Qué son los servicios web y cómo se implementan?

Introducción a los Servicios Web

• Los servicios web permiten la comunicación e interoperabilidad entre sistemas, existiendo principalmente dos tipos: SOAP (Simple Object Access Protocol) y REST (Representational State Transfer).

SOAP vs. REST

Características de SOAP

• SOAP es un protocolo de comunicación basado en XML que define mensajes en formato XML y utiliza estándares como WSDL para describir servicios web.

• Aunque puede utilizar diferentes protocolos de transporte, generalmente se implementa sobre HTTP, siendo más rígido y pesado en comparación con REST.

Características de REST

• REST se basa en principios como la identificación única de recursos y operaciones estándar de HTTP (GET, POST, PUT, DELETE), utilizando formatos ligeros como JSON o XML.

• A diferencia de SOAP, no requiere WSDL para su descripción y es más flexible al usar URLs normales con parámetros.

Ventajas y Desventajas

Comparación General

• La elección entre SOAP y REST depende del contexto del proyecto; aunque SOAP no está obsoleto, REST es más ligero y adecuado para arquitecturas web modernas.

• Mientras que REST es preferido por su ligereza, existen sistemas que aún utilizan SOAP debido a sus ventajas en entornos empresariales donde la seguridad avanzada es crítica.

Ventajas Específicas

• SOAP ofrece un modelo formal para transacciones con garantías de atomicidad, consistencia, aislamiento y durabilidad similar a las bases de datos.

• Aunque implementar SOAP puede ser laborioso debido a su especificidad técnica (como el uso del WSDL), permite desacoplar sistemas independientemente de la tecnología subyacente.

Estado Sin Estado en REST

• El principio "stateless" significa que cada solicitud contiene toda la información necesaria para procesarla sin mantener estado entre solicitudes.

• Esto implica que si una solicitud asíncrona necesita ser realizada posteriormente, debe incluir identificadores específicos ya que no hay capacidad para mantener sesiones.

Interacción Multiplataforma

• Las aplicaciones móviles pueden interactuar consistentemente con servicios web gracias a protocolos estándar como HTTP utilizados por REST.

¿Cómo se implementa una API REST en aplicaciones móviles?

Introducción a las APIs REST

• Cuando se desarrolla una aplicación móvil, se utiliza una API REST para la comunicación entre el sistema y la aplicación. Esta puede ser híbrida o nativa, escrita en diferentes lenguajes como React JS o Flutter.

Ventajas de las APIs REST

• Las APIs REST ofrecen mayor flexibilidad y escalabilidad en comparación con arquitecturas como SOAP. Los clientes móviles pueden acceder a recursos específicos mediante URIs y realizar operaciones estándar (GET, POST, PUT, DELETE).

• Promueven un desacoplamiento efectivo entre cliente y servidor, permitiendo que el desarrollo del frontend y backend se realice de manera independiente.

Comparación con SOAP

• A diferencia de SOAP, que utiliza XML y tiene más carga debido a su interpretación del lenguaje, las APIs REST utilizan peticiones HTTP simples que son más eficientes.

• Aunque SOAP también opera sobre HTTP, su complejidad es mayor debido a la necesidad de describir servicios web mediante WSDL.

Ejemplo práctico de uso de API

• Se presenta un ejemplo donde se describe cómo interactuar con un servicio web utilizando WSDL. Esto incluye detalles sobre los mensajes que puede recibir.

• En datos.gov.es se muestra cómo consultar datos mediante GET y cómo interpretar la respuesta en formato JSON.

Métodos de autenticación en APIs REST

• Existen diferentes mecanismos para autenticar usuarios en APIs REST; uno común es el uso de una API Key proporcionada al usuario tras registrarse.

• También es posible utilizar certificados X509 para autenticar clientes contra servicios web tanto en SOAP como en REST.

Comunicación entre componentes distribuidos

• La comunicación entre componentes distribuidos puede realizarse mediante SOAP o REST. Es fundamental asegurar conectividad adecuada para permitir estas interacciones.

¿Qué es GRPC y cómo se utiliza en microservicios?

Introducción a GRPC

• El GRPC es un protocolo de llamada a procedimientos remotos (RPC) utilizado en microservicios, permitiendo la comunicación entre componentes mediante HTTP.

Colas de Mensajes

• Las colas de mensajes permiten delegar la comunicación entre componentes, donde cada uno envía y recibe mensajes como eventos o notificaciones.

GraphQL y Middleware

• GraphQL permite a los clientes solicitar datos específicos, optimizando la transmisión de información. Los middleware, como el Enterprise Service Bus (ESB), facilitan la comunicación entre sistemas dentro de una organización.

¿Cómo se comunican las capas en una arquitectura empresarial?

Comunicación entre Capas

• La comunicación entre la capa de presentación y la lógica de negocio puede implementarse utilizando HTTPS, servicios web RESTful o SOAP para desacoplar estas capas.

Desacoplamiento con JDBC y ORM

• Para desacoplar la lógica de negocio de la base de datos, se utiliza JDBC en entornos Java. También se pueden emplear marcos ORM como Hibernate para mapear objetos a tablas en bases de datos.

Interacción entre subsistemas: ¿cómo funcionan las peticiones?

Estructura del Sistema

• Cada subsistema opera independientemente; las interfaces hacen peticiones específicas a cada uno según sea necesario, lo que permite una interacción asíncrona.

Diseño del Sistema

• La capa de presentación puede estar alojada en un servidor web Apache mientras que la lógica empresarial reside en otro entorno (como Tomcat), facilitando así el flujo de peticiones y respuestas.

¿Cómo se comunican los subsistemas en una arquitectura de software?

Comunicación entre subsistemas

• Se discute la posibilidad de tener dos redes diferentes, una interna y otra externa, donde cada red puede hacer peticiones a distintos subsistemas.

• Se presenta la aplicación Cecan, que permite filtrar conjuntos de datos como demografía a través de su interfaz web.

• La interfaz web realiza una llamada a la lógica de negocio para obtener catálogos de datos específicos mediante una petición HTTP en formato JSON.

• Todos los subsistemas ofrecen comunicación a través de API Rest, permitiendo diversas funciones y consultas entre ellos.

• La lógica agrupada visualmente no implica que todos los submódulos estén interconectados; cada uno opera independientemente.

Estructura del proyecto y ejecución

• Se explica cómo el código del proyecto está organizado en componentes Java que se ejecutan en la máquina virtual Java (JVM).

• Los componentes están esperando solicitudes en un servidor Tomcat configurado para escuchar en puertos específicos (ej. 80 o 90).

• Los subsistemas activos ofrecen sus APIs Rest disponibles para consultas mediante métodos HTTP como GET, PUT y DELETE.

• La interfaz web no reside en el mismo servidor que la lógica de negocio; está ubicada en un entorno accesible por internet (DMZ).

• El uso del protocolo HTTP es ventajoso ya que atraviesa firewalls y es ampliamente utilizado para interfaces web.

Conceptos relacionados con microservicios

• Se aclara que el enfoque discutido no es sobre microservicios per se, sino sobre comunicación entre módulos distribuidos.

• Se menciona la confusión común entre conceptos como microservicios y comunicación entre componentes distribuidos.

• La discusión avanza hacia clasificar conceptos relacionados con microservicios como consecuencia de las arquitecturas previas mencionadas.

• Se enfatiza la importancia de entender primero REST y servicios web antes de abordar microservicios debido a su complejidad inherente.

• La arquitectura basada en microservicios se define como un diseño estructural más que tecnológico, diferenciándose así de aplicaciones monolíticas.

Arquitectura de Microservicios y Monolitos

Introducción a la Aplicación Monolítica

• Se define una aplicación monolítica como aquella que está estructurada en tres capas. El examen puede incluir preguntas sobre microservicios, lo que requiere un entendimiento de ambas arquitecturas.

Ventajas de los Microservicios

• Los microservicios son considerados el futuro debido a las ventajas que ofrecen, lo cual es importante para entender su creciente adopción por diversas organizaciones.

Definición y Características de los Microservicios

• Un microservicio se caracteriza por ser un servicio independiente que realiza una función específica y se comunica con otros servicios mediante interfaces bien definidas.

• La especialización es clave en la filosofía de microservicios; cada uno debe ser altamente especializado para cumplir su función.

Desafíos en el Acceso a Datos

• Uno de los principales problemas es el acceso concurrente a datos entre microservicios, ya que cada uno puede tener su propia base de datos.

• Si cada microservicio tiene su propia base de datos, surge la necesidad de coordinar cómo acceder a los datos compartidos entre ellos.

Opciones para Implementar Bases de Datos en Microservicios

• Se pueden utilizar bases de datos compartidas o monolíticas donde todos los microservicios acceden a una única base de datos.

• Cada microservicio puede tener su propio servidor dedicado o compartir tablas dentro de una misma base de datos, dependiendo del contexto y necesidades del sistema.

Transacciones y Propiedades AIT

• Las transacciones deben cumplir con las propiedades AIT (Atomicidad, Integridad y Durabilidad), lo cual se complica cuando no están todas las operaciones en la misma base de datos.

• Una base de datos compartida simplifica las lecturas y escrituras al evitar transacciones distribuidas complicadas.

Coreografía vs Orquestación en Microservicios

• En sistemas con bases de datos compartidas, la coreografía implica que cada servicio sabe cómo comunicarse con otros sin necesidad de un controlador central.

Orquestación y Microservicios

Concepto de Orquestación

• La orquestación se compara con un director de orquesta que coordina las transacciones, asegurando que terminen en el orden correcto.

• Se utilizan buses de eventos como Kafka o Rabbit MQ para gestionar la comunicación entre microservicios, permitiendo que los eventos fluyan adecuadamente.

Desacoplamiento y APIs

• Los subsistemas pueden ofrecer una API REST, lo cual es una decisión de diseño que permite mantener el desacoplamiento.

• La lógica de negocio puede estar distribuida en componentes independientes, aunque todos forman parte del mismo sistema.

Relación con Contenedores

• Se introduce el concepto de contenedores (Docker) y su orquestación (Kubernetes), lo cual permite un mayor desacoplamiento entre subsistemas.

• A medida que se avanza en la comprensión del sistema moderno, se enfatiza la importancia de crear interfaces para facilitar la comunicación entre componentes.

Comunicación entre Microservicios

• Los microservicios deben manejar solicitudes tanto de clientes externos como de otros microservicios, utilizando protocolos adecuados para su comunicación.

• Se descarta SOAP debido a su complejidad; se prefiere REST por ser más ligero y rápido.

Tipos de Comunicación

• La comunicación puede ser síncrona (esperando respuesta inmediata) o asíncrona (sin esperar respuesta).

• REST es comúnmente utilizado para sistemas pequeños o medianos; GRPC puede ser considerado para sistemas más grandes debido a su velocidad.

Diseño de Microservicios y Comunicación

Uso de Plantillas en Microservicios

• Se sugiere utilizar plantillas para el diseño de microservicios, evitando complicaciones innecesarias. La defensa del diseño se puede preparar más adelante.

Patrones de Mensajería

• La comunicación entre microservicios se realiza mediante mensajes a través de canales como RabbitMQ o Apache Kafka. Se enfatiza la importancia de elegir un patrón adecuado.

Opciones de Comunicación

• Las opciones para la comunicación incluyen REST para comunicación síncrona y buses de mensajería como RabbitMQ para comunicación asíncrona. Es crucial seleccionar una opción adecuada según las necesidades del sistema.

Desacoplamiento y Despliegue

• El desacoplamiento permite una gran libertad en el despliegue, pudiendo optar por servicios en diferentes entornos, como AWS o servidores locales.

Estrategias de Despliegue

• Se pueden desplegar múltiples instancias del mismo servicio en un solo host o cada microservicio en máquinas virtuales independientes, lo que plantea ventajas y desventajas en términos de recursos.

Contenedores y Eficiencia

Introducción al Concepto de Contenedor

• Los contenedores surgen como solución a la necesidad de evitar levantar sistemas operativos completos para ejecutar aplicaciones, optimizando así los recursos utilizados.

Ventajas del Uso de Contenedores

• Un contenedor empaqueta código, bibliotecas y dependencias necesarias para ejecutar una aplicación sin preocuparse por el sistema operativo subyacente. Esto simplifica la gestión y despliegue.

Aplicaciones Legacy en Contenedores

• Los contenedores permiten contenerizar aplicaciones existentes (Legacy), facilitando su modernización sin necesidad de reescribirlas completamente.

Abstracción Completa con Contenedores

• Al usar contenedores, se abstrae toda la complejidad relacionada con el sistema operativo y sus configuraciones, permitiendo un enfoque más limpio hacia el desarrollo y despliegue.

Contenedores y Microservicios: Una Relación Sinérgica

Ventajas de los Contenedores en Microservicios

• Los contenedores son ideales para implementar aplicaciones de microservicios, permitiendo que cada servicio se ejecute en su propio contenedor aislado, lo que facilita la gestión y el mantenimiento.

• La escalabilidad es una ventaja clave; se pueden escalar microservicios específicos según la demanda sin afectar a otros, optimizando así el uso de recursos.

• En entornos de nube como Azure, AWS o Google Cloud, la infraestructura es gestionada por el proveedor, permitiendo a los usuarios programar recursos según horarios específicos.

• Se busca optimizar la infraestructura evitando servidores infrautilizados; los contenedores pueden levantarse solo cuando son necesarios.

Comparativa entre Contenedores y Máquinas Virtuales

• Docker es uno de los sistemas más utilizados para gestionar contenedores. A diferencia de las máquinas virtuales que requieren un sistema operativo completo por cada instancia, los contenedores comparten el mismo sistema operativo subyacente.

• Utilizar contenedores resulta más económico y administrable en comparación con tener múltiples máquinas virtuales con sus respectivos hipervisores.

Arquitectura y Despliegue

• La arquitectura basada en microservicios permite independizar funcionalidades, facilitando su despliegue y administración. Aunque hay similitudes gráficas con arquitecturas tradicionales, las diferencias operativas son significativas.

• La gestión efectiva de microservicios requiere herramientas adecuadas para orquestar estos servicios dentro de un entorno containerizado.

Gestión de Contenedores con Kubernetes

• Kubernetes es una plataforma central para la orquestación de contenedores que permite gestionar aplicaciones complejas mediante un diseño estructurado.

• Las funciones principales incluyen facilitar despliegues automáticos, escalabilidad automática y recuperación ante errores. Esto asegura un flujo eficiente entre diferentes microservicios.

Características Clave de Kubernetes

• Kubernetes proporciona características esenciales como balanceo de cargas y descubrimiento automático de servicios al gestionar múltiples instancias de microservicios.

• Permite controlar recursos asignados a cada contenedor (como CPU), asegurando que se utilicen eficientemente según las necesidades del servicio durante diferentes períodos del día.

• Es una plataforma open-source heredada de Google que simplifica el despliegue y gestión continua de aplicaciones en contenedores.

¿Cómo funcionan los microservicios y Kubernetes?

Introducción a la arquitectura de microservicios

• La filosofía de microservicios implica que cada componente opera de forma aislada, permitiendo que cada uno tenga su propia potencialidad. Se enfatiza el uso de APIs y bases de datos separadas para una mejor gestión.

Arquitectura física vs. lógica

• En la arquitectura lógica se discuten las configuraciones, mientras que en la física se decide si utilizar un solo servidor o implementar un clúster con Kubernetes y contenedores Docker.

Gestión de aplicaciones en contenedores

• La administración moderna permite gestionar contenedores con supervisión, depuración y recuperación ante fallos, facilitando el manejo automatizado sin necesidad de expertos en sistemas operativos.

Estructura del clúster en Kubernetes

• Un clúster de Kubernetes debe tener al menos dos nodos: un nodo maestro (controlador) y uno o más nodos trabajadores (worker nodes), donde se ejecutan las aplicaciones en contenedores.

Concepto de Pods en Kubernetes

• Un Pod es la unidad más pequeña dentro de Kubernetes, compuesta por uno o más contenedores que se implementan en un solo nodo. Es fundamental entender esta estructura para manejar correctamente los despliegues.

Conclusiones sobre Docker y microservicios

• Se destaca la importancia del uso de Docker para crear imágenes que pueden ser desplegadas fácilmente en plataformas como Google Cloud. Además, se menciona que no es necesario usar Kubernetes junto con Docker.

Reflexiones finales sobre el aprendizaje

• Se hace hincapié en separar conceptos clave como microservicios, contenedores y orquestación para facilitar el entendimiento pedagógico entre los estudiantes.

¿Cómo se relacionan los microservicios con las bases de datos?

Conceptos sobre Microservicios y APIs

• Se discute la importancia de que todos los sistemas tengan su propia API, comparando esto con contenedores marítimos que cumplen normas ISO para facilitar su manejo.

• Se menciona que el mundo de los microservicios es vasto e infinito, planteando la pregunta sobre si los microservicios que se conectan a bases de datos son llamados "data service" o si es un término inventado por una empresa específica.

Servicios de Datos

• Se aclara que el concepto de "data service" no es exclusivo de una empresa; existen servicios de datos y también "data as a service".

• La idea presentada es utilizar un servicio de datos como capa entre la base de datos y los microservicios, lo cual permite canalizar toda la información hacia la base de datos a través del microservicio.

Diseño y Arquitectura en Microservicios

• Se enfatiza que no hay una única forma correcta para implementar microservicios; cada diseño puede ser adaptado según las necesidades específicas del proyecto.

• El objetivo es enseñar soluciones prácticas y mínimas en lugar de buscar perfección, permitiendo así flexibilidad en el diseño arquitectónico.

Próximos Pasos

• Se anuncia que en la próxima sesión se abordarán temas relacionados con interfaces API y web, incluyendo sus ventajas e inconvenientes. También se planea ilustrar un ejemplo utilizando microservicios.