Hoy en día tenemos un gran reto, nosotros como arquitectos debemos proveer de soluciones a nuestros clientes, que sean optimas en cuanto a costos y resultados, debemos siempre tomar en cuenta distintos aspectos como los atributos de calidad o requerimientos no funcionales para con ello mejorar los diseños y las implementaciones de las arquitecturas de las aplicaciones que se desean migrar o crear directamente en la nube.
Existen algunos principios que propone Microsoft para que las aplicaciones que se desplieguen sobre la nube cumplan los requerimientos no funcionales de los clientes, estos principios los mencionamos a continuación:
Recuperación automática:
Debemos pensar en todo, cuando desarrollamos sistemas distribuidos, ya sean arquitecturas SOA o arquitecturas microservicios, hay que tomar en cuenta aspectos de recuperación ante desastres, sobre todo en servicios que necesitan estar 24/7 en línea y nuestro nivel de servicio es alto.
Redundancia:
Que pasa si uno de los servicios que provee la facturación o provee el registro de pedidos se cae?, como garantizamos que se cumple nuestro nivel de servicio?, exactamente, diseñando una aplicación redundante, por ejemplo ya sea con técnicas de escalamiento o geo-replicación o no centralizar funcionalidad vital en únicos lugares o instancias, debemos siempre pensar en ¿Qué pasaría si?... y nunca dar nada por hecho, ese 0.00001% puede pasar y debemos estar preparados para afrontarlo.
Minimizar la coordinación:
Esto se resume en una palabra "Concurrencia", a menudo en programación se toma muy en serio este punto ahora con la programación asíncrona es mas común pero que pasa cuando esta concurrencia es a nivel de arquitectura?, cuando diseñemos arquitectura debemos cuidar las transacciones entre los sistemas y diferentes servicios, tratando siempre que se pueda la consistencia total pero en caso que no entonces aceptar y trabajar con la consistencia eventual.
Escalado horizontal:
Como debe funcionar un software de nube "Consume lo que necesitas", es decir la aplicación que se diseñe debe estar preparada para que se puedan agregar o quitar instancias a medida que se necesite, esto con en fin de seguir garantizando nuestro nivel de servicio, ayudando así a la estabilidad de nuestra solución.
Particiones alrededor de límites:
En este punto se menciona la importancia de los limites el escalamiento vertical, ya que en la nube todos los servicios cuentan con limites y cuotas, entonces regresamos a la pregunta, ¿Qué pasaría si?... en una venta llego a mi limite de instancias de mi app service plan por ejemplo y lo complicado es que siguen llegando ventas!.
He aquí la importancia del punto anterior siempre nuestras aplicaciones deben aprovechar los recursos horizontalmente o en su defecto desacoplar la solución optando por contextos o algún diferenciador que ayude a que en todos los ambientes se tenga el performance que se necesita.
Diseñar para las operaciones:
Aquí entra mucho el quien y como se ejecutara la solución o que tipo de solución es, es decir, por cada solución siempre debe haber algún soporte de configuración para el departamento de operaciones de la empresa ya que las soluciones deben poder configurarse y actualizarse según lo requiera el departamento de operaciones y por su puesto los clientes.
Servicios administrados:
Utilizar PaaS siempre que se pueda en lugar de utilizar IaaS, esto con el fin de facilitar la administración de los recursos , con una solución PaaS toda la infraestructura queda soportada por Azure sin embargo depende esto mucho de la solución ya que algunas soluciones necesitan configuraciones especiales sobre servidores o SO específicos, recuerden siempre valorar el alcance y sobre que solución nos estamos enfrentando.
Seleccionar un buen almacén de datos:
Y venimos con la pregunta ¿Qué datos se van a guardar? ¿Cómo es mejor SQL o NoSQL? ¿Archivos o Documental? y como siempre se responde en estos casos, depende. pero aquí te recomiendo tomar en cuenta esto, realiza un mapeo completo de la solución, como esta la base de datos actual, reajusta la base de datos si es necesario y optimízala según sea el fin, ya sea para transacciones o para búsquedas, siempre toma en cuenta para que se usan los datos.
Diseñar para evolucionar:
Aunque no lo crean, implementar arquitecturas de software en un principio es complicado, pero, una vez implementadas transparentemente simbolizan ahorros en tiempo y en dinero, pero por que menciono esto.
A menudo cuando se proponen realizar refactors sobre aplicaciones los equipos de desarrollo a veces no suelen tomarlo bien y es totalmente entendible, nuestro trabajo como arquitectos es mostrarles el camino, dándoles una visualización y un panorama del plan a mediado - largo plazo para que en un futuro cuando BA pida un cambio no sea un "caray ¿Dónde esta el código que hacia esto? o el famoso ¿así me dieron el código?" en su lugar sea un:" se analizo que el cambio sea en el dominio de X sobre el componente Y e impactara a Z dependencias" , créanme en un principio es complicado pero a mediano plazo con las actualizaciones verán mejoras en sus cambios
Crear teniendo en cuenta las necesidades de la empresa:
Esto puede resumirse en "poner atención al cliente" y con esto me refiero a poner especial atención en la toma re requerimientos, no hay pregunta tonta! al contrario hay que preguntar es mas mínimo detalle y replantearnos siempre a nosotros y a nuestro cliente las diversas situaciones o casos de uso y las implicaciones que conllevan si fallan o funcionan correctamente, recuerden siempre, todo desarrollo debe estar justificado por un requisito empresarial.
Espero les sirva y dejen sus comentarios para seguir mejorando, comparto mis redes para cualquier duda, y dirían por ahi... ¡voy y vengo!

Twitter
YouTube
Facebook
Linkedin