La importancia de los requerimientos no funcionales — Diseño de arquitecturas
Al momento de desarrollar una nueva arquitectura se deben considerar el mayor número de aspectos que nos ayude a decidir sobre las mejores tecnologías, lenguajes de programación y estrategias a implementar en la propuesta de la arquitectura, son las startups el mejor acercamiento a las nuevas tecnologías, ya que estas necesitan competir con grandes empresas y lo necesitan hacer de forma inmediata, esta guía te ayudará si vas empezando en el diseño de arquitecturas ó simplemente para complementar el conocimiento que ya tienes sobre el desarrollo del mismo.
Primero vamos hablar sobre la importancia de tener una buena arquitectura de software, La arquitectura de la solución es vital para cualquier industria y su solución. En ausencia de una arquitectura de solución, existe la posibilidad de que el desarrollo de software falle; los proyectos pueden retrasarse, superar el presupuesto y no ofrecer suficientes funcionalidades. Este escenario se puede mejorar drásticamente creando una arquitectura de solución y aplicando experiencia y conocimiento; todos los cuales son proporcionados por un arquitecto de soluciones (Hablaremos de estos roles en un post siguiente). Ayuda a mantener a las partes interesadas de todas las áreas, desde las funciones comerciales no técnicas hasta el desarrollo técnico, en la misma página, lo que evita confusiones, mantiene el proyecto encaminado dentro del cronograma y el tiempo, y ayuda a obtener el máximo retorno de la inversión (ROI).
Una buena arquitectura de solución establece especificaciones con una solución bien definida, lo que nos ayuda a entregar y lograr el producto final, junto con una operatividad fluida del producto después del lanzamiento. Un solo problema puede tener múltiples soluciones y cada solución tiene sus limitaciones. La arquitectura de la solución considera todas las soluciones y encuentra la mejor mediante la creación de una prueba de concepto práctica que se adapta a todas las limitaciones comerciales y técnicas.
Ahora bien, ¿Qué son los requerimientos no funcionales y para que nos sirven?, En ingles llamados non-fuctional requirements (NFRs), son aquellos requerimientos que “aparentemente” deberían ser parte de la solución, este tipo de aspectos pueden ser críticos para la solución y los podemos subdividir en:
- Seguridad
- Disponibilidad
- Problemas de latencia
- Mantenimiento
- Registro
- Enmascaramiento de información confidencial
- Problemas de rendimiento
- Confiabilidad
- Mantenibilidad
- Escalabilidad
- Usabilidad
- Etc…
Como podemos ver, pueden ser muchos los requerimientos no funcionales que pocas veces solemos incluir y definitivamente esto tiene que ver de acuerdo al proyecto, en algunas ocasiones no será necesario agregar a la solución todas las consideraciones.
La arquitectura de la solución debe considerar múltiples atributos y aplicaciones de diseño, ya que una misma solución puede tener un gran impacto en numerosos proyectos de una organización y esto nos exige una evaluación más cuidadosa de las diversas propiedades de la arquitectura y así lograr un equilibrio.
Hablemos solo de algunos atributos en este post:
Escalabilidad y elasticidad: Es uno de los primeros factores que debemos tomar en cuenta al momento de diseñar una solución, la escalabilidad significa darle a un sistema la capacidad de manejar cargas de trabajo crecientes y puede aplicarse a múltiples cada como es el webserver, aplicaciones y base de datos.
Por otro lado la elasticidad es que no solo podamos agregar un número determinados de recursos a nuestra solución, si no que esta pueda incrementar y decrementar de acuerdo sea la necesidad con la finalidad de ahorrar costos, esto es adoptado especialmente en el diseño de arquitecturas de las nubes públicas las cuales proveen módulos sencillos para implementar esta funcionalidad a nuestras aplicaciones.
¿Qué tipos de escalamiento tenemos?
Horizontal: Es el más cómodo y popular, además de ser económico en la última década y se refiere a la función de replicar un servicio y ser balanceado para soportar grandes cargas de trabajo.
Vertical: Esta técnica ha sido usada por largo tiempo, es cuando agregamos computo adicional como almacenamiento (storage) o memoria de procesamiento a nuestro servidor, esto es que si nosotros definimos que nuestra aplicación en un primer inicio funcionario con 2 vCPU y 4 núcleos, solicitemos que estos parámetros sean incrementados de acuerdo a una matriz de aprovisionamiento en caso de tenerla.
Un ejemplo de este tipo de actividad, es en el caso de México en temporada de E-commerce alto como ( Buen fin) ó en otros paises como Black Friday, las empresas que han contrado o tienen equipo físico y sus aplicaciones on-premise deberán prevenir este cambio significativo de trafico por lo menos 2 o 3 meses antes, ya que tienen que hacer un proceso de transición en sus servidores, en cambio realizar este tipo de actividad en la nube publica es muy fácil.
Veamos como se ve un ejemplo de escalamiento aplicado en AWS.
Alta disponibilidad y resiliencia: Es normal que lo único que la organización/negocio no quiere pasar es por un downtime de sus servicios, El tiempo de inactividad puede provocar una serie de problemas económicos, confianza en los usuarios y en la empresa, por lo cual preocuparnos de la alta disponibilidad será uno de los temas más importantes a atender dentro de los NFRs, el alta disponibilidad depende de los requisitos de la propia aplicación, no es lo mismo una aplicación en producción con miles de usuarios conectados a una aplicación interna que podria tener un tiempo de tolerancía para este tipo de escenarios críticos.
Para tener una arquitectura de alta disponibilidad, es mejor planificar las cargas de trabajo en ubicaciones aisladas del centro de datas, para que si esto ocurre una replica de la aplicación pueda operar desde otra ubicación.
Regularmente este tipo de estrategias suelen realizarse en diferentes zonas de una región para la nube publica o en diferentes data centers , los cuales se encontrarán replicando el contenido de la zona activa y en caso de caída de una zona, la zona disponible pueda tomar la operación de estos servicios.
La resiliencia es que la aplicación pueda recuperarse sin intervención humana, esto se puede lograr con el monitoreo constante de los servicios, el balanceador de carga puede monitorear los servicios activos y el estado de la instancia, si por alguna razón el balanceador de carga no recibe un estatus ok de la instancia podría solicitar la eliminación y creación nuevamente, esto es parte de lo que hablamos como escalamiento horizontal.
Fallo a tolerancia y redundancia: La tolerancia a fallas consiste en manejar la capacidad de carga de trabajo si ocurre una interrupción sin comprometer el rendimiento del sistema. Una arquitectura completamente tolerante a fallas implica altos costos debido a una mayor redundancia (Quiere decir que tendremos que agregar más componentes a nuestro diseño de arquitectura).
Cómo hemos visto esto es solo un poco de las consideraciones de deberemos tomar en cuenta para el diseño de aplicaciones, tomando en cuenta los requerimientos no funcionales, sin dudas un segundo post valdrá la pena para agregar un par de atributos necesarios a las arquitecturas orientadas a alta disponibilidad.
