Parte 2 - Tema 1 Flashcards
Arquitectura software
1
Q
Arquitectura software
A
La arquitectura de un sistema software constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado dicho sistema y de cómo trabajan juntos sus componentes. Es la representación de dicho software que permite:
* Analizar la efectividad del diseño para la consecución de los requisitos fijados.
* Considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil.
* Reducir los riesgos asociados a la construcción del software
2
Q
Principios
A
Hay 12 principios que están relacionados a la escalabilidad, disponibilidad y costo
3
Q
Principio 1: N+1 Design
A
Para garantizar la disponibilidad de tu software, ten al menos una instancia adicional en tu esquema de despliegue.
4
Q
Principio 2: Design for rollback
A
Para garantizar también la disponibilidad, asegúrate que todo cambio en tu software sea fácilmente revertible.
5
Q
Principio 3: Design to Be Disabled
A
Cuando dependes de un sistema, y este no se encuentre disponible, establece un mecanismo que garantice un normal funcionamiento.
6
Q
Principio 4: Design to Be Monitored
A
Además de monitorear cuándo el sistema no está funcionando correctamente, debes obtener indicadores que permita identificar cuándo se está desempeñando de manera diferente a lo normal.
7
Q
Principio 5: Design for Multiple Live Sites
A
8
Q
Principio 6: Use Mature Technologies
A
Usar una tecnología emergente se consciente que al hallar errores, la comunidad a consultar será muy pequeña. Si quieres evitar eso trata de usar tecnologías ya probadas y con una gran comunidad.
9
Q
Principio 7: Asynchronous Design
A
Siempre que sea posible, los sistemas deben comunicarse de forma asincrónica, ya que son más tolerantes a fallas y no caen fácilmente a cargas extremas
10
Q
Principio 8: Stateless Systems
A
Trate de evitar el estado siempre que sea posible, ya que almacenarlo requiere memoria lo que aumenta el costo de su sistema.
11
Q
Principio 9: Scale Out Not Up
A
Escale horizontalmente en lugar de verticalmente, si el adquirir un hardware más rápido, más grande y más caro, no sea indispensable para el crecimiento de su negocio.
12
Q
Principio 10: Design for at Least Two Axes of Scale
A
Se consideran el escalamiento en ejes, lo que se conoce como el cubo de la escalabilidad, eje x (clonación y replicación), eje y (divide componentes diferentes) y eje z (divide componentes no diferentes)
13
Q
Principio 11: Buy when non core
A
Independientemente de lo inteligente que sea su equipo, simplemente no son los mejores en todo. Construya cosas cuando sea realmente bueno en eso y haga una diferencia significativa en su producto, plataforma o sistema. Y compre cuando no sea el caso.
14
Q
Principio 12: Use Commodity Hardware
A
No diseñes una solución que dependa de un hardware específico.
15
Q
Arquitectura Monolítica
A
Consiste en crear una aplicación autosuficiente que contenga absolutamente toda la funcionalidad necesaria para realizar la tarea para la cual fue diseñada, sin contar con dependencias externas que complementen su funcionalidad.
16
Q
Arquitectura Monolítica Ventajas
A
- Fácil de desarrollar
- Fácil de escalar
- Pocos puntos de fallo
- Autónomo
- Rendimiento
- Fácil de probar
17
Q
Arquitectura Monolítica Desventajas
A
- Anclado a un Stack tecnológico
- Escalado Monolítico
- El tamaño sí importa
- Versión tras versión
- Si falla, falla todo
- Es fácil perder el rumbo
- Puede ser abrumador
18
Q
Arquitectura Cliente/Servidor
A
El componente servidor proporcionará servicios a múltiples componentes cliente. Los clientes solicitan servicios al servidor y éste proporciona los servicios pertinentes a dichos clientes. Además, el servidor sigue escuchando las peticiones de los clientes.
19
Q
Arquitectura Cliente/Servidor Ventajas
A
- Administración centrada en el servidor.
- Centralización de los recursos.
- Mejora de la seguridad.
- Escalabilidad de la instalación.
20
Q
Arquitectura Cliente/Servidor Desventajas
A
- Coste elevado.
- Dependencia del servidor.
21
Q
Arquitectura en capas
A
Cuya base es la separación de las diferentes funcionalidades del sistema en capas o niveles, donde cada capa se encarga de un conjunto de tareas específicas y se comunica con los niveles adyacentes mediante interfaces bien definidas.
22
Q
Arquitectura en capas Ventajas
A
- Modularidad
- Separación de responsabilidades
- Reutilización
- Escalabilidad
- Flexibilidad
23
Q
Arquitectura en capas Desventajas
A
- Complejidad
- Tiempo y esfuerzo de desarrollo
- Consumo de recursos
- Costos
- Rendimiento
24
Q
Arquitectura peer to peer
A
Es una red de computadoras donde todos los dispositivos conectados a la red actúan como cliente y servidor al mismo tiempo. En esta arquitectura no es necesario un servidor central que administre la red (aunque puede existir), si no que todos los nodos de la red pueden comunicarse entre sí.
25
Arquitectura peer to peer Ventajas
Alta escalabilidad
Tolerancia a fallas
Descentralización
Privacidad
Equilibrio de carga
26
Arquitectura peer to peer Desventajas
* Alta complejidad
* Control
* Seguridad
* Tráfico
27
Arquitectura orientada a los servicios (SOA)
SOA es una arquitectura de software que estructura una aplicación como una colección de servicios interoperables que se comunican entre sí a través de una red. Cada servicio realiza una función empresarial específica y se publica, descubre y se invoca a través de una red.
28
Cuáles son los principales componentes de una SOA
Los componentes clave incluyen: servicios, contratos de servicio, registro de servicios, ESB (Enterprise Service Bus), y consumidores de servicios.
28
¿Cuál es la diferencia entre un servicio web y un servicio SOA?
Aunque todos los servicios web son servicios, no todos los servicios son servicios web. SOA es un enfoque más amplio que incluye servicios web, pero también puede utilizar otros protocolos y estándares. Los servicios SOA se centran más en los negocios y en la interoperabilidad a largo plazo.
29
¿Cuáles son las ventajas de SOA?
Reutilización de servicios, mayor flexibilidad, escalabilidad, agilidad, y alineación con los objetivos del negocio.
30
¿Cuáles son los desafíos de SOA?
Complejidad de implementación, costos de desarrollo iniciales, gestión de la gobernanza de servicios, y dependencia de una infraestructura sólida.
31
¿Qué es un ESB?
Un ESB es un software que actúa como intermediario entre los diferentes servicios de una SOA, facilitando la comunicación y la transformación de datos.
32
¿Cómo se asegura la seguridad en una SOA?
A través de mecanismos como la autenticación, la autorización, el cifrado de datos, y la gestión de identidades.
33
¿Cuál es la diferencia entre SOA y microservicios?
Ambos son enfoques arquitectónicos basados en servicios, pero los microservicios son más granulares y se despliegan de forma independiente. SOA suele tener un enfoque más centralizado.
34
Desventajas de la Arquitectura Orientada a Servicios (SOA)
* Complejidad
* Costo
* Riesgo
* Tiempo de implementación
* Curva de aprendizaje
35
¿Qué es un microservicio?
Un microservicio es una pequeña aplicación independiente que realiza una única función bien definida dentro de un sistema más grande.
36
¿Por qué utilizar microservicios?
Mayor escalabilidad, flexibilidad, facilidad de desarrollo, despliegue independiente y tecnologías heterogéneas.
37
¿Cómo se diseñan los microservicios?
Se diseñan en torno a dominios de negocio específicos y se comunican a través de APIs bien definidas.
38
¿Qué tecnologías se utilizan comúnmente para desarrollar microservicios?
Docker, Kubernetes, contenedores, API Gateway, lenguajes como Java, Node.js, Go y frameworks como Spring Boot.
39
¿Qué es un API Gateway?
Un API Gateway actúa como punto de entrada único para los clientes, enrutando las solicitudes a los microservicios correspondientes.
40
¿Cuáles son las ventajas de los microservicios sobre SOA?
Mayor escalabilidad, flexibilidad, tecnología heterogénea, despliegue independiente.
41
¿Cuáles son las desventajas de los microservicios?
Mayor complejidad operativa, gestión de múltiples servicios, necesidad de herramientas especializadas.
42
¿Cuándo es adecuado utilizar microservicios?
Para sistemas grandes y complejos que requieren alta escalabilidad y flexibilidad.
43
¿Cuáles son las tendencias actuales en microservicios?
Serverless, funciones como servicio, edge computing
44
¿Qué es un sistema en tiempo real?
Un sistema en tiempo real es aquel cuya corrección depende no solo de la lógica de los resultados computacionales, sino también de los momentos en los que se producen dichos resultados.
45
¿Cuáles son las características clave de un sistema en tiempo real?
Respuesta rápida, determinismo, fiabilidad, seguridad, capacidad de respuesta a eventos externos.
46
¿Qué requisitos especiales tienen los sistemas en tiempo real?
Tiempo de respuesta predecible, baja latencia, alta disponibilidad, tolerancia a fallos.
47
¿Cuáles son los componentes principales de un sistema en tiempo real?
Hardware (procesadores, sensores, actuadores), sistema operativo en tiempo real (RTOS), software de aplicación.
48
¿Qué factores se deben considerar al diseñar un sistema en tiempo real?
Predictibilidad, modularidad, escalabilidad, seguridad.
49
¿Cuáles son algunos ejemplos de sistemas en tiempo real?
Sistemas de control industrial, sistemas de aviónica, sistemas médicos, robots.
50
¿Qué es un sistema transaccional?
Un sistema transaccional es un sistema de información que recopila, almacena, modifica y recupera información relacionada con las transacciones de una organización. Estas transacciones pueden ser desde ventas y compras hasta actualizaciones de registros.
51
¿Qué es una transacción?
Una transacción es una unidad de trabajo atómica, es decir, una serie de operaciones que se ejecutan como un todo. Si una transacción falla, todas las operaciones se deshacen, garantizando la integridad de los datos.
52
¿Cuáles son las propiedades ACID de las transacciones?
Las propiedades ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) garantizan la integridad y la fiabilidad de las transacciones en un sistema de base de datos.
53
¿Cuáles son los componentes principales de un sistema transaccional?
Base de datos transaccional, interfaz de usuario, lógica de negocio, middleware.
54
¿Cuál es la importancia del middleware en un sistema transaccional?
El middleware facilita la comunicación entre diferentes componentes del sistema, gestiona las transacciones y proporciona servicios adicionales como seguridad y monitoreo.
55
¿Cuáles son algunos ejemplos de sistemas transaccionales?
Sistemas de punto de venta, sistemas bancarios, sistemas de reservas, sistemas de gestión de inventario.
56
¿Cuál es la principal ventaja de un sistema transaccional?
Garantizan la integridad y consistencia de los datos, evitando pérdidas o duplicidades. Son esenciales para operaciones críticas donde la precisión es fundamental.
57
¿Cómo mejora un sistema transaccional la eficiencia de una organización?
Respuesta: Automatiza procesos, reduce errores manuales y agiliza las transacciones, lo que se traduce en una mayor productividad.
58
¿Qué papel juegan los sistemas transaccionales en la toma de decisiones?
Proporcionan datos precisos y actualizados para la toma de decisiones informadas y basadas en hechos.
59
¿Cómo contribuyen los sistemas transaccionales a la seguridad de los datos?
Implementan mecanismos de control de acceso, cifrado y copias de seguridad para proteger la información confidencial.
60
¿Cuál es la principal desventaja de un sistema transaccional?
Pueden ser rígidos y difíciles de modificar, lo que los hace menos flexibles ante cambios rápidos en los requisitos del negocio.
61
¿Cómo afecta la complejidad de un sistema transaccional a su mantenimiento?
Sistemas complejos pueden ser difíciles de mantener y actualizar, requiriendo personal altamente especializado.
62
¿Qué problemas de rendimiento pueden surgir en sistemas transaccionales de gran tamaño?
Pueden experimentar cuellos de botella y lentitud en el procesamiento de transacciones, especialmente bajo cargas altas.
63
¿Cómo afecta la dependencia de una base de datos a un sistema transaccional?
Una falla en la base de datos puede causar la pérdida de datos y paralizar el sistema completo.
64
¿Qué es una arquitectura de objetos distribuidos?
Una arquitectura de objetos distribuidos es un modelo de software donde los objetos, que encapsulan tanto datos como comportamiento, se distribuyen en múltiples computadoras conectadas en red.
65
¿Cuál es la diferencia entre un objeto y un proceso en una arquitectura distribuida?
Un objeto representa una entidad del mundo real con propiedades y métodos, mientras que un proceso es la unidad de ejecución en un sistema operativo.
66
¿Cuáles son los principales objetivos de una arquitectura de objetos distribuidos?
Reutilización de código, modularidad, escalabilidad, transparencia de la distribución.
67
¿Cuáles son los componentes clave de una arquitectura de objetos distribuidos?
Objetos distribuidos, middleware, registro de objetos, sistema de nombres.
68
¿Qué es el middleware en una arquitectura de objetos distribuidos?
El middleware proporciona servicios de comunicación, gestión de transacciones y seguridad entre objetos distribuidos.
69
¿Qué es un registro de objetos?
Un registro de objetos es una base de datos que almacena información sobre los objetos disponibles en el sistema.
70
¿Cuáles son los principales desafíos en el diseño de arquitecturas de objetos distribuidos?
Transparencia de la distribución, concurrencia, gestión de estados, seguridad.
71
¿Cómo se garantiza la consistencia de los datos en un sistema distribuido de objetos?
A través de mecanismos de bloqueo, transacciones distribuidas y replicación de datos.
72
¿Qué papel juega la seguridad en una arquitectura de objetos distribuidos?
La seguridad es fundamental para proteger los objetos y la comunicación entre ellos. Se utilizan mecanismos como la autenticación, la autorización y el cifrado
73
¿Cuáles son algunos ejemplos de sistemas que utilizan arquitecturas de objetos distribuidos?
Sistemas de comercio electrónico, sistemas de colaboración en línea, aplicaciones de realidad virtual.
74
¿Cuáles son las principales ventajas de las arquitecturas de objetos distribuidos?
Reutilización de código, modularidad, escalabilidad, flexibilidad.
75
¿Cuáles son las principales desventajas de las arquitecturas de objetos distribuidos?
Complejidad, gestión de estados, rendimiento, seguridad
76
¿Qué es CORBA?
CORBA es un estándar de la industria para desarrollar y ejecutar aplicaciones distribuidas basadas en objetos. Define una arquitectura de middleware que permite a objetos en diferentes plataformas comunicarse entre sí.
77
¿Cuáles son las principales características de CORBA?
* Interoperabilidad: Permite que objetos escritos en diferentes lenguajes y ejecutando en diferentes plataformas se comuniquen.
* Independencia de la plataforma: Las aplicaciones CORBA pueden ejecutarse en cualquier plataforma que implemente la especificación CORBA.
* Abstracción de la distribución: Oculta la complejidad de la comunicación distribuida a los desarrolladores.
78
¿Cuáles son los componentes clave de CORBA?
* ORB (Object Request Broker): El núcleo de CORBA, que enruta las solicitudes de los clientes a los objetos correspondientes.
* IDL (Interface Definition Language): Un lenguaje para definir las interfaces de los objetos.
* IIOP (Internet Inter-ORB Protocol): El protocolo de comunicación estándar para CORBA.
79
¿Cuáles son las ventajas de CORBA?
Alta interoperabilidad, madurez, gran comunidad de desarrolladores.
80
¿Cuáles son las desventajas de CORBA?
Complejidad, sobrecarga, puede ser pesado para aplicaciones simples.
81
¿Qué es DCOM?
DCOM es una tecnología propietaria de Microsoft que extiende el modelo de objetos componentes (COM) a entornos distribuidos.
82
¿Cuáles son las principales características de DCOM?
* Integración con el sistema operativo Windows: DCOM está estrechamente integrado con el sistema operativo Windows.
* Facilidad de uso: DCOM es relativamente fácil de usar para los desarrolladores de Microsoft.
83
¿Cuáles son las ventajas de DCOM
Fácil integración con otras tecnologías de Microsoft, rendimiento.
84
¿Cuáles son las desventajas de DCOM?
Propietario, menos interoperable que CORBA, más ligado a la plataforma Windows.
85
¿Qué es una arquitectura Event-Driven?
Una arquitectura Event-Driven (EDA) es un paradigma de diseño de software donde los eventos desencadenan y coordinan la comunicación entre servicios desacoplados. Un evento es un cambio de estado o una actualización, como un pedido realizado o un pago completado.
86
¿Cuáles son los componentes principales de una arquitectura Event-Driven?
Productores de eventos, consumidores de eventos, canal de eventos (bus de eventos) y el propio evento.
87
¿Cuál es la diferencia entre una arquitectura Event-Driven y una arquitectura orientada a servicios (SOA)?
Mientras que SOA se centra en la exposición de servicios a través de interfaces bien definidas, EDA se enfoca en la detección y reacción a eventos. EDA puede complementar a SOA, ya que los servicios pueden ser activados por eventos entrantes.
88
¿Cuáles son las principales ventajas de una arquitectura Event-Driven?
Alta escalabilidad, desacoplamiento de componentes, procesamiento en tiempo real, mayor resiliencia a fallos.
89
¿Cuáles son las principales desventajas de una arquitectura Event-Driven?
Complejidad en la gestión de eventos, dificultad en la depuración, necesidad de herramientas especializadas.
90
¿Cómo se garantiza la consistencia de los datos en una arquitectura Event-Driven?
A través de mecanismos de confirmación de eventos, sagas y eventual consistency.
91
¿Qué papel juega la seguridad en una arquitectura Event-Driven?
La seguridad es crucial para proteger los eventos y garantizar la integridad de los datos. Se utilizan mecanismos de autenticación, autorización y cifrado.
92
¿Cómo se gestionan los eventos duplicados o fuera de orden?
Mediante el uso de identificadores únicos de eventos, índices y mecanismos de reintentos.
93
¿Cuáles son algunos ejemplos de sistemas que utilizan arquitectura Event-Driven?
Sistemas de recomendación, plataformas de comercio electrónico, sistemas de IoT.
94
¿Qué es la Arquitectura Hexagonal?
La Arquitectura Hexagonal, también conocida como Arquitectura de Puertos y Adaptadores, es un patrón de diseño de software que busca aislar la lógica de negocio del núcleo de una aplicación de las tecnologías externas con las que interactúa, como bases de datos, interfaces de usuario, etc.
95
¿Cuáles son los componentes principales de una Arquitectura Hexagonal?
* Núcleo: Contiene la lógica de negocio central de la aplicación.
* Puertos: Son los puntos de entrada y salida de la aplicación, definidos como interfaces abstractas.
* Adaptadores: Implementan los puertos y se conectan a las tecnologías externas (bases de datos, frameworks, etc.).
96
¿Cuáles son las principales ventajas de utilizar Arquitectura Hexagonal?
* Desacople: Separa la lógica de negocio de las tecnologías externas, facilitando los cambios y las pruebas.
* Testabilidad: Permite realizar pruebas unitarias de la lógica de negocio de forma aislada.
* Flexibilidad: Facilita la sustitución de tecnologías y frameworks.
* Reutilización: El núcleo de la aplicación puede ser reutilizado en diferentes contextos.
97
¿Cuáles son los desafíos al implementar la Arquitectura Hexagonal?
* Curva de aprendizaje: Puede requerir un cambio en la forma de pensar y diseñar aplicaciones.
* Complejidad inicial: La configuración inicial puede ser más compleja que en otros patrones.
98
¿Cuál es la diferencia entre la Arquitectura Hexagonal y la Arquitectura en Capas?
La Arquitectura Hexagonal se centra en desacoplar la lógica de negocio de las tecnologías externas, mientras que la Arquitectura en Capas se enfoca en organizar el código en capas bien definidas.
99
¿Cuándo es recomendable utilizar la Arquitectura Hexagonal?
Es ideal para aplicaciones con requisitos cambiantes, donde la tecnología subyacente puede evolucionar rápidamente.
100
¿Cuál es el papel de los tests en la Arquitectura Hexagonal?
Los tests son fundamentales para garantizar la calidad y la corrección de la lógica de negocio.
101
¿En qué tipo de aplicaciones es más común utilizar la Arquitectura Hexagonal?
Es muy utilizada en aplicaciones empresariales, microservicios y aplicaciones con requisitos de alta testabilidad.
102
¿Qué es Arquitectura CQRS (Command Query Responsibility Segregation)?
CQRS es un patrón arquitectónico que separa las responsabilidades de lectura (consultas) y escritura (comandos) en un sistema. En lugar de utilizar un modelo único para ambas operaciones, CQRS introduce dos modelos separados: uno para actualizaciones y otro para lecturas.
103
¿Cuál es la diferencia entre un comando y una consulta en CQRS?
Un comando modifica el estado del sistema (crear, actualizar, eliminar), mientras que una consulta solo devuelve información sin modificar el estado.
104
¿Cuáles son las principales ventajas de utilizar CQRS?
* Escalabilidad: Permite optimizar de manera independiente los modelos de lectura y escritura.
* Flexibilidad: Facilita la implementación de diferentes estrategias de almacenamiento y indexación para cada modelo.
* Performance: Al separar las responsabilidades, se puede mejorar el rendimiento de las operaciones de lectura y escritura.
* Seguridad: Permite aplicar políticas de seguridad más granulares a las operaciones de lectura y escritura.
105
¿Cuáles son los desafíos al implementar CQRS?
* Complejidad: Introducir dos modelos separados puede aumentar la complejidad del sistema.
* Consistencia eventual: En algunos casos, los datos pueden no ser consistentes de forma inmediata entre los dos modelos.
* Desarrollo: Requiere un cambio de mentalidad en el desarrollo de aplicaciones.
106
¿Cuándo es recomendable utilizar CQRS?
* Sistemas con altas cargas de lectura y escritura.
* Sistemas con requisitos de escalabilidad y performance muy exigentes.
* Sistemas con modelos de datos complejos y evolutivos.
107
¿Qué herramientas y tecnologías son útiles para implementar CQRS?
Frameworks de mensajería (Kafka, RabbitMQ), bases de datos NoSQL, etc.
108
¿Qué es una arquitectura de n niveles?
Es un modelo de diseño de software que divide una aplicación en múltiples capas lógicas, cada una con una responsabilidad específica. Esto permite una mejor organización, mantenimiento y escalabilidad.
109
¿Cuáles son las capas típicas en una arquitectura de n niveles?
Las capas más comunes son: presentación, lógica de negocio y acceso a datos. Sin embargo, pueden existir más capas dependiendo de la complejidad de la aplicación.
110
¿Cuál es el propósito de cada capa?
* Presentación: Interactúa con el usuario, mostrando la interfaz gráfica y capturando los datos de entrada.
* Lógica de negocio: Contiene la lógica principal de la aplicación, implementando las reglas de negocio y los procesos.
* Acceso a datos: Se encarga de la interacción con la base de datos, realizando operaciones de lectura, escritura y actualización.
111
¿Cuáles son las principales ventajas de una arquitectura de n niveles?
* Reusabilidad: Las capas pueden ser reutilizadas en diferentes proyectos.
* Mantenibilidad: Los cambios en una capa afectan menos a las demás.
* Escalabilidad: Permite escalar cada capa de forma independiente.
* Abstracción: Oculta la complejidad de las capas inferiores.
112
¿Cuáles son las principales desventajas de una arquitectura de n niveles?
* Mayor complejidad: Requiere un diseño más cuidadoso y puede aumentar el tiempo de desarrollo.
* Mayor sobrecarga: Las llamadas entre capas pueden generar un overhead adicional.
