Castillos en el aire

Castillos en el aire

Normalmente paso el 50% de mi jornada de trabajo en reuniones, workshops, entre equipos revisando soluciones y el 50% (en teoría) restante lo dedico a montar castillos en el aire. Y si, por castillos en el aire me refiero a VPC, sub redes, balanceadores, maquinas, servicios, streams, colas, cdns, caches… y un pijón de cosas más, que, como el manual del arquitecto tradicional hacía sobre una mesa con paralés y escuadra y cartabón; nosotros usamos Visual Paradigm, Lucid, Infra como código, o cualquier solución que nos permita “dibujar”.

Todo empieza en un papel

Una de la primeras cosas que aprendí es la importancia del papel en nuestra profesión (estaría encantando de tener un iPad Pro con el Pencil, pero… Tim, algo más asequible hombre, que un Bic y un folio son bien también). Creo no ser el único bicho raro, que para la cosa más simple primero se tira una lineas de carbón en una libreta. Ahí es donde empieza todo, unos requisitos de alto nivel en la cabeza (normalmente un nuevo reto), un papel en blanco, un lápiz y un Standler de 0.2.

Este es el punto en el que empezamos a crear la fortaleza. Un gateway por aquí, balanceadores por el otra lado, un bastión por si las moscas, un AKS, EKS, EMR, o lo que toque, y ya tenemos flotando un primer mapa “vomitado” directamente del cerebro al papel pasando por la mano. Poco a poco, con la experiencia, te das cuenta que en definición poco hay que pensar sobre la implementación. Mi siguiente paso sobre el papel, es imaginarme diferentes escenarios o casos de uso que pueda deducir de los requisitos, y es donde empezamos con la Evolución.

Diseño Evolutivo

En nuestra industria existen una serie de patrones, buenas prácticas y componentes, del mismo modo que existen en otras ingenierías, desde la de caminos, hasta la genética, pasando por la industrial. A esto me gusta añadir cierta parte de intuición/creatividad que viene de la mano del arte, y no hablo de UI/UX. A todo arquitecto le gusta ver su obra acabada, con todos los detalles, el agua fluyendo por las tuberías y la luz perfectamente regulada con la temperatura ideal. Pero detrás de eso, hay un trabajo muy tedioso de planificar, y muchas veces, dilucidar, por donde va a fluir ese agua y donde los sensores de luz y térmicos cumplen su función de la forma más eficiente posible.

Y con esto habremos construido la casa perfecta? Tendremos la llave de la arquitectura final?

Pues exactamente igual que en el sector IT, lo siento, pero NO. Lo que el arquitecto hace (o debe) es mirar más halla del alcance, analizar el entorno y lo que lo rodea (riesgos, dependencias, negocio, equipos, presupuesto, y un largo etc…) para poder establecer una estrategia de evolución.

Cuando hablo con algunos compañeros del paradigma del diseño de arquitecturas evolutivas, normalmente empezamos la discusión por el mismo.

Amigo1: Claro que hacemos arquitecturas evolutivas. Escalamos en todas las direcciones, y hasta si me descuido en diagonal :muscle: y no solo eso, si nos vienen casos de uso nuevos, como hacemos “clean architecture” eso está chupado, repositorio, contrato, entidad, transformación, presentación y ale a correr.
Yo: Interesante, y cuales son las funciones de fit que usáis para ver, cuando hacer que…
Amigo1: Ya vamos viendo.
Yo: Muchas Suerte con eso 🙂

Un día de Slack

Y en ese punto es mejor para, no por que no este mal, si no por que es algo perfectamente valido, pero con la definición de arquitecturas evolutivas en la mano podemos decir que:

An evolutionary architecture consists of three primary aspects: incremental change, fitness functions, and appropriate coupling. In the remainder of the book, we discuss each of these factors separately, then combine them to address what it takes to build and maintain architectures that support constant change.

Building Evolutionary Architectures – N. Ford/R. Parsons/P. Kua

En la descripción identificamos rápidamente las reglas del juego para montar castillos en el aire:

  • Control del cambio de forma incremental. (Al que se le pase por la cabeza cascada, por favor, pare de leer)
  • Fitness functions. Nos ayudan a controlar la integridad de nuestra arquitectura. Personalmente me gusta ponerlas en el lado devops/ops.
  • Un nivel de acoplamiento y coesión adecuados. Y entendamos ese adecuado como el suficiente como para no hacer una chapuza, pero tampoco acabar siendo una cebolla; vamos, xeitiño (sentido común para los gallegos).

Diseño incremental para reducir el coste de infraestructura y cambio

Uno de los pilares en los que se basa la arquitectura en la nube es la reducción de costes o ser eficiente con estos. De manera vaga, podríamos decir que es el arte de tener un setup en el que pagamos única y exclusivamente por lo que se usa. En este punto estaremos pensando en los servicios “fully managed” (ya hablaremos del modelo de responsabilidad compartida), en algunos casos ya ayudan a la gestión de costes.

El problema en las empresas de sobre costes o lo contrario, déficit de presupuesto con impacto en el rendimiento, son los dos quebraderos de cabeza de estas:

Sobre costes: Pongamos que en la empresa X pongo 4 maquinas con un coste mensual de $40 cada una, $160 al mes. Cuando vemos las telemetrías observamos que en la media las maquinas están a un 30% de uso o incluso en algunos momentos, prácticamente sin uso. Dado que en algunos momentos del día los picos de carga hacen que se usen todas las máquinas al 80%, los arquitectos han concluido que el setup es correcto, y si lo es, pero deja de estar lejos de ser eficiente en costes.
Deficit de presupuesto: A veces se intenta soportar cargas que generan un estado de sobre carga en las máquina por no invertir lo suficiente, o no encontrar la manera de abaratar los costes y acomodarlos dentro de un presupuesto, por desgracia, para muchas empresas, la nube no puede ser una barra libre donde tirar miles de euros al mes. Este déficit que provoca sobrecargaras en los momentos clave del día (cuando los usuarios están haciendo más uso de un producto, suelen ser los golden minutes y todo tiene que ir como la seda), afecta los tiempo de respuesta, calidad del servicio y en consecuencia degrada el servicio. En este caso la empresa Z solo se puede permitir dos máquinas que normalmente están a un 50% de carga, tocando el 100% en los momento calientes del día.

Empresa Z

Estas dos situaciones, aun que diferentes, tienen el mismo problema de fondo. La falta de métricas sobre el volumen necesario para operar en la nube y montar castillos en el aire, hace que no tengamos cimientos sobre los que en algún momento, dejaremos posar el castillo levantado.

Es por eso que recoger telemetrías, hacer test de capacidad y eficiencia son claves para ajustar los costes de cualquier arquitectura en la nube. Si bien hay muchas formas de llevar esto a la práctica, cuando hablamos de producto y de su parte IT, las funciones de Fitness entran en juego.

Con las métricas en la mano, querremos que nuestra infraestructura viva siempre en un punto intermedio saludable (la capacidad mínima esperada), que todo funcione correctamente y añadir las reglas de auto-escalado de servicio necesarias, apoyadas por las métricas obtenidas, que hagan que nuestra infraestructura escale durante los periodos de tiempo cortos y de más carga, de forma que el servicio no se vea degradado. Cada proveedor de servicios en la nube tiene sus propios mecanismos para llevar acabo este tipo de solución.

Modulación del acoplamiento

Por mi experiencia, cada vez que hemos cogido una pila de requisitos y nos encerramos en una habitación 6 meses; acabamos generando más acoplamiento del debido. Los motivos suelen ser varios:

  • visión largoplacista: puede hacer girar una lógico de negocio al tercer mes con un impacto serio sobre el diseño
  • prisas finales: acortamiento de fechas, asumir situaciones de negocio en base a los requisitos…

Un montón de factores nos pueden llevar a sufrir nuestras propias soluciones.

De este primer párrafo hay dos puntos muy importantes, fuente de todos los males:

La cueva
El tiempo, 4, 5… x meses

Con el tiempo poco podemos hacer, pero de la cueva podemos salir. Al salir de la cueva, también vemos pasar el tiempo, y de esa observación nace la intuición que nos llevara a tomar determinadas decisiones, a medida que ponemos o quitamos piezas en un puzle con un aparente caos controlado. Las piezas pueden ser cualquier cosa, desde una lambda, hasta servicios tirados a golpe de Istio y k8s; el puzle es negocio, un ente complejo y que toma decisiones cada vez más rápido. El caos controlado… toda evolución lleva un poco caos asociado, creo que alguien con más tiempo que yo, debería de escribir un libro que se llamase “Arquitecturas del Kaos” (con K tiene más tirón :P).

Conclusión

Me atrevería a decir que cualquiera de los bloques de arquitectura de los que estamos a acostumbrados a hablar, debería de moverse a un modelo evolutivo. Software, Datos, Solución, UX,… en un entorno sano y ágil, se debería de poder, justamente, diseñar para el caos que nos envuelve cada día.

Y se podría decir, que es también mi trabajo (y es precioso).

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.