Los sistemas distribuidos y las buenas prácticas son geniales pero la experiencia es mejor

Los líderes de la industria de la tecnología entienden las ventajas de los sistemas distribuidos. Un sistema distribuido es un conjunto de dispositivos o nodos interconectados que trabajan en coordinación y con el mismo objetivo. En sistemas de software, la idea fundamental es que los recursos (o el acceso a los mismos) estén distribuidos a través de múltiples servidores, lo que permita que el sistema sea capaz de manejar un gran volumen de tráfico y datos.

La magia central de los sistemas distribuidos es que facilitan la escalabilidad. Pero es más que eso. Cuando diseñamos la arquitectura de un sistema distribuido de software buscamos que en la medida de lo posible cumpla con ciertos principios. Además de escalabilidad, Kate Matsudaira identifica disponibilidad, desempeño, fiabilidad, manejabilidad y costo.

Para lograr la escalabilidad, los desarrolladores utilizan patrones de diseño como la arquitectura de microservicios, donde cada servicio se encarga de una tarea específica y puede escalarse de manera independiente. Además, de este modo el sistema será fácil de entender y mantener. Por lo tanto, resultará más eficiente, manejable y confiable, y estará disponible la mayor parte del tiempo.

A su vez, la fiabilidad y la tolerancia a fallos se fortalecen mediante el uso de técnicas como la replicación de datos, el uso de sistemas de respaldo y la implementación de pruebas rigurosas. Al tener varios nodos trabajando juntos, si uno de ellos falla, los demás nodos pueden continuar disponibles para brindar servicio.

En mi experiencia, espero que esta capacidad de manejar una gran cantidad de información ayude a adaptar al sistema a las necesidades cambiantes del negocio.

Por supuesto, éste es el escenario ideal, y quienes están a la vanguardia aspiran al mismo lo más posible. Pero cuando aterrizamos el diseño de sistemas distribuidos a los requerimientos del cliente, debemos enfrentar la realidad de que algunos principios y objetivos tendrán más importancia que otros, y que los recursos a nuestra disposición tendrán que priorizar lo más importante para el negocio, todo evaluado a través del cristal de lo aprendido en proyectos anteriores.

Priorizar requerimientos

¿A qué requerimientos debemos dar más importancia? Empecemos por aclarar el panorama distinguiendo los requerimientos funcionales de los no funcionales. Pensemos en los funcionales como aquellos que forman parte de las soluciones que otorgan valor al usuario y se expresan por medio de las historias de usuario, features o capacidades del producto.

En contraste, los no funcionales, aunque un poco más sutiles, son igualmente importantes y describen cualidades operativas críticas, como seguridad, confiabilidad, desempeño, manutención, escalabilidad o usabilidad. Para propósitos del diseño inicial de un sistema, se considera que los requerimientos no funcionales tienen una influencia mayor, mientras que los funcionales no necesariamente se van a definir desde la fase de diseño y pueden ir cambiando.

El punto que quiero que consideres es que, en cuestión de importancia, “todos los requerimientos son iguales, pero algunos son más iguales que otros” (para parafrasear la novela de Orwell). Como dice Nikolay Ashanin, “cuando diseñamos para cumplir cualquier requerimiento, es esencial considerar el impacto sobre otros atributos y encontrar arreglos entre los requerimientos. Junto con esto, el valor o prioridad de cada atributo difiere de sistema a sistema”.

Por ejemplo, un negocio de ventas retail normalmente no necesita que su seguridad sea muy robusta, ya que sus sistemas son internos; con lo que el consumidor interactúa es el front. De manera opuesta, un banco o una institución financiera naturalmente va a pedir que sus sistemas sean impenetrables.

En referencia a los requerimientos no funcionales, Marco Bürckel advierte contra caer en la tentación de quererlos todos. Cada uno de ellos puede incrementar la complejidad del diseño y la implementación, e incluso pueden entrar en conflicto unos con otros. Tal es el caso de un sistema de alto desempeño que perdería portabilidad debido a las demandas de ambiente o hardware.

El valor de la experiencia

Además de los requerimientos específicos del negocio, la que resulte ser la arquitectura más adecuada va a depender del tiempo disponible para el proyecto, del costo del mismo valorado contra el presupuesto disponible, y de los recursos humanos; es decir de los desarrolladores mismos.
En la industria del software, a veces nos encontramos con arquitectos proactivos en lo que se refiere a las mejores prácticas. Sin duda que es buena idea tener respeto por las mismas, pero si un arquitecto se muestra demasiado celoso en su afán por hacer su trabajo “como dice el manual”, puede encontrarse con un gasto excesivo en términos de tiempo, manos y dinero.

Incluso si esto ocurre, habrá una valiosa ganancia en términos de experiencia. El arquitecto habrá aprendido una importante lección acerca de cómo pasar de la teoría a la práctica de los sistemas distribuidos. Una cosa es diseñar sobre el papel, lo cual puede ser tan rápido como una semana o incluso un día. Pero en la ejecución, el arquitecto puede hallar que diseñó y estimó de manera equivocada y no equilibró realistamente sus tiempos y costos.

De hecho, hay quienes opinan que es una certeza que la primera idea de diseño estará equivocada. En la opinión de Bürckel, “la arquitectura de software y los planes de proyectos tienen una cosa en común: El primer intento siempre está equivocado. El inicio del proyecto es donde tienes la menor cantidad de conocimiento acerca de los retos técnicos y no técnicos a los que te vas a enfrentar a través del desarrollo”. 6 De ahí que ese primer intento deba ser abstracto, según Bürckel, y yo añadiría, simple (¡recuerden el principio KISS!).

Tengo la fortuna de trabajar en una empresa líder que favorece la colaboración, la comunicación y la innovación en un entorno de apertura de palabra, tolerancia al error y experimentación. Está claro que el aprendizaje es fundamental, y nada enseña como la experiencia. Por lo tanto, si me preguntan qué criterios entran en mi consideración cuando estoy pensando en la arquitectura de un sistema, diré que en primer lugar la experiencia.

En segundo lugar, tomaré en cuenta las necesidades del cliente, así como las tecnologías que este mismo impone. Ocurre a menudo que el negocio ya trabaja con ciertos sistemas y es nuestra responsabilidad adaptarnos a ellos, o simplemente que existen preferencias en uno u otro sentido.

Y en tercer sitio pondría las mejores prácticas de los sistemas distribuidos como las expuse arriba. Debo subrayar que soy amigo de dichos principios. En efecto, no es necesario inventar el hilo negro cuando los sistemas distribuidos han probado una y otra vez sus fortalezas. Mi punto es sencillamente que esos principios se aterrizan por medio de la experiencia, a su vez construida con la práctica, y lo que el cliente busca.

Sin duda, la tecnología puede ser escalable, con todos los beneficios que ello implica. La guía la dictan el requerimiento y lo aprendido anteriormente.