Arquitecturas de software ¿Cuál y porqué?
Sistemas software
Gran parte de lo que nos rodea basa su funcionamiento en sistemas informáticos, sistemas software que desempeñan una función u/y ofrecen un servicio, desde la red de telecomunicaciones del proveedor de internet, hasta la página web básica del comercio de tu barrio.
Cada uno de esos sistemas está creado bajo unas reglas específicas, uno o varios lenguajes de programación, un contexto de interacción acotado por protocolos… y un sin fin de peculiaridades que hacen que un sistema sea único.
En este pequeño estudio nos centraremos en una de esas peculiaridades: el concepto de arquitectura del software.
¿Qué es una arquitectura de software?:
La arquitectura, como concepto aplicado al desarrollo, consiste en la planificación basada en modelos, patrones y abstracciones teóricas. El objetivo principal de una arquitectura es definir la integración de las partes obedeciendo a una estructura definida que ofrezca determinadas características.
Las principales características a la hora de seleccionar una arquitectura son las siguientes:
- Coste: El coste es el principal factor limitante de un proyecto software de medio/alto nivel, el costo elevado de las arquitecturas con más infraestructura o los desarrollos iterativos aumentan este parámetro.
- Tiempo de desarrollo: a la par con el coste encontramos el margen temporal del que disponemos para la finalización del proyecto, un reducido tiempo imposibilita la inclusión de complejas estructuras.
- Escalabilidad: el volumen de usuarios que soportará así como el número de funcionalidades del proyecto son variables que podemos desear aumentar durante las últimas etapas del ciclo de vida del software, una arquitectura modular y bien definida facilita mucho la tarea.
- Aislamiento: un poco menos relevante que los otros factores también encontramos el aislamiento del producto, si va a formar parte de un conglomerado de sistemas interconectados, debemos utilizar una arquitectura que predisponga esa interconectividad.
- Comodidad o conocimiento: es necesario añadir a esta lista la propia preferencia personal, a menudo justificada en el dominio de unas herramientas concretas, a la hora de elegir la arquitectura de nuestro proyecto.
Arquitecturas de software vs patrones de arquitecturas de software:
Antes de comenzar a enumerar las diferentes arquitecturas, o lo que entendemos por ellas, es útil disociar los términos de arquitecturas y de patrones de arquitecturas, de manera que podemos generar dos enumeraciones atendiendo a distintos principios de implementación y uso.
- Arquitecturas: Generalmente son estructuras que definen y delimitan cómo se integran en un proyecto los componentes, la interacción entre ellos y los flujos de ejecución y datos, podemos verlo como las definición teórica de todo el marco de desarrollo del proyecto.
- Patrones de arquitecturas: Los patrones son soluciones reutilizables que se aplican para tratar de corregir problemas frecuentes en el diseño o el desarrollo del proyecto. Estos patrones permiten aplicar directrices sobre desafíos específicos que ofrece la arquitectura seleccionada.
Simplificando mucho, podemos decir que los patrones de arquitecturas se aplican para corregir las contingencias dentro de una arquitectura.
Entremos ahora en materia hablando de las arquitecturas.
Arquitecturas de software:
Vamos a ver algunas de las arquitecturas de software más comunes:
- Monolito: En una arquitectura de este tipo todo el código se desarrolla y ejecuta como un único proceso, es el planteamiento más sencillo para pequeños proyectos software que no requieren grandes aplicaciones ni serán escalables. Es también muy útil para prototipados rápidos.
Haciendo una interpretación rápida del gráfico podemos apreciar cómo toda la lógica del sistema se encuentra enmarcada en un único entorno, que interconecta con la base de datos y sirve el resultado como petición a una respuesta (aplicado a un modelo cliente-servidor).
- Microservicios: En las arquitecturas de microservicios el sistema se divide en componentes independientes denominados microservicios, su independencia es tal que engloba el desarrollo el despliegue e incluso el escalado. Usamos como palabra clave el escalado, dado que esta arquitectura se enfoca sobre todo a grandes proyectos que exigen una alta posibilidad de escalado.
Cabe destacar que esta arquitectura permite el uso de diversos lenguajes para los diferentes microservicios.
Aquí podemos apreciar la diferenciación de los módulos que operan con la lógica del sistema, incluso se puede ver la existencia de bases de datos de acceso específico y al acceso a través de algún mecanismo de conexión-autorización.
- SPA (Single page application): La arquitectura SPA se caracteriza por la existencia de un único documento HTML sobre el que actúa e itera la lógica de negocio, se caracteriza este modelo por la suavidad de la navegación debido a la ausencia de tiempos de carga y a recursos como el lazy load, que permite un cargado dinámico de los contenidos.
Se utiliza este tipo de arquitectura sobre todo en sistemas que requieren una gran interacción entre el usuario y el sistema.
En la imagen superior podemos apreciar lo más característico de las arquitecturas SPA, su flujo de ejecución y datos.
La ausencia de los tiempo de carga, anteriormente mencionados, son la principal ventaja frente a los sistemas tradicionales multi página.
- Serverless: Es un tipo de arquitectura que no trabaja sobre un back al uso, lo hace sobre unos servicios en la nube, cuyo proveedor se encarga de la infraestructura subyacente.
El flujo de ejecución es muy característico, las funciones programadas se ejecutan como respuesta a eventos, que son peticiones HTTP.
Sistema muy caracterizado por la abstracción, incluso la escalabilidad es contratable según demanda.
Muy utilizado en aplicaciones que esperan picos variables de tráfico y necesitan una alta elasticidad en la disposición de recursos disponibles. También para pequeños equipos que prefieres abstraerse de la infraestructura.
La estructura a través de un grafismo de esta arquitectura se puede extender tanto como lo hagan los servicios necesarios, sin embargo podemos extraer la idea esencial, que es el acceso a los mismos, desde el usuario a través del consumo de los servicios cloud.
- Arquitectura hexagonal: La arquitectura hexagonal, cuya concepción es un poco más abstracta, presenta un modelo de tres capas o anillos que se conectan entre ellas de manera inmediata por cercanía, se trata de aislar la lógica, las implementaciones y las interfaces.
Este tema ya ha sido tratado en más detalle en la web, aquí: enlace.
La aplicación de esta arquitectura se recomienda para proyectos que exigen un alto desacoplamiento entre la lógica de negocio y las interfaces externas, de modo que es sencillo modificar las implementaciones tecnológicas sin tocar la lógica subyacente en el anillo interno.
En la clara representación de los tres anillos podemos observar sus ámbitos de control, por orden de peso en la implementación del sistema, el centro lo ocupa el dominio, donde se define la lógica, esta se implementa en la capa de aplicación y se interconecta a través de los elementos presentes en la capa de infraestructura.
Algo sencillo de apreciar aquí es la posibilidad de sustituir un adaptador sin tocar la lógica, un ejemplo claro es el paso del uso de una base de datos relacional a una no relacional.
Existen multitud de diferentes arquitecturas y este estudio se ampliará gradualmente.
Aquí puedes ampliar tus conocimientos sobre patrones de interacción : enlace