ARQUITECTURA DE SOFTWARE

 Arquitectura SOA (arquitectura orientada a servicios)

• La arquitectura orientada a los servicios (SOA) es un tipo de diseño de software que

permite reutilizar sus elementos gracias a las interfaces de servicios que se

comunican a través de una red con un lenguaje común.

• Un servicio es una unidad autónoma de una o más funciones del software diseñada

para realizar una tarea específica, como recuperar cierta información o ejecutar una

operación. Contiene las integraciones de datos y código que se necesitan para llevar

a cabo una función empresarial completa y diferenciada. Se puede acceder a él de

forma remota e interactuar con él o actualizarlo de manera independiente.

la SOA integra los elementos del software que se implementan y se mantienen por

separado, y permite que se comuniquen entre sí y trabajen en conjunto para formar

aplicaciones de software en distintos sistemas.

¿Cómo funciona la arquitectura orientada a los servicios?

Antes de que se empezara a utilizar la SOA a fines de los noventa, era muy difícil

conectar una aplicación con los servicios alojados en otro sistema, y se necesitaba una

integración profunda de punto a punto (conectividad, enrutamiento, traducción de los

modelos de datos, etc.). Luego, los desarrolladores debían repetir el proceso para

cada proyecto nuevo. Este modelo se conocía como "monolítico", ya que el código

para toda la aplicación formaba parte de una sola implementación. Si algo no

funcionaba correctamente, debía darla de baja por completo hasta que se

solucionaran los problemas y luego volver a implementarla como una versión

nueva

Dado que la SOA expone los servicios utilizando protocolos estándar de red para enviar

solicitudes o acceder a los datos (p. ej., SOAP, JSON, ActiveMQ o Apache Thrift), no es

necesario que los desarrolladores realicen las integraciones desde cero. De hecho, pueden

utilizar los patrones llamados buses de servicios empresariales (ESB) para integrar un

elemento centralizado y los sistemas de backend, y ponerlos a disposición de todos como

interfaces de servicios. Asimismo, pueden reutilizar las funciones actuales en vez de volver

a crearlas.

En este tipo de arquitectura, los servicios se comunican por medio de un sistema "sin

conexión directa". Se trata de un método para interconectar los elementos en un sistema o

una red, de modo que puedan transmitir información o coordinar un proceso empresarial,

mientras se reduce la dependencia entre ellos. En consecuencia, esto da origen a una

nueva aplicación.

Ventajas frente al enfoque monolítico

• Comercialización más rápida y mayor flexibilidad: la posibilidad de reutilizar los

servicios agiliza y simplifica el proceso de ensamblaje de las aplicaciones. Los

desarrolladores no tienen que empezar siempre desde cero, tal como sucede con

las aplicaciones monolíticas.

• Uso de la infraestructura heredada en los mercados nuevos: la SOA permite que los

desarrolladores tomen las funciones de una plataforma o un entorno y las ajusten e

implementen en otros nuevos.

• Reducción de los costos gracias a una mayor agilidad y un desarrollo más eficiente

6

• Mantenimiento sencillo: dado que todos los servicios son autónomos e

independientes, se puede modificar y actualizar cada uno cuando sea necesario, sin

afectar al resto.

• Escalabilidad: la SOA posibilita la ejecución de los servicios en varios lenguajes de

programación, servicios y plataformas, lo cual aumenta la escalabilidad de forma

considerable. Además, utiliza un protocolo de comunicación estandarizado con el

que las empresas pueden disminuir la interacción entre los clientes y los servicios,

lo cual permite ajustar las aplicaciones con menos presiones e inconvenientes.

• Mayor confiabilidad: la SOA genera aplicaciones más confiables, ya que es más fácil

depurar servicios pequeños que un código de gran volumen.

Funciones de la SOA

Los elementos esenciales de la arquitectura orientada a los servicios consisten en

tres funciones.

1. Proveedor de servicios

Se encarga de crear servicios web, ofrecerlos a un registro de servicios disponibles

y gestionar sus condiciones de uso.

2. Agente o registro de servicios

Se encarga de brindar información acerca del servicio a quien lo solicite, y puede

ser público o privado.

3. Usuario del servicio o persona que lo solicita

Buscará un servicio en el registro o por medio del agente, y se conectará con el

proveedor para recibirlo.

¿Qué es la arquitectura orientada a los servicios? (s/f). Redhat.com. Recuperado el 24 de enero de 2023, de

fuente:

https://www.redhat.com/es/topics/cloud-native-apps/what-is-service-oriented-architecture 

MICROSERVICIOS

¿Qué es una arquitectura de microservicios?

La arquitectura de microservicios es un método de desarrollo de aplicaciones software

que funciona como un conjunto de pequeños servicios que se ejecutan de manera

independiente y autónoma, proporcionando una funcionalidad de negocio completa. En

ella, cada microservicio es un código que puede estar en un lenguaje de programación

diferente, y que desempeña una función específica. Los microservicios se comunican

entre sí a través de APIs, y cuentan con sistemas de almacenamiento propios, lo que

evita la sobrecarga y caída de la aplicación.

Los microservicios han creado infraestructuras IT más adaptables y flexibles. Porque si se

quiere modificar solamente un servicio, no es necesario alterar el resto de la

infraestructura. Cada uno de los servicios se puede desplegar y modificar sin que ello

afecte a otros servicios o aspectos funcionales de la aplicación.

Veamos qué ventajas y desventajas tiene la aplicación de una arquitectura de

microservicios frente a otros tipos de arquitectura. Hay que tener en cuenta estos puntos a

8

la hora de identificar qué tipo de arquitectura software será la mejor para un determinado

proyecto u organización.

decide4AI. (2019, septiembre 3). Arquitectura de microservicios: qué es, ventajas y desventajas.

Decide. https://decidesoluciones.es/arquitectura-de-microservicios/

Ventajas

• Modularidad: al tratarse de servicios autónomos, se pueden desarrollar y

desplegar de forma independiente. Además un error en un servicio no debería

afectar la capacidad de otros servicios para seguir trabajando según lo previsto.

• Escalabilidad: como es una aplicación modular, se puede escalar

horizontalmente cada parte según sea necesario, aumentando el escalado de los

módulos que tengan un procesamiento más intensivo.

• Versatilidad: se pueden usar diferentes tecnologías y lenguajes de

programación. Lo que permite adaptar cada funcionalidad a la tecnología más

adecuada y rentable.

• Rapidez de actuación: el reducido tamaño de los microservicios permite un

desarrollo menos costoso, así como el uso de “contenedores de software”

permite que el despliegue de la aplicación se pueda llevar a cabo rápidamente.

• Mantenimiento simple y barato: al poder hacerse mejoras de un solo módulo y

no tener que intervenir en toda la estructura, el mantenimiento es más sencillo y

barato que en otras arquitecturas.

• Agilidad: se pueden utilizar funcionalidades típicas (autenticación, trazabilidad,

etc.) que ya han sido desarrolladas por terceros, no hace falta que el

desarrollador las cree de nuevo.

Desventajas

• Alto consumo de memoria: al tener cada microservicio sus propios recursos y

bases de datos, consumen más memoria y CPU.

• Inversión de tiempo inicial: al crear la arquitectura, se necesita más tiempo

para poder fragmentar los distintos microservicios e implementar la comunicación

entre ellos.

• Complejidad en la gestión: si contamos con un gran número de microservicios,

será más complicado controlar la gestión e integración de los mismos. Es

necesario disponer de una centralización de trazas y herramientas avanzadas de

procesamiento de información que permitan tener una visión general de todos

los microservicios y orquesten el sistema.

• Perfil de desarrollador: los microservicios requieren desarrolladores

experimentados con un nivel muy alto de experiencia y un control exhaustivo de

las versiones. Además de conocimiento sobre solución de problemas como

latencia en la red o balanceo de cargas.

Arquitectura Cliente Servidor

Conceptos

Cliente-Servidor es uno de los estilos arquitectónicos distribuidos más conocidos, el cual

está compuesto por dos componentes, el proveedor y el consumidor. El proveedor es un

servidor que brinda una serie de servicios o recursos los cuales son consumido por el

Cliente.

En una arquitectura Cliente-Servidor existe un servidor y múltiples clientes que se

conectan al servidor para recuperar todos los recursos necesarios para funcionar, en este

sentido, el cliente solo es una capa para representar los datos y se detonan acciones para

modificar el estado del servidor, mientras que el servidor es el que hace todo el trabajo

pesado.

10

Imagen 1.3 https://reactiveprogramming.io/figures/cliente-servidor.png

En esta arquitectura, el servidor deberá exponer un mecanismo que permite a los clientes

conectarse, que por lo general es TCP/IP, esta comunicación permitirá una comunicación

continua y bidireccional, de tal forma que el cliente puede enviar y recibir datos del servidor

y viceversa.

Cliente-Servidor es considerada una arquitectura distribuida debido a que el servidor y el

cliente se encuentran distribuidos en diferentes equipos (aunque podrían estar en la misma

máquina) y se comunican únicamente por medio de la RED o Internet.

11

¿Como se estructura un Cliente-Servidor?

El cliente y el servidor son aplicaciones diferentes, por lo que pueden tener un ciclo de

desarrollo diferente, así como usar tecnologías y un equipo diferente entre sí. Sin

embargo, en la mayoría de los casos, el equipo que desarrolla el servidor también

desarrolla el cliente, por lo que es normal ver que el cliente y el servidor están construidos

con las mismas tecnologías.

Imagen 1.4 https://reactiveprogramming.io/figures/cliente-servidor-architecture.png

Como podemos ver en la imagen de abajo, el cliente y el servidor son construidos en lo

general como Monolíticos, donde cada desarrollo crea su propio ejecutable único y funciona

sobre un solo equipo, con la diferencia de que estas aplicaciones no son autosuficientes,

ya que existe una dependencia simbiótica entre los dos.

En este sentido, es normal tener 3 artefactos, el Cliente, el Servidor y una tercera librería

que contiene Objetos comunes entre el servidor y el cliente, esta librería tiene por lo general

12

los Objetos de Entidad, DTO, interfaces y clases base que se usan para compartir la

información, es decir, objetos que se utilizan en las dos aplicaciones y se separan para no

repetir código (Principio DRY – Don’t repeat yourself), sin embargo, este tercer componente

no es obligatorio que exista, sobre todo si el cliente y el servidor utilizan tecnologías

diferentes o son implementados con diferentes proveedores.

Ventajas

• Centralización: El servidor fungirá como única fuente de la verdad, lo que impide que

los clientes conserven información desactualizada.

• Seguridad: El servidor por lo general está protegido por firewall o subredes que impiden

que los atacantes pueden acceder a la base de datos o los recursos sin pasar por el

servidor.

• Fácil de instalar (cliente): El cliente es por lo general una aplicación simple que no

tiene dependencias, por lo que es muy fácil de instalar.

• Separación de responsabilidades: La arquitectura cliente-servidor permite

implementar la lógica de negocio de forma separada del cliente.

• Portabilidad: Una de las ventajas de tener dos aplicaciones es que podemos desarrollar

cada parte para correr en diferentes plataformas, por ejemplo, el servidor solo en Linux,

mientras que el cliente podría ser multiplataforma.

Desventajas

• Actualizaciones (clientes): Una de las complicaciones es gestionar las actualizaciones

en los clientes, pues puede haber muchos terminales con el cliente instalado y tenemos

que asegurar que todas sean actualizadas cuando salga una nueva versión.

• Concurrencia: Una cantidad no esperada de usuarios concurrentes puede ser un

problema para el servidor, quien tendrá que atender todas las peticiones de forma

simultánea, aunque se puede mitigar con una estrategia de escalamiento, siempre será

un problema que tendremos que tener presente.

• Todo o nada: Si el servidor se cae, todos los clientes quedarán totalmente inoperables.

• Protocolos de bajo nivel: Los protocolos más utilizados para establecer comunicación

entre el cliente y el servidor suelen ser de bajo nivel, como Sockets, HTTP, RPC, etc.

Lo que puede implicar un reto para los desarrolladores.

• Depuración: Es difícil analizar un error, pues los clientes están distribuidos en diferentes

máquinas, incluso, equipos a los cuales no tenemos acceso, lo que hace complicado

recopilar la traza del error.

Arquitectura Cliente-Servidor. (s/f). Reactiveprogramming.io. Recuperado el 24 de enero de

2023, de https://reactiveprogramming.io/blog/es/estilos-arquitectonicos/cliente-servidor

13

Arquitectura Monolítica

¿Qué es la arquitectura monolítica?

La mayoría de las veces, un software es una combinación de diferentes conjuntos de

características. En la arquitectura monolítica, todas las características de un software

residen en una única base de código y se implementan como un solo archivo. Si se

requieren actualizaciones de código, esas actualizaciones no se pueden acomodar de

forma independiente. El desarrollador tiene que usar la misma base de código, realizar los

cambios de código necesarios y luego volver a implementar el código actualizado.

Entonces, incluso si se requiere un solo cambio, toda la base del código se toca y se

vuelve a implementar.

Tipos de arquitectura monolítica:

Existen principalmente dos tipos de Arquitectura Monolítica:

• Arquitectura monolítica de proceso único:

Si todo el código de una aplicación se implementa como un solo proceso, este tipo de

arquitectura se denomina Arquitectura monolítica de proceso único.

14

imagen 1.5

https://ichi.pro/assets/images/max/724/1*wkX_NBLUolnhEQs-Y-GHgQ.png

• Arquitectura monolítica modular:

En esta variante de arquitectura monolítica, un solo proceso de aplicación consta de

varios módulos. Cada uno de estos módulos puede funcionar de forma independiente. Los

módulos tienen interfaces y pueden comunicarse entre sí a través de estas interfaces. La

base de datos subyacente es la misma y todos los módulos utilizan la misma base de

datos para todas las operaciones. Pero, aun así, todos los módulos deben combinarse

para formar un solo archivo para la implementación.