La arquitectura de las aplicaciones o soluciones en la nube no requieren del uso de tecnologías concretas, esta debe ser totalmente agnóstica sobre el uso de tecnologías, para poder diseñar una buena arquitectura de aplicaciones en la nube podríamos tomar en cuenta los siguientes puntos:
- Bajo acoplamiento
- Posibilidad de escalar
- Alta disponibilidad
- Recuperación ante fallos
- Mantenibilidad
para llegar a cumplir estos atributos de calidad Microsoft nos propone 6 estilos de arquitectura las cuales se aplican dependiendo del problema a resolver o la complejidad de las mismas, a continuación mencionare algunas con sus características a tomar en cuenta y en que casos se pueden usar
N Niveles:
Esta es la arquitectura mas tradicional y usada actualmente en aplicaciones empresariales, el enfoque principal, como en todo es dividir la aplicación en capas y cada capa solo puede comunicarse con su antecesor mas próximo.
¿Es funcional?, si por supuesto, el tema aquí es la dependencia ya que al solo comunicarse con su capa antecesora mas próxima, los cambios que se realicen en cada nivel pueden implicar cambios en las demás capas que dependen de esta, trayendo consigo una seria de complicaciones de escalamiento y la mantenibilidad si crece demasiado la solución.
Web-Cola-Trabajo:
Al igual de la arquitectura en niveles, esta dividida en capas, sin embargo la diferencia aquí es que existirá una capa front la cual se encarga de de encolar trabajos a un sistema de colas las cuales pueden ser o no tareas de larga duración, una vez que termina el trabajo el sistema front de comunica asíncronamente con el trabajo, obteniendo así el resultado del proceso o trabajo solicitado en un principio.
¿Es funcional?, claro sin duda, sin embargo para dominios complejos es posible que sea difícil administrar los recursos de nube necesarios para que funcione en optimas condiciones, se debe tener en cuenta que para soluciones de tiempo real quizá esta no sea la opcion mas optima.
Microservicios:
Para dominios complejos es necesario orquestar de una manera eficiente las actualizaciones y procesos de la solución y esto implican varias cosas, tanto el funcionamiento de la solución como las actualizaciones y despliegues.
Con una aplicación de microservicios tenemos el escenario en el cual la aplicación se divide en servicios independientes, cada servicio tiene una única responsabilidad y los servicios tienen bajo acoplamiento, es decir la comunicación es a través de API, esta división permite que tengamos equipos distribuidos de desarrollo enfocados en pequeñas soluciones que en conjunto resuelvan el caso de uso o feature que se solicita.
aquí quiero hacer una mención sobre la cultura DevOps, esta cultura no es propia de microservicios
¿Es funcional?, en efecto sin embargo el mantener microservicios no es fácil, mas si no se tiene una arquitectura de software limpia como Clean Architecture o DDD, además de mantener la orquestación ya sea el AKS o Service Fabric, solucionamos un reto pero entramos a otros 5 sin embargo empoderamos mucho nuestra solución con los microservicios, ojo este estilo en definitiva no es para aplicaciones pequeñas.
Arquitectura basada en eventos:
Esta arquitectura utiliza un modelo basado en publicación-suscripción, en este modelo hay productores que publican eventos, y consumidores que se suscriben a ellos, estos productores por lo regular suelen ser independientes de los consumidores, por lo regular como con todas las grandes aplicaciones, es necesario desacoplar algunos componentes, y para comunicar ciertos componentes el algunos casos de uso podemos utilizar este estilo, ya sea que se procesen una gran cantidad de datos o sean soluciones IoT podemos considerar esta una opción de arquitectura para nuestras aplicaciones utilizando servicios de Azure como Event Grid o Service Bus de Azure.
Big Data y Big Compute
Todas las aplicaciones generan datos, y como siempre cuando trabajamos con aplicaciones algunas veces pensamos en el presente y mediano plazo pero algunas veces no tomamos en cuenta que las aplicaciones casi siempre generan grandes volúmenes de datos, dependiendo el contexto y objetivo de la aplicación, ahora para casos donde la manipulación y presentación de la información es importante, entonces debemos echarle un ojo a este estilo. Este estilo puede ser muy adecuado para perfiles de big data, por ejemplo para dividir un conjunto de datos muy grande para procesarlo y analizarlo, y para eso necesitamos procesar en paralelo toda la información, entonces podríamos generar batch de trabajo con algunos puntos de comunicación en tiempo real para que podamos extraer y analizar los datos lo mas pronto posible usando por ejemplo servicios de Azure como Azure Data Factory o algún otro, según lo requiera nuestro cliente.
Como verán es necesario conocer lo mas precisamente posible que necesita nuestro cliente, para con ello idear y elegir un estilo de arquitectura adecuado para que con ello le simplifiquemos la visa a nuestro cliente y a nosotros ya que minimizaremos al máximo el riesgo de error y de problemas al implementar la solución.
Espero les sirva y dejen sus comentarios para seguir mejorando, comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!
Top comments (0)