This post is also available in english

En el mundo del software, cuando se piensa en la arquitectura, no hay una definición concreta sino una serie de debates y opiniones al respecto. Todas y cada una de ellas objetables.

Por ejemplo, podemos pensar a la arquitectura como la organización fundamental de un sistema, es decir, los aspectos más importantes del diseño interno de un sistema de software, cómo están conectados los componentes de más alto nivel. Pero, ¿cómo se define qué es fundamental o de alto nivel?

También podríamos pensar que la arquitectura son las decisiones que deben ser tomadas al comienzo de un proyecto aunque, en realidad, son las decisiones que uno desearía haber tomado bien al inicio de un proyecto

A grandes rasgos, una de las cuestiones sobre la que parece haber consenso es que la arquitectura tiene que ver con algo importante que influye mucho sobre el desarrollo del proyecto. La arquitectura se trata de las cosas importantes. Sea lo que eso sea.

¿Qué elementos son importantes? ¿Qué elementos pueden generar problemas si no se los controla? Muy subjetivo, ¿no? Lo que para unx es importante, quizás para otrx no lo sea.

Acá aparece una de las ideas centrales y, en mi opinión, más interesantes: la arquitectura es una construcción social; depende del consenso grupal sobre qué es importante.

Situación #1: un grupo de desarrolladorxs construye un gran sistema de software y define que la persistencia es crucial. Define sin preámbulos que usan por ejemplo Oracle para su base de datos y tiene su propia capa de persistencia para mapear objetos.

Situación #2: otro grupo de desarrolladorxs trabaja en una aplicación de diagnóstico por imágenes. Usan Oracle, pero no consideran a este aspecto parte de la arquitectura porque el mayor desafío en un sistema de este tipo está en analizar las imágenes; no en guardarlas.

El quid de la cuestión está entonces en definir qué es lo importante y generar consenso al respecto.

¿Cuál es la diferencia entre styles y patterns?

Antes de seguir avanzando, me parece importante hacer una distinción entre estilos de arquitectura y patrones de arquitectura.

Los estilos son más macro. Tienen que ver con la estructura general y la organización de la interfaz de usuario, el código del backend y cómo ese código interactúa con los datos almacenados.

Loa patrones, en cambio, son más micro. Están relacionados con estructuras de diseño de más bajo nivel que ayudan a formar soluciones específicas dentro de un estilo de arquitectura.

Algunas consideraciones sobre los sistemas distribuidos

Hay dos grandes tipos de sistemas: los monolíticos y los distribuidos.

La mayor diferencia es que los monolíticos consisten de una única unidad deployable, mientras que los distribuidos consisten de múltiples unidades deployables que están conectadas por protocolos de acceso remoto tipo REST o SOAP.

Junto con el hype por usar sistemas distribuidos como los famosos microservicios vienen una serie de falacias que nos invitan a ignorar algunos de las consideraciones que deberíamos tener en cuenta a la hora de optar por este tipo de sistemas.

  1. La red NO es confiable. Es importante porque todos los sistemas distribuidos se apoyan en la comunicación entre redes hacia los servicios, desde los servicios y entre los servicios.
  2. La latencia NO es cero. En las llamadas locales a través de métodos o funciones el tiempo se mide en nanosegundos o microsegundos. Cuando esa misma llamada se hace a través de un protocolo tipo REST, el tiempo se mide en milisegundos.
  3. El ancho de banda NO es infinito. Por ejemplo, cuando se usan microservicios la comunicación entre ellos usa mucho ancho de banda y esto genera que la red se enlentezca, lo que a su vez impacta en los dos puntos anteriores (latencia y confianza).
  4. La red NO es segura. Tienen que tomarse medidas de seguridad en cada endpoint y esto también ralentiza el sistema.
  5. La topología cambia. Se necesita estar continuamente en comunicación con los admin de redes y operaciones para ver qué cambios hay y adecuar los sistemas.
  6. No hay un solo admin. Un poco lo mismo del punto cinco. Los sistemas distribuidos requieren de mucha colaboración y comunicación.
  7. El transporte tiene costo. Los sistemas distribuidos tienen mayor costo que los monolíticos.
  8. La red no es homogénea. Adecuación de protocolos y esas cosas.

Algunas otras cuestiones a tener en cuenta son el logging distribuido - es difícil ver cuál es el problema cuando hay muchos logs para revisar y con diferentes formatos -, las transacciones distribuidas - a veces hay que sacrificar la consistencia y la integridad de los datos, y el mantenimiento y versionado de los contratos - es particularmente difícil mantener contratos (comportamiento y datos sobre los que acuerdan el cliente y el servicio) por el desacoplamiento de los servicios y porque los sistemas pertenecen a diferentes equipos -.

Estas son algunas de las cosas que hay que tener en la cabeza a la hora de pensar en aplicar una arquitectura distribuida.

Conclusiones

Martin Fowler dice que para él una de las tareas más importantes de un arquitecto es quitar la arquitectura. ¿Cómo? ****Buscando formas de eliminar la irreversibilidad en el diseño de software. Porque la irreversibilidad es una de las principales causas de la complejidad.

Si pensamos en la arquitectura tradicional y la construcción de edificios, una de las principales diferencias con la arquitectura de software es que muchas de las decisiones que se toman cuando se construye un edificio son difíciles de cambiar. Si que quiero tener un sótano diferente, estoy complicada.

En cambio, con el software, no hay ninguna razón física por la que sea difícil cambiarlo. Podés elegir diferentes aspectos del software y hacer que sea fácil cambiarlos. Pero no sabemos cómo hacer TODO fácil de cambiar y aún si hiciéramos que TODO sea fácil de cambiar, aumentaríamos mucho la complejidad del sistema en su totalidad. Y la complejidad es lo que hace que el software sea difícil de cambiar. Además, no sabemos qué aspectos está bueno poder cambiar entonces no sabemos cuándo está buenos cambiar las cosas y cuándo no.

Entonces, en conclusión, el software no está limitado por la física como los edificios sino que por nuestra imaginación, por el diseño y por la organización… todas propiedades de los humanos, no del mundo.

Mi conclusión de la conclusión es que todo es un quilombo y nunca vamos a tomar la decisión correcta 😃.

Muchas gracias por su atención.

Fuentes

Este posteo está basado fuertemente en el artículo Who needs an architect? de Martin Fowler y el libro Fundamentals of Software Architecture. An Engineering Approach de Mark Richard & Neal Ford