Arquitectura de Software: Quién la diseña y por qué

Para crear una aplicación o servicio complejo y a gran escala, es necesario planificar cuidadosamente el proceso de creación y desarrollo del programa: cómo crecerá, cómo cambiará, qué deben hacer los desarrolladores en caso de fallos y cómo reemplazar ciertas funciones si quedan obsoletas.

Este complejo mecanismo del software se denomina arquitectura. A continuación, te explicamos cómo funciona la Arquitectura de Software.

¿Qué es la arquitectura de software y para qué sirve?

En pocas palabras, la arquitectura de software es un plan cuidadosamente elaborado para el desarrollo de un programa.

Un programa puede constar de una gran cantidad de funciones, clases y objetos. En servicios pequeños, puedes simplemente abrir un editor de código y empezar a escribir, añadiendo nuevas funciones sobre la marcha. Pero a medida que el programa crece y se desarrolla, aumenta la probabilidad de que empiece a comportarse de forma inesperada; por ejemplo, al añadir nuevas funciones, las antiguas pueden dejar de funcionar correctamente.

En proyectos pequeños, casi siempre es posible corregir el programa o reescribirlo por completo si ya no es posible corregirlo. Pero incluso en estos pequeños bloques de código y con una descripción clara de los errores, puede ser difícil encontrar el problema o comprender cómo se debería haber hecho para evitar los errores.

En los programas grandes, es imposible prescindir de un plan: normalmente, varias personas trabajan en el código, y es necesario garantizar que el servicio siga funcionando incluso después de varios años y con una gran cantidad de cambios. Por lo tanto, los desarrolladores decidieron crear un plan teniendo en cuenta todos los requisitos del producto.

En resumen:

• Si tu proyecto es pequeño, puedes prescindir de la arquitectura.
• Si se planea algo a gran escala y potencialmente grandioso, es absolutamente necesario pensar en todos los pasos y escribir un plan de desarrollo detallado para comprender de antemano hacia dónde se dirige el programa.

Principios básicos de la arquitectura de software

Debido a que todos los servicios y aplicaciones sirven a sus propias funciones, no existe una guía única para la creación de una arquitectura universal. Sin embargo, hay algunos consejos para su creación que son aplicables a casi todas las variantes de software.

1. Investigación: La arquitectura del sistema debe comenzar con una investigación.

El futuro programa siempre tiene un cliente, incluso si eres tú mismo. Además del cliente, existen los usuarios, los escenarios de uso previstos, los recursos y las cargas. Todo esto debe recopilarse y analizarse para ver cómo funcionará el sistema en diferentes escenarios y situaciones; esto influirá en el enfoque que se elija para la creación del programa.

2. Modularidad: El sistema debe dividirse en módulos independientes, en la medida de lo posible.

Esto significa que la base de código debe dividirse en fragmentos, cada uno de los cuales será responsable de su propia parte del trabajo. De este modo, será más fácil y seguro escalar, actualizar y solucionar problemas. Los componentes deben estar lo menos interconectados posible para que los fallos y errores en una parte no tengan consecuencias críticas para otras partes. Lo ideal es utilizar una API o su equivalente, donde los módulos intercambian datos en un formato unificado.

No es obligatorio que la aplicación se divida en fragmentos diferentes si existe otra forma de controlar su funcionamiento y desarrollo. Pero, en la mayoría de los casos, es más fácil hacerlo dividiendo el programa en módulos.

3. Independencia: Las partes del programa no deben depender unas de otras de arriba hacia abajo.

Por ejemplo, el código del servidor no debe depender del formulario de inicio de sesión del sitio web. Esto simplifica la comprensión del sistema y protege contra errores imprevistos en las partes importantes de los servicios.

4. Escalabilidad: La arquitectura de la aplicación debe permitir la escalabilidad.

El escenario más obvio: la aplicación se ha vuelto popular de repente, por lo que es necesario aumentar el número de servidores que atienden a los usuarios. Si no se tiene en cuenta la posibilidad de escalabilidad de antemano, no será posible añadir rápidamente estos servidores y distribuir la carga.

5. Resistencia a fallos y seguridad.

Durante el diseño, hay que tener en cuenta la posibilidad de errores y fallos, y prever algoritmos de actuación en estos casos. El ejemplo más sencillo es restringir los derechos de los usuarios del programa para que el cliente no pueda acceder accidentalmente a los derechos de administrador.

6. Observabilidad y monitorización.

Para ver cómo funciona todo, los desarrolladores y administradores idealmente deben tener acceso a las métricas e indicadores. En proyectos sencillos se puede prescindir de ello, pero en proyectos grandes, de cuyo funcionamiento ininterrumpido dependen muchas personas, esto es absolutamente necesario.

Tipos de estilos arquitectónicos

En función de las investigaciones iniciales, los desarrolladores obtienen una idea de cómo seguirá su programa y cómo se desarrollará. Con el tiempo, empezaron a aparecer soluciones similares que se agruparon y se convirtieron en estilos arquitectónicos.

No se puede decir que un estilo sea mejor que otro. Aunque algunos estilos se utilizan con más frecuencia, esto suele estar dictado por otras condiciones: el número de desarrolladores del equipo, los recursos del cliente y las tareas específicas. El responsable del diseño, el arquitecto, determinará qué utilizar.

Hoy en día existen muchos estilos arquitectónicos; en Wikipedia hay actualmente 35. Hablaremos de dos tipos principales de arquitectura de software; los demás se basan en ellos.

Arquitectura monolítica

Este es el tipo de arquitectura más popular para servicios y aplicaciones pequeñas.

Para seguir este estilo, no es necesario hacer nada especial: simplemente escribe todo el código sin dividirlo en módulos. Esto es un monolito: toda la base de código en un solo lugar.

Ventajas de la arquitectura monolítica:

• Es fácil de escribir, probar y ejecutar.
• Debido a que todas las funciones se encuentran en un solo lugar, el desarrollador o los desarrolladores tienen una idea clara de las interrelaciones dentro del programa.

Desventajas:

• A medida que se desarrolla, el mantenimiento de una gran base de código se vuelve complejo. Un programa grande se convierte en algo engorroso, y trabajar con él ya no es tan cómodo.
• Debido a que la aplicación solo tiene un componente central, cualquier cambio en una parte puede provocar cambios en otra.
• Si es necesario modificar o escalar una función u objeto, puede resultar difícil, ya que en un monolito todo suele estar interconectado.

Algunas grandes empresas que utilizan la arquitectura monolítica (aunque no siempre se limitan a ella): GitHub, Twitter, Atlassian, Airbnb, SoundCloud, Netflix.

Arquitectura de microservicios

Este tipo de arquitectura divide todo el proyecto en segmentos: microservicios.

Una aplicación grande puede tener microservicios separados para cada tarea. Se obtienen aplicaciones independientes: bloque de administración de usuarios, trabajo con la base de datos, procesamiento de pedidos, entrega, widgets. Todo esto está de alguna manera interconectado; es posible añadir nuevos módulos y modificar su contenido sin afectar a la forma de interacción.

Ventajas de los microservicios:

• Es más fácil mantener y desarrollar los microservicios que la arquitectura monolítica, ya que dependen poco unos de otros, por lo que se puede modificar y actualizar uno sin temor a dañar la aplicación general.
• Se pueden asignar diferentes desarrolladores a cada microservicio. Estos equipos son fáciles de organizar porque los microservicios son independientes.

Desventajas:

• Es más caro y complejo que la arquitectura monolítica.
• La interacción entre los diferentes microservicios debe configurarse de todos modos, ya que sigue siendo una sola aplicación. Esto puede ser complejo.
• Las pruebas y la seguridad pueden requerir más tiempo y preparación, ya que el sistema resulta bastante complejo.

Algunas empresas conocidas que también construyen sus productos en microservicios: Amazon, Uber, Coca-Cola, eBay, SoundCloud, Netflix.

Ten en cuenta que algunas empresas utilizan tanto la arquitectura monolítica como la de microservicios. Por lo tanto, no es necesario ceñirse estrictamente a un solo principio si es más cómodo organizar el trabajo utilizando simultáneamente diferentes enfoques.

Patrones arquitectónicos

Además de los estilos arquitectónicos, existen patrones o plantillas. Se trata de enfoques probados para el diseño que funcionan bien para tareas ya conocidas. Hay muchos más patrones que estilos, porque hay más tareas pequeñas concretas que tareas globales para la construcción de un servicio completo.

La mayoría de los patrones pertenecen a la arquitectura de microservicios, ya que la interacción en la variante monolítica es mucho más sencilla.

Algunos ejemplos de patrones arquitectónicos:

• Capas (layers): Patrón de arquitectura monolítica. Todo el proyecto se divide en varias capas, y cada nivel es responsable de una tarea específica. En la arquitectura de microservicios, estas capas se trasladan a servicios separados.
• Registro de servicios (Service Registry): Patrón de microservicios en el que todos se registran en un registro central. Cuando un microservicio accede a otro, accede a este registro y conoce la dirección actual del servicio necesario. Esto permite que los microservicios se descubran entre sí durante el funcionamiento y se utiliza a menudo durante el escalado del proyecto.
• Origen de eventos (Event Sourcing): Esquema en el que se guardan todos los estados del sistema, tanto el actual como los anteriores. Esto permite restaurar el estado de la aplicación en cualquier momento. Es especialmente útil en servicios donde es importante el historial de cambios y la posibilidad de reversión.
• Base de datos por servicio (Database per Service): Cada microservicio recibe su propia base de datos para no depender de un solo repositorio y aislar los datos de los diferentes servicios. A veces funciona bien, pero hay situaciones en las que es más sencillo llevar todo en una sola base de datos para no perder tiempo en el mantenimiento de una decena de bases de datos diferentes y en el trabajo con ellas.
• Composición de API (API Composition): Solución que ayuda a obtener datos de diferentes servicios web después de utilizar un patrón con bases de datos separadas. Según esta plantilla, se crea una API separada que llama a diferentes módulos y combina los resultados obtenidos en la memoria.
• Disyuntor (Circuit Breaker): Patrón para prevenir fallos. Si uno de los servicios empieza a fallar, el disyuntor cierra el acceso a él hasta que los desarrolladores reparen el sistema. Esto evita la sobrecarga y permite restaurar el servicio general. Suena sencillo y lógico, pero un disyuntor de este tipo no debe detener todo el sistema, y esto ya es una tarea compleja en el diseño de sistemas grandes donde todo está interconectado.

Diseño de la arquitectura de software

La arquitectura es una forma de organizar los programas informáticos. Pero no es un conjunto estricto de reglas y técnicas, por lo que no basta con aprender los patrones y estilos. Para el diseño se necesita comprender tanto los principios básicos del funcionamiento del software como la experiencia con tecnologías concretas.

El proceso en sí también puede variar: el arquitecto puede idear un esquema mentalmente, dibujarlo o construir un modelo 3D. Lo importante es que le resulte cómodo trabajar y que pueda explicar a los desarrolladores sus tareas concretas.

Quién desarrolla la arquitectura

La arquitectura suele ser desarrollada por desarrolladores de backend. Esto lo hacen tanto arquitectos experimentados como otros programadores, a menudo a partir del nivel junior.

Después de llegar al nivel senior, un desarrollador backend puede desarrollarse en tres direcciones:

• No cambiar nada, trabajar en un puesto senior, seguir creciendo en salario y recibir nuevas tareas más complejas y serias como desarrollador.
• Convertirse en líder de equipo: organizar el equipo y trabajar menos con la tecnología.
• Convertirse en arquitecto: trabajar más con el sistema y las tecnologías, supervisar el desarrollo y el correcto funcionamiento de los servicios.

El dominio de la habilidad de diseñar una arquitectura no llega solo, y en las empresas, para un ascenso a menudo es necesario tener cierta capacidad para diseñar. Así es como puede verse esta gradación según el puesto:

• Desarrollador junior: realiza tareas claras que, en la mayoría de los casos, le explican desarrolladores más experimentados. Perfecciona sus habilidades tecnológicas, conoce al equipo y al conjunto de herramientas. A menudo realiza el trabajo manual: trabaja en equipo con desarrolladores intermedios o senior, ayuda con sus tareas y adquiere experiencia.
• Desarrollador intermedio: debe ser capaz de diseñar y realizar una pequeña parte del proyecto de forma independiente. No necesita diseñar todo el sistema, pero debe ser capaz de hacer un fragmento, por ejemplo, cargar las páginas de una sección específica del sitio web desde el backend al frontend con todas las conexiones necesarias con los demás componentes de la aplicación.
• Desarrollador senior: es un desarrollador experimentado que puede encargarse del diseño de varias partes del servicio. Todavía no es un arquitecto, pero un especialista que se encuentra un escalón por debajo.
• Arquitecto: diseña todo el sistema y, posiblemente, también desarrolla algunos módulos de la aplicación.

Ventajas de una buena arquitectura de software

Algunas de las principales ventajas que ofrece una buena arquitectura son la previsibilidad y la observabilidad del software.

La previsibilidad del programa permite comprender hacia dónde se dirigirá el proyecto, cómo escalarlo y qué problemas se pueden esperar. Con un buen proyecto, el equipo ya sabe en la fase de investigación la cantidad de esfuerzo y tiempo que se necesitará para la implementación y puede reforzar de antemano los puntos débiles potenciales del sistema.

La observabilidad se consigue gracias a la transparencia del funcionamiento del sistema y a la monitorización, un sistema configurado para el seguimiento del estado del proyecto. Conociendo la estructura de interacción de todas las partes, se pueden añadir elementos a cada una para transmitir el estado. De este modo, parte de los fallos serán visibles con antelación y algunos podrán repararse rápidamente.

Herramientas y métodos de diseño arquitectónico

Para el diseño no es necesario utilizar herramientas especiales ni ceñirse a enfoques estrictos. Es importante que el arquitecto cree un esquema para sí mismo para comprender con exactitud la interacción de los componentes del proyecto entre sí.

Actualmente, existe una gran cantidad de herramientas y estándares para el diseño de la arquitectura de software, incluso para el trabajo en equipo. Algunos ejemplos son:

• UML (Unified Modeling Language): lenguaje para crear diagramas de clases.
• ArchiMate: estándar abierto para el modelado de la arquitectura corporativa.
• Modelo C4 (C4 Model): método visual de modelado de la arquitectura.
• Microsoft Visio, Lucidchart y Draw.io: editores gráficos de diagramas y esquemas.

Errores más comunes en la creación de la arquitectura de una aplicación

La mayoría de los errores en el diseño de la arquitectura se reducen a la violación de los principios básicos de su preparación:

• No realizar una investigación preliminar y no establecer los requisitos para la futura aplicación.
• Elegir una arquitectura monolítica sin tener en cuenta la posibilidad de escalabilidad.
• Realizar el diseño sin tener en cuenta la distribución de responsabilidades de los diferentes módulos.
• Diseñar un sistema sin documentación.
• No analizar los posibles riesgos.

Cómo convertirse en arquitecto de software

Para convertirse en arquitecto, primero hay que convertirse en desarrollador.

Si quieres saber cómo es, prueba los Cursos Online Programación. Todos los programas incluyen lecciones con conocimientos relevantes, proyectos en el portafolio y apoyo de mentores para quienes quieran empezar pero no sepan cómo.