Category Archives: Quality Attributes

Cómo integrar los requerimientos de DBAs y Admins a las decisiones de diseño de una solución

En este post voy a tratar brevemente sobre qué podemos hacer para asegurarnos que los requerimientos de DBAs y Admins están adecuadamente cubiertos por las decisiones de diseño de una solución, en equilibrio con una adecuada cobertura de los requerimientos de los demás stakeholders de dicha solución.

Los puntos principales de este post son los siguientes:

  • Los DBAs y Admins también son stakeholders de primer nivel de una solución
  • Los requerimientos de DBAs y Admins suelen “asomar” a través de los requerimientos no funcionales de la solución
  • Pensar en cómo automatizar el deployment de la solución desde el comienzo
  • Incorporar metodologías como DevOps para mejorar la integración con DBAs y Admins en los deployments

Los DBAs y Admins también son stakeholders de primer nivel de una solución

Un problema frecuente que se presenta en la documentación de requerimientos es que resulta poco probable que los usuarios clave entrevistados por los analistas funcionales tengan presentes los requerimientos de los DBAs y de los Admins y los describan con suficiente detalle.

En suma, los requerimientos de los DBAs y Admins pasan a engrosar la lista de los requerimientos “invisibles” de la solución en cuestión: son todos aquellos requerimientos que no tienen un “vocero” que los saque del anonimato, a tiempo.

Lamentablemente, este es un hecho muy frecuente, y un abrumador porcentaje de las soluciones existentes tiene su lista de requerimientos “invisibles”, que típicamente incluye a los requerimientos de los DBAs y Admins.

Un elemento que contribuye a que los requerimientos de los DBAs y Admins sean “invisibles” es que la gran mayoría de los usuarios no comprende de qué forma puede comprometer seriamente la correcta operación de la solución si los requerimientos de los DBAs y Admins no están adecuadamente cubiertos.

Qué podríamos hacer para mejorar esto ?

Existe una alternativa de resolución muy simple: que el arquitecto sea el que “saque del anonimato” a los requerimientos de DBAs y Admins, junto con otros requerimientos “invisibles” importantes.

Una forma apropiada para hacer esto es que el arquitecto le sugiera a los analistas funcionales como orientar las preguntas de requerimientos en general, y en particular, sobre los no funcionales.

Los requerimientos de DBAs y Admins suelen “asomar” a través de los requerimientos no funcionales de la solución

Ciertamente, los requerimientos de los DBAs y los Admins no son “completamente invisibles”, más bien, son altamente “transparentes”, ya que estos requerimientos suelen “asomar” en forma velada o indirecta a través de los requerimientos no funcionales que los usuarios normalmente describen.

Por diversas razones, tanto prácticas como técnicas, los arquitectos preferimos agrupar los requerimientos de una solución en categorías que se denominan Quality Attributes.

Consideremos brevemente algunos Quality Attributes (QAs) relevantes que suelen “hacer visibles” a algunos de los requerimientos de DBAs y Admins:

  • Performance
  • Escalabilidad
  • Seguridad
  • Alta Disponibilidad/Disaster Recovery (HA/DR)
  • Mantenibilidad
  • Administrabilidad

Veamos un ejemplo sobre como algunos requerimientos de seguridad pueden “hacer visibles” a requerimientos importantes de DBAs, Admins y otras áreas.

Supongamos que un documento de requerimientos de una solución dice algo similar a lo siguiente:

“Esta solución Web debe ser Internet Facing, dado que debe soportar tanto a usuarios de Intranet como a usuarios de Extranet”

Esta sola frase remite a requerimientos de los DBAs, de los Admins y de Seguridad Informática.

Repasemos brevemente las implicancias que esta frase tiene en las decisiones de diseño para que la solución cubra adecuadamente los requerimientos de DBAs, Admins y Seguridad Informática que “asoman”.

Los Web Front End servers de esta Web Application deben estar en la DMZ o red perimetral, dado que la Web Application en cuestión es Internet Facing.

Dado que la DMZ es una “zona no segura”, la DMZ no puede alojar ni a la capa de lógica de negocios ni a la capa de acceso a datos: solamente debería estar la capa de presentación de la Web Application en la DMZ.

Los requests y responses de los RPCs desde el código de la capa de presentación de la Web Application a la capa de lógica de negocios deben pasar a través de un firewall, por lo tanto, dichas invocaciones deberían estar “montadas” sobre el protocolo HTTP/HTTPS para ser viables.

Queda claro que la arquitectura típica presente en una cantidad importante de Web Applications existentes no es capaz de cumplir con las condiciones y requerimientos mencionados.

Por lo tanto, tal vez sea necesario revisar algunas de las decisiones de diseño que comúnmente se toman en Web Applications para que puedan cubrir estos requerimientos importantes de seguridad en forma adecuada.

En cuanto a los QAs de Mantenibilidad y Administrabilidad, podemos repasar brevemente como la forma en que registramos las excepciones arrojadas por la solución tienen implicancias cruzadas en ambos QAs.

Para los DBAs y Admins, sería conveniente que la solución registre las excepciones en el event log de cada server donde las mismas emergen, mientras que para el equipo de production support que ha de dar soporte (bug fixing e implementación de cambios de requerimientos) a la solución en producción, sería conveniente que la solución registre las excepciones en archivos de log en directorios de red a los que ellos tengan acceso.

Es importante destacar que el equipo de production support tal vez necesite que estos archivos de log registren detalles adicionales de las excepciones que serían un “exceso de información” para los DBAs y Admins, por lo tanto, las decisiones de diseño deberían cubrir en forma adecuada y equilibrada las diferencias en los detalles de información de excepciones a registrar para estos dos grupos.

En relación con el QA de Alta Disponibilidad/Disaster Recovery (HA/DR), debemos contemplar que si bien como primera aproximación es aceptable decir que las implementaciones de alta disponibilidad que soportan medidas de failover automático (como Failover Clustering y Database Mirroring, o las diversas configuraciones de AlwaysOn, en SQL Server) son transparentes a la lógica de los sistemas de información que las usan, lo correcto sería verificar con pruebas de carga con volúmenes y picos de transacciones comparables a los reales el grado de aumento de la latencia en las transacciones, debido a los procesos adicionales necesarios para el soporte de Alta Disponibilidad.

En suma, podemos encontrar que los requerimientos de todos los QAs mencionados tienen diversas y serias implicancias a nivel de las decisiones de diseño que permitan dar una cobertura apropiada a las requerimientos de DBAs y Admins que se desprenden (se “hacen visibles” a través) de dichos QAs.

Tarde o temprano, las decisiones de diseño que debemos tomar para dar adecuada y balanceada cobertura a todos los requerimientos derivan en una arquitectura distribuida, como una diversa cantidad de componentes a instalar en diversos servers.

No hay nada de malo en una arquitectura distribuida con diversos componentes a ser instalados en una serie de servers: es cierto, en sí mismo, no tiene nada de malo, pero debemos contemplar algunas de sus consecuencias.

Por ejemplo, un proceso manual de instalación y configuración de estos diversos componentes en diversos servers no es lo más recomendable, dado que podría ser propenso a diversos errores de instalación y/o configuración no evidentes (errores de instalación y/o configuración que no arrojan mensajes de error durante el proceso manual de instalación, configuración y prueba).

Para eliminar o mitigar la ocurrencia de este tipo de errores, es conveniente que contemos con procesos automáticos de deployment de los diversos componentes de la solución.

Pensar en cómo automatizar el deployment de la solución desde el comienzo

Ya hemos visto muy brevemente que debemos considerar con mucho detenimiento las decisiones de diseño que tomamos para asegurar una adecuada y equilibrada cobertura de todos los requerimientos de una solución, y además, hemos visto que las decisiones de diseño que tomamos tienen implicancias que afectan a estos requerimientos (por ejemplo, ya vimos como una arquitectura distribuida tiene implicancias en el deployment de la misma).

Por lo tanto, es necesario que empecemos a pensar en los procesos automáticos de deployment de la solución desde las etapas tempranas del diseño y del desarrollo, dado que si dejamos esto para el final, corremos el riesgo de descubrir (tarde) que algunas decisiones de diseño no “suman” a la automatización del deployment.

Es importante destacar que esto no implica trabajo adicional, sino que tan solo cambiar la decisión de que tan temprano se empieza a diseñar y desarrollar el proceso de deployment automático de la solución.

Para un equipo de desarrollo que utiliza Agile, debería ser algo bastante natural usar métodos automáticos de deployment.

Una de las prácticas de Agile es tener builds frecuentes durante la ejecución de una iteración o Sprint, como mínimo, en la medida de lo posible, un build diario, aunque sería mucho mejor si el equipo pudiese implementar un proceso de continuous delivery: poder realizar un build a pedido en cualquier momento, y si el mismo es exitoso, a continuación hacer un deployment automático a un entorno en particular de todos los componentes actualizados, recién generados en el build.

En sí mismo, para poder realizar un build a pedido, es necesario automatizar una serie compleja y larga de tareas, que incluyen procesos automáticos de copia coordinada de archivos a determinados directorios de red, junto con la invocación automática (y también coordinada) de determinados procesos (ejecución de procesos de verificación de estilos y standards de programación, ejecución de procesos automáticos de unit testing, ejecución de procesos automáticos de compilación y linking, etc.)

Los equipos de desarrollo Agile suelen usar determinadas tools open source para automatizar builds e integrations, tales como Ant o NAnt.

Por su parte, los DBAs y los Admins suelen usar tools como Perl, Python o PowerShell para automatizar procesos de administración.

Es altamente recomendable que los procesos automáticos de deployment, que han de ser ejecutados por los DBAs y Admins, estén desarrollados con las tools que los DBAs y Admins acostumbrar usar.

Por lo tanto, es altamente recomendable que el equipo de desarrollo adquiera la experiencia necesaria para desarrollar con fluidez en Perl, Python, PowerShell u otra tool, según corresponda.

Queda claro que tanto para el equipo de desarrollo como para el equipo de DBAs y Admins será de mucho valor agregado buscar formas de integrar el trabajo en conjunto que deben realizar.

Incorporar metodologías como DevOps para mejorar la integración con DBAs y Admins en los deployments

Qué podemos hacer para mejorar la integración del equipo de desarrollo con el equipo de DBAs y Admins?

A priori, esto parecería ser algo complicado de lograr, dado que, típicamente, el equipo de desarrollo usa procesos como Agile, por ejemplo, mientras de los DBAs y los Admins usan procesos como ITIL, por ejemplo.

A pesar que estos dos tipos de procesos parecerían presentar dificultades de reconciliación para poder pensar que sería posible tener procesos integrados, en realidad, es una tarea menos complicada de lo que parece, e inclusive, existen metodologías exitosas que permiten integrar los procesos de ambos equipos para aquellas tareas que deben diseñar e implementar en forma conjunta y coordinada.

Una de tales metodologías es DevOps

(para más detalles, ver definiciones y tools)

Como cierre, les dejo dos ideas para reflexionar:

“Los arquitectos debemos entablar un diálogo fluido, cordial y frecuente con los DBAs y Admins, de tal forma que seamos ‘todos juntos contra el problema’, en vez de ‘estar enfrentados por el problema’”.

“Si hemos de desarrollar soluciones que tengan a SQL Server como repositorio de persistencia, los arquitectos debemos ampliar tanto el alcance como la profundidad de los conocimientos que tenemos sobre las diversas capacidades que soporta esta herramienta”

Saludos, GEN

Advertisements