Todo desarrollador se ha enfrentado alguna vez a un código espagueti. Ese momento en el que añadir una simple funcionalidad rompe tres cosas diferentes en la otra punta de la aplicación. Aquí es donde entra en juego la verdadera importancia de la Arquitectura del Software. No se trata solo de hacer que el código funcione hoy, sino de garantizar que siga funcionando y evolucionando el día de mañana.
¿Qué es exactamente la Arquitectura del Software?
La arquitectura del software es una pieza fundamental en el desarrollo de sistemas modernos. Su propósito es definir la estructura, los componentes y las interacciones que conforman una aplicación o sistema. Pero no se trata solo de cuestiones técnicas: la arquitectura del software crea los cimientos para garantizar la calidad, escalabilidad y sostenibilidad de los proyectos, funcionando como un puente que conecta los objetivos del negocio con las soluciones tecnológicas.
Historia de la Arquitectura del Software
Con el paso del tiempo, todo evoluciona. Las soluciones se van perfeccionando, corrigiendo y adaptando a las nuevas necesidades. En este aspecto el software no iba a ser diferente. Desde su nacimiento (aproximadamente en los años 50) el software y, por tanto, su arquitectura, han ido evolucionando de la mano de las nuevas tecnologías informáticas. Las capacidades del hardware, tanto de procesamiento como de comunicaciones, han crecido exponencialmente en el último siglo. Este desarrollo del hardware ha permitido la evolución del software y su arquitectura, transformándolo para aprovechar las nuevas capacidades que provee el hardware.
Los sistemas han pasado de simples programas monolíticos a la computación distribuida basada en microservicios. Los paradigmas arquitectónicos han evolucionado para dar lugar a soluciones a los retos de cada época. A continuación, exploraremos los diferentes paradigmas por los que ha ido pasando la arquitectura del software a lo largo de su historia:
- Sistemas monolíticos (décadas de 1960 y 1970): El concepto de software monolítico hace referencia al tipo de software en el que toda la funcionalidad está encapsulado en un mismo bloque o archivo de código.
- Sistemas distribuidos (finales de 1970 y década de 1980): El avance de las redes y las comunicaciones permitieron la interoperabilidad entre sistemas, de esta forma, surgieron las arquitecturas distribuidas. En este tipo de arquitecturas los diferentes componentes del software se comunican entre sí para dar lugar a la funcionalidad completa.
- Arquitectura cliente servidor (décadas de 1980, 1990 y 2000): Este modelo arquitectónico (también distribuido) separa las aplicaciones en dos capas principales: El cliente, encargado de la interfaz de usuario, y el servidor, que procesa las solicitudes de los clientes, manteniendo la lógica de negocio y se encarga del almacenamiento de los datos.
- Arquitectura de capas (década de 1990): Paralelamente a la arquitectura cliente-servidor, se desarrolló el paradigma de arquitectura de capas. Consiste en dividir la aplicación en múltiples capas especializadas, cada una de ellas especializada en una tarea concreta. Se trata de una división lógica de capas, no implica que estas tengas que estar separadas en diferentes máquinas, aunque podría ser el caso, como ocurre en la programación web.
- Arquitectura orientada a servicios (década 2000): La arquitectura orientada a servicios (SOA) surgió ante la necesidad de integrar diferentes sistemas heterogéneos. Este enfoque introduce el concepto de componentes software autónomos, conocidos como servicios, que pueden ser consumidos o utilizados a través de interfaces (canales de comunicación) bien definidos y estándares. Bajo este paradigma, podemos tratar el servidor como un servicio y ofrecer toda su funcionalidad de forma “autónoma” y desatendida para que sea consumida por un cliente cuando este lo requiera.
- Microservicios (década de 2010 hasta actualidad): Se trata de la evolución natural de la arquitectura orientada a servicios. Este paradigma propone dividir las aplicaciones en pequeños servicios independientes que pueden ser desarrollados, desplegados y escalados de forma independiente. Esto mejora la escalabilidad, ya que pueden ser escalados solo aquellos microservicios que hagan falta.
¿En qué ayuda la Arquitectura del Software?
Más allá de simplemente organizar líneas de código, una arquitectura bien planteada actúa como la columna vertebral de cualquier proyecto. Su verdadero valor no se aprecia el primer día de programación, sino a largo plazo: ayuda a prevenir fallos en cadena, facilita que la aplicación escale de forma segura cuando crece el volumen de usuarios y ahorra incontables horas de mantenimiento y frustración a todo el equipo de desarrollo.
Comenzar un desarrollo sin una arquitectura previa, en primer lugar, supondrá un gran problema a la hora de realizar el desarrollo de forma paralela. No será sencillo dividir tareas si no tenemos claros cuales son los componentes que formarán nuestro software. Otra dificultad que encontraremos será, que llegado un punto del desarrollo nos daremos cuenta de que hay una forma mejor de estructurar el código. Llegado este punto, estaremos obligados a realizar una reestructuración del código, lo que supondrá un enorme número de horas, que, en el paradigma empresarial, se traduce en un aumento de costes. Por último, un software con una mala arquitectura será complicado de mantener. Una estructura monolítica, con clases muy grandes y poco especializadas será difícil de comprender para la persona que realiza el mantenimiento y será difícil modificar la funcionalidad sin afectar a otras partes del código. Además, es muy posible que nuestro software no sea sencillo de escalar para albergar un mayor número de usuarios.