For years, many smart developers recognized that some parts of their systems were harder to modify than others. That’s why software architecture is defined as the “parts hard to change later”
Building Evolutionary Architectures
Lo que nos transmite esta reflexión es que, las decisiones arquitectónicas son las que más tiempo perdurarán en la empresa y que más difícil será cambiarlas. Por poner un ejemplo: el lenguaje de programación que usemos para desarrollar. Tras años usando este lenguaje, la gente que tengamos trabajando en la empresa estará cómoda con él y habrá mucha resistencia a cambiarlo o aprender uno nuevo (la banca sigue usando Cobol).
La arquitectura no se centra en cómo vamos a organizar en producción nuestras aplicaciones (monolito, SOA, microservicios, eventos, etc), sino en todas aquellas decisiones que fundamentan cómo la gente trabaja y que finalmente se ven reflejadas en cómo y qué desplegamos a producción.
¡Las decisiones arquitectónicas definirán la cultura de la empresa!
Cultura y arquitectura
Supongamos que, en nuestra empresa ficticia, creamos un equipo de QA que testee manualmente nuestra aplicación de manera independiente a los equipos de desarrollo. Esta estrategia moldea nuestra empresa, cómo los equipos de desarrollo trabajan con QA para subir a producción, cómo ese equipo organiza su trabajo, qué inputs necesitará de los desarrolladores, etcétera. Según pase el tiempo, estos procesos estarán más metidos en el ideario de la empresa y se convierten en la única forma de hacer las cosas.
Ahora supongamos que el mundo cambia, que tenemos que ser capaces de lanzar al mercado nuevos productos muy rápido y pivotar sobre ellos para entender lo que quieren los clientes. En ese nuevo entorno, nuestro QA se acaba de convertir en un bloqueo para nuestro nuevo objetivo. Entramos entonces en cómo cambiar nuestra organización, necesitamos cambiar nuestra cultura, cambiar nuestras decisiones arquitectónicas.
Uno de los puntos, que me parecen más interesante, es el hecho de llegar demasiado tarde a intentar cambiar una decisión arquitectónica. Para tomar estas decisiones dolorosas, deberíamos aplicar el Last Responsible Moment y eso significa que nuestra arquitectura debe adaptarse a la realidad de la empresa y debe poder evolucionar.
Arquitectura y diseño del software
Hoy en día, el mundo software está fascinado por los microservicios, pero ¿todas las empresas deben implementar microservicios?. La respuesta es no, por ejemplo una pequeña empresa con dos desarrolladores les será mil veces más efectivo mantener y gestionar un monolito. Solo deberían pensar en migrar a microservicios cuando empiecen a tener evidencias que su decisión de mantener un monolito representa para ellos un problema.
Si esa misma empresa, necesita introducir muchas más features a su producto y para ello quiere triplicar su plantilla de desarrolladores se enfrentará al problema de adaptar sus decisiones arquitectónicas a su nueva realidad.
La arquitectura de microservicios habilita que una empresa escale en número de equipos autónomos de forma simple. Su objetivo es aumentar la autonomía de los equipos y, por tanto, poder contratar a más gente y hacer más cosas a la vez dentro de la empresa sin tener a los desarrolladores bloqueados. Para ello, aboga por crear pequeños servicios orientados a negocio (dividir verticalmente la base del código), cada uno de ellos será responsabilidad de un único equipo (vertical slicing). Si necesitan comunicarse lo harán de manera lo más desacoplada posible (eventos).
Esta arquitectura tiene un gran impacto en la organización y requiere eliminar silos, especializar equipos, definir cómo interaccionan los equipos si tienen que hacer cosas en un código que no es de uno de sus microservicios, etc. Nos interesa si lo que queremos promover en nuestra organización es la escalabilidad. En cambio, si nosotros estamos más preocupados por los costes de operaciones, entonces un monolito será más adecuado.
Pero el diablo está en los detalles, aunque sepamos que debemos cambiar nuestro monolito por microservicios para gestionar eficientemente el trabajo de nuestros nuevos desarrolladores. Eso será más o menos difícil dependiendo de lo acostumbrada que esté nuestra organización al cambio. Si cambiamos y evolucionamos frecuentemente el dolor será pequeño.
Principio para construir una arquitectura
Estos son los principios sobre los que nos debemos guiar para conseguir una arquitectura que pueda evolucionar:
- Cambios incrementales, nuestra arquitectura debe soportar esos pequeños cambios de forma rápida.
- Ser capaces de medir los atributos que nos interesan de nuestra arquitectura.
- Bajo acoplamiento, el acoplamiento es la antítesis del cambio; algo muy acoplado es muy difícil de cambiar.
La arquitectura del software está relacionada con cómo soportar de una manera eficiente el trabajo de los equipos de desarrollo de la empresa. Esto está relacionado con cómo dividir ese trabajo, quién va a hacer qué, con quién y cómo se va a desplegar a producción. Por poner otro ejemplo, si queremos evitar tener código duplicado y eso es mucho más importante para nosotros que la creatividad de los equipos a la hora de buscar soluciones nuevas, tal vez debiéramos pensar en un monorepositorio.
Una buena arquitectura será aquella que nos pemite resolver todas estas cuestiones organizativas de una manera simple y escalable y también hacer frente a los requisitos no funcionales de nuestras aplicaciones. Pero como bien hemos dicho antes debe tener mecanismos para ser cambiada no está escrita en piedra.
