DEV Community: Ricardo Josue Perez Altamirano

Preguntas clave antes de implementar microservicios con .NET

Ricardo Josue Perez Altamirano — Fri, 10 Mar 2023 20:58:18 +0000

Que tal amigas y amigos como están, regresando a los artículos el día de hoy platicaremos acerca de microservicios y partimos de que los microservicios no solo es poner aplicaciones o pedazos de aplicación sobre contenedores, una arquitectura de microservicios va mas allá, una arquitectura de microservicios es un enfoque para crear una aplicación de servidor como un conjunto de servicios pequeños, eso quiere decir que los microservicios están enfocados directamente al back-end. Esto no quiere decir que su lógica de diseño no pueda ser aplicada en otros contextos o ambientes pero la implementación en este caso es para aplicaciones de back-end.
Con microservicios cada servicio debe ejecutar su propio proceso y se comunica con otros procesos, esta comunicación puede ser síncrona o asíncrona. para poder mejorar la posibilidad de éxito de una arquitectura de microservicios hay que diseñar muy bien basándose en el dominio (reglas de negocio) y separados en contextos delimitados, ¿Te suenan estos términos?, ¡si!, estoy hablando de Domain Driven Design (DDD) pero no todo es DDD, recordemos que DDD es una arquitectura de software basada en arquitecturas limpias, tal como Clean Architecture o la arquitectura Hexagonal.

Pero ¿por que es importante una arquitectura de este estilo?, porque para estas arquitecturas el enfoque principal es enfocar la solución de software a las reglas de negocio y que estas mismas son lo mas importante de la solución de software y no tienen dependencia alguna, esta independencia disminuye el acoplamiento con otros componentes o librerías que son ajenos a las reglas del negocio y con esto mejoramos la escalabilidad, extensibilidad y mantenimiento de la solución de software, y esto, ¿Qué tiene que ver con microservicios?, bueno pues todo, ya que cuando estamos definiendo una arquitectura de nuestra aplicación casi el 99% de las veces uno de los principales atributos de calidad es escalabilidad, extensibilidad , mantenimiento de la solución, disponibilidad entre otros.
Esto lleva a otra pregunta clave al momento de decidir microservicios, ¿La solución de software es lo suficientemente grande para implementar microservicios?, ¿Son realmente necesarios?. Bien la respuesta a estas ultimas 2 preguntas depende directamente del problema a resolver pero solo como un parámetro podríamos hacer un pequeño análisis para definir algunas cuestiones:

Dominio
Aquí es analizar cuales son las reglas de negocio y que tan críticos son los procesos por ejemplo ¿que impacto tienen las reglas de negocio de la aplicación en la organización?, ¿es un impacto económico u operativo?, ¿que pasaría si alguna de las reglas de negocio no estuviera bien implementada?, si hubiera cambios operativos o de reglas ¿que tan facil deberia ser el intercambio o actualización de estas reglas?,¿son reglas de negocio cambiantes?, ¿Qué tan fragmentadas con las reglas de negocio en cuanto a contextos?, ¿Qué operación del negocio esta relacionada directamente con la aplicación?
una vez definidas y respondidas estas preguntas quizá podríamos subir al siguiente nivel en nuestro análisis.

Diseño de aplicación
Aquí ya podemos empezar a tocar temas de .NET, versiones de .NET, de preferencia versiones LTS para poder aguantar un poco las actualización o siempre mantenerse actualizados a la versión de .NET que este en este momento del diseño, patrones de desarrollo para reutilizar componentes, frameworks o librerías en .NET para no empezar todo desde cero, todo esto depende totalmente del arquitecto de software en la parte del diseño y la experiencia del equipo de desarrollo en la parte de implementación. Este diseño debe considerar la comunicación entre componentes ya sean microservicios o componentes desacoplados los cuales deben cumplir con el principio como tal de la arquitectura limpia que elijamos y de los microservicios que es la autonomía.
Un punto mas aquí que hay que mencionar son los atributos de calidad, es decir ¿Cuánta disponibilidad, escalabilidad, elasticidad quiero en la aplicación? ya que la respuesta a esta pregunta será base para definir la infraestructura que llevara nuestra solución de desarrollo de software

Infraestructura:
En este punto ya podemos pensar en protocolos de comunicación HTTP o AMQP, el sistema manejador de base de datos ya sea SQL Server, MySQL, Postgresql, también en un proveedor de nube como Azure y con ello poder usar algún servicio de contenedorizacion y administración de contenedores como Docker y Azure Kubernetes Services(AKS) y eso con preguntas como ¿Cuánto es el presupuesto?, ¿Qué tecnología se adapta a mis atributos de calidad en cuanto a escalabilidad, disponibilidad, etc.?, ¿Cuál es la experiencia del equipo de implementación para estos servicios?, ¿Es posible implementar DevOps para mejorar y dar calidad al proyecto de desarrollo?

Como ven creo yo son pocas preguntas pero créanme cuando les digo que derivado de las respuesta de estas preguntas saldrán más, estas preguntas son solo el comienzo para el diseño y creo que es fundamental empezar con estos cuestionamientos si queremos implementar una arquitectura de microservicios en nuestra solución, aquí te invito a compartir si tu llevaste algún plan o preguntas diferentes a que los compartas en los comentarios para poder ayudar a otros compañeros que están el el dilema de si implementar microservicios o no.

Déjame tus comentarios y debatamos acerca de esto, seria genial tu apoyo compartiendo este articulo y comentándome que te parece esta serie de artículos.

Comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!

Twitter
YouTube
Facebook
Linkedin

Modelos de arquitectura multi tenant para Azure (Parte 2)

Ricardo Josue Perez Altamirano — Tue, 13 Dec 2022 07:55:31 +0000

Como veníamos platicando en la parte 1 de este articulo, la arquitectura de la solución puede influir en las opciones que se tiene disponibles para el aislamiento. Por ejemplo, imaginemos en una arquitectura de la solución de tres niveles

1) El nivel de interfaz de usuario, puede ser una aplicación web multi tenant compartida y todos los inquilinos accedan a través de un nombre de host único.

2) El nivel intermedio puede ser una capa de aplicación compartida con colas de mensajes compartidos.

3) La cola de datos podría ser bases de datos aisladas o contenedores de blobs

sea cual sea la opción, es importante considerar la posibilidad de combinar o en si caso hacer coincidir diferentes niveles de aislamiento en cada nivel. La decisión de este aislamiento tendrá distintos criterios de aceptación como lo serán:

1) Coste
2) Complejidad
3) Requisitos de los clientes
4) Numero de recursos

Modelos de tenant comunes

Ya teniendo los requisitos analizados y evaluados podremos considerar algunos de los patrones de implementación para sistemas multi tenant.

1) Implementaciones automatizadas de tenant único:

En este modelo se implementa un conjunto dedicado de infraestructura para cada tenant, la aplicación es responsable de iniciar y coordinar la implementación de los recursos de cada tenant.
Estas soluciones hacen un uso extensivo de la infraestructura como código o de las api de Azure Resource Manager. Este enfoque es bueno cuando necesitamos aprovisionar infraestructuras completamente independientes de cada uno de los clientes.

Una de sus principales ventajas es que los datos están completamente aislados para cada tenant, lo que reduce considerablemente el riesgo de inconsistencia de información o perdida accidental.
Uno de los riesgos es que su rentabilidad es baja, ya que no se comparte la infraestructura entre los tenant y eso puede abrir la puerta a que los tenants puedan tener gastos excesivos.

2) Implementaciones totalmente multi tenant

Ahora podemos considerar una implementación completamente multi tenant en donde si se comparten todos los componentes.
Solo se tiene un conjunto de infraestructura para implementar y mantener, y todos los inquilinos la usan.

Una de sus ventajas de esta implementación es el coste, ya que se utiliza una solución con componentes compartidos, incluso si se llegara a requerir implementaciones con SKU superiores, seguirá siendo para todos los tenants.
Unos de los riesgos es la consistencia de la información ya que no se debe filtrar datos entre tenants , aquí es probable que se apliquen técnicas de administración y particionamiento de datos además de pensar en como actuar o que pasara si un tenant requiere de algún ajuste especifico y como afectara a los demás tenants.

3) Implementaciones con particiones verticales

No es todo o nada, ahora con esta implementación podemos considerar la posibilidad de crear particiones verticales de algunos tenants, por ejemplo:

podemos usar una combinación de implementaciones de tenant único con multi tenant para clientes que necesiten mayor rendimiento o con características particulares.
podemos implementar varias instancias de la solución geográficamente y un tenant puede estar en una área geográfica especifica.

Una de las ventajas sigue siendo el compartimiento de la infraestructura y que toma ventajas de los modelos de implementación anteriores.
Un riesgo es que ahora hay que hacer énfasis en el código ya que la arquitectura de ese código debe estar diseñada para soportar implementaciones generales o especificas

4) Implementaciones con particiones horizontales

Es posible también considerar este tipo de implementaciones ya que esto implica tener componentes compartidos y como hemos visto es una mejora considerable tomando en cuenta los riesgos del compartimiento de la infraestructura.

Una de las ventajas es que se pueden mitigar problemas de vecinos ruidosos ya que por ejemplo al ser horizontal podemos tener en algún servidor bases de datos para diferentes clientes y cada quien utilizaría su base de datos
Un riesgo es que por ejemplo al momento de desplegar debemos tener en cuenta los parches o actualizaciones individuales para cada cliente.

ahora que ya sabemos estos puntos, debemos hacernos la siguiente pregunta.
¿Cómo probar el aislamiento?
podemos considerar el usar el servicio de Azure Chaos Studio para poder introducir errores que simulan interrupciones o problemas del mundo real y comprobar la resistencia y resiliencia de nuestras soluciones multi tenant

Excelente, has llegado al final, por hoy reflexiona, ¿Qué pasaría si en tu solución un servidor deja de funcionar?, ¿estas listo para atender esa situación?, ¿Cómo administras la información de tus clientes?, ¿ es fácil migrar de tecnologías o frameworks?

déjame tus comentarios y debatamos acerca de esto, seria genial tu apoyo compartiendo este articulo y comentándome que te parece esta serie de artículos.

Comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!

Twitter
YouTube
Facebook
Linkedin

Modelos de arquitectura multi tenant para Azure (Parte 1)

Ricardo Josue Perez Altamirano — Tue, 25 Oct 2022 06:03:48 +0000

Continuando con los post sobre arquitectura de software, en especifico arquitectura multi tenant, ahora pasaremos a diseñar una solución, para esto debemos hacer algunas definiciones:

Inquilino (tenant):
Aquí debemos definir que es un inquilino en la organización, es decir a quien se le proporciona el servicio, y para esto tenemos 2 modelos comunes:

Negocio a negocio (B2B):
Cuando los clientes son otras organizaciones, es probable que a estos clientes se consideren como inquilinos, hay ocasiones en las cuales se debe considerar tener un cliente asignado a varios inquilinos y de igual manera un es posible que un cliente necesite varias instancias del servicio, en general un inquilino tendrá mas usuarios, por ejemplo los empleados del mismo cliente serán usuarios del mismo inquilino

Negocio a consumidor (B2C):
Cuando los clientes son consumidores, es un poco mas complejo relacionar clientes, inquilinos y usuarios, en algunos casos cada consumidor suele ser su propio inquilino pero habría que tomar en cuenta si la solución la utilizaran familias o grupos de personas relacionadas, por ejemplo algún streaming de música o contenido podría ser una solución B2C.

Al definir el inquilino hay que considerar los siguientes puntos para diseñar la solución:

si los inquilinos son personas o familias , hay que enfocarse en la forma en la cual administra los datos personales del usuario, cumpliendo las normativas y leyes vigentes.

si los inquilinos son empresas, hay que enfocarse en los requisitos de cumplimiento , aislamiento, y en este punto debemos considerar un SLO (objetivo de nivel de servicio)

Bien ya sabemos que considerar pero ahora como tomo la decisión de que modelo multi tenant utilizo?. para eso considera las siguientes preguntas:

¿Cuáles son los objetivos empresariales?
¿Aceptarán los clientes todas las formas de multi tennant?
¿Cómo afectaría cada modelo de multi tenant los requisitos de cada cliente?
¿Podrá escalar la solución de un solo inquilino?
¿Qué tamaño tiene el equipo de operaciones y cuanta administración de la infraestructura puede automatizar?
¿Esperan los clientes que se cumplan los SLA o SLO?

En caso de que se espere que el negocio valla a escalar a un gran numero de clientes, será de vital importancia implementar una infraestructura compartida , en caso contrario, se necesitara mantener un parque de instancias grande en constante crecimiento y es probable que la implementación de recursos individuales en Azure para cada cliente sea algo compleja de mantener.

Implementaciones para inquilinos

Cuando pensamos en una solución multi tennant debemos poder distinguir entre inquilinos físicos y lógicos:
Una diferencia clave entre inquilinos e implementaciones es como se aplica el aislamiento. Cuando varios inquilinos comparten una única implementación, se suele confiar en el código de la aplicación y en un identificador de inquilino de una base de datos para mantener los datos separados de cada inquilino.
Cuando existen inquilinos con propias implementaciones dedicadas, por lo regular tienen su propia infraestructura, y puede ser menos importante que el código tenga en cuenta algunas operaciones multi tenant, por ejemplo cuando se recibe alguna solicitud para un inquilino especifico debe asignarla a la implementación que contenga los datos de ese inquilino

Aislamiento de inquilinos

Otra consideración importante es el nivel de aislamiento que necesita cada inquilino, para esto es importante tomar en cuenta los siguientes puntos:

1) Tener un único conjunto de infraestructura, con instancias independientes de la aplicación y bases de datos separadas para cada inquilino
2) Compartir algunos recursos comunes y a la vez, se mantienen separados otros recursos para cada inquilino.
3) Conservar datos en una infraestructura física independiente y en la nube

se recomienda pensar en el aislamiento como una continuidad y no una propiedad diferenciada, por ejemplo podemos implementar componentes que estén aislados de otros componentes dentro de la misma arquitectura, por ejemplo se muestra a continuación un diagrama para entender mejor el aislamiento:

considerando el nivel de aislamiento afectan algunos aspectos de la solucion como:

Seguridad:
Al compartir la infraestructura se debe tener especial cuidado en no utilizar datos de otro cliente y tener una base solida en la estrategia de identidad

Costo:
Es mas económico tener varios inquilinos en la misma infraestructura compartida

Rendimiento:
Si se comparte la infraestructura el rendimiento puede verse afectado al incrementar el numero de usuarios en uso de la plataforma

Reliability:
Un problema en un componente de un inquilino puede provocar una interrupción en todos los usuarios.

Se puede considerar la posibilidad de combinar los niveles de aislamiento y decidir sobre lo que se comparte y lo que estará aislado, todo depende directamente de la solución que se quiere realizar, como ya hemos comentado en artículos anteriores.

bien por hoy reflexiona, como es tu idea?, la solución se ajusta a lo que necesitas? déjame tus comentarios y debatamos acerca de esto, seria genial tu apoyo compartiendo este articulo y comentándome que te parece el inicio de esta serie de artículos y te espero en la Parte 2.

Comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!

Twitter
YouTube
Facebook
Linkedin

Diseñando soluciones Multi-tenant en Azure

Ricardo Josue Perez Altamirano — Sat, 01 Oct 2022 16:27:13 +0000

En algún punto de nuestra existencia, hemos tenido un cliente o una solución con una buena idea, algún software de contabilidad, seguimiento de trabajo, streaming de datos, redes sociales, entre otras, aquí el tema es claro, necesitamos una buena solución que sea capaz de escalar y de rendir a todos los usuarios del cliente sin ningún tipo de complicación, ya sea para usar la aplicación como usuarios o para nosotros como arquitectos el administrar cambios, desplegar nuevas versiones y administrar el sistema.
Para esto Microsoft Azure nos propone una serie de recomendaciones de arquitectura para diseñar estas soluciones, pero primero vamos a definir que es una aplicación multi-tenant.
Una solución multi-tenant es una que usan varios clientes o inquilinos. estos inquilinos son distintos de los usuarios. varios usuarios de una sola organización, empresa o grupo forman un único inquilino, como ejemplo pueden ser:

Soluciones de negocio a negocio (B2B)
Soluciones de trabajo y productos de software como (SaaS)
Soluciones de negocio a consumidor (B2C)

Consideraciones de arquitectura para una solución multi-tenant

En una arquitectura se comparten algunos o todos los recursos entre los inquilinos, y esto implica que un buen diseño de arquitectura puede marcar la diferencia en cuanto a rendimiento, eficiencia y eficacia del sistema, para llegar a este punto debemos hacernos las siguientes preguntas:

¿Cómo se define lo que es un inquilino para una solución?
¿Un inquilino corresponde a un cliente o usuario o grupo de usuarios?
¿Cómo se implementara la infraestructura para admitir el sistema y cuanto aislamiento habrá entre los inquilinos?
¿Qué modelos de precios comerciales ofrecerá la solución y como afectaran estos a los requisitos del sistema multi-tenant?
¿Cómo tiene pensado hacer crecer su negocio o solución?
¿Cómo reaccionará si escala al numero de inquilinos que espera?
¿Algún inquilino tiene requisitos inusuales o especiales?
¿Cómo supervisará, administrará, automatizará, escalará y controlará su entorno de Azure y como afectará esto al sistema?

!Wow¡ si, son muchas preguntas por responder y espero a lo largo de una serie de artículos vallamos resolviendo una por una pero por ahora permíteme comentarte algo más.

Sea cual sea tu arquitectura es esencial que comprenda los requisitos de los clientes, sobre todo si has adquirido compromisos de ventas con los clientes o si tienes obligaciones contractuales o requisitos de cumplimiento que satisfacer.

Por ejemplo, imagina que creamos una solución multi-tenant que vende a empresas del sector de servicios financieros, estos clientes tienen requisitos específicos y estrictos de seguridad por ejemplo como parte de la arquitectura se puede ofrecer una solución de firewall para acceder a recursos protegidos, y esta parte debe estar considerada dentro de la solución o por ejemplo para el control de usuarios del cliente que solución de IS podríamos utilizar.

bien por hoy reflexiona, tienes la respuesta de estas preguntas? déjame tus comentarios y debatamos acerca de esto, seria genial tu apoyo compartiendo este articulo y comentándome que te parece el inicio de esta serie de artículos.

Comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!

Twitter
YouTube
Facebook
Linkedin

Arquitectura Cloud Para Startups en Azure

Ricardo Josue Perez Altamirano — Thu, 08 Sep 2022 05:46:50 +0000

Continuando con la serie de artículos de arquitecturas en Azure, revisando documentación de Microsoft Azure me encontré con este tema que me parece importante compartirles, y parto de la siguiente pregunta ¿Cómo llevar a cabo la innovación? para esto es necesario realizar pruebas sobre algunas suposiciones para con ellas poder crecer y escalar conforme el producto o servicio evoluciona y crece en el mercado, una vez realizado esto ahora lo que sigue es que la solución escale para poder satisfacer la demanda de los usuarios finales.
Kent Beck propone un proceso de tres fases de innovación de productos de software estas son:

exploración
expansión
extracción

y estas fases se muestran en la siguiente gráfica:

1) Exploración

En este punto es empezar poco a poco, es decir poder invertir pequeñas cantidades de tiempo en diferentes ideas del producto, ya sean características o mejoras mínimas que quizá sean un poco diferentes al objetivo del producto, sin embargo esto mismo impulsará a la exploración para obtener respuestas, realizar adecuaciones y con ello poder encontrar o conjuntar una idea para el producto que sea lo mas completa posible. Esta fase requiere disciplina ya que entre tantas ideas podemos perdernos o desvirtuarnos de la idea principal y esto nos puede llevar a perder tiempo valioso, es importante realizar las definiciones con personas de negocio y con experiencia en arquitectura de soluciones tecnológicas ya que en este punto se pueden tomar decisiones arquitectónicas que faciliten y aterricen las ideas del producto que se esta diseñando.

2) Expansión

Una vez que la startup empieza a crecer gracias a la fase de exploración automáticamente caemos en la fase de expansión, en este punto es muy importante poner foco y detectar todos los elementos que puedan ser un riesgo o bloqueo para el crecimiento continuo del producto, para llegar a esto es necesario realizar un diseño básico de arquitectura que se fue creando en la fase de exploración y seguirá madurando en esta fase esto se realiza en conjunto con el arquitecto de soluciones con el objetivo de satisfacer las necesidades de todos los clientes, aquí ya entran criterios de aceptación y los atributos de calidad que el proyecto así requiera, aquí entra en juego el monitoreo y seguimiento de la solución para poder determinar los faltantes y los nuevos features.

3) Extracción

Ahora con la solución corriendo, clientes consumiendo, equipo analizando y negocio tomando decisiones hay mucho en juego, en este punto lo que sigue es mejorar, como lo comentamos en la sección anterior pero aquí se añaden algunos temas igual de críticos para el negocio como la reducción de costos, aumento de eficiencia se la solución, aislamiento y seguridad de la información de los usuarios, estos análisis se pueden realizar con toda la información generada en monitoreos, reportes o datos log generados por la solución, revisar que de todo puede ayudar a mejorar aun mas la solución y con ello continuar mejorando y escalando la arquitectura y con ello la solución. Las optimizaciones son muy buenas opciones pero hay que analizarlo bien ya sea cambio de forma de hacer las cosas o tecnologías, !hay que pensarlo frio¡ y siempre es mejor tener a algún arquitecto de soluciones para poder aconsejar y llevar a cabo la implementación y coordinación del proyecto o solución.

Y tu ¿tienes una idea de iniciar un proyecto?, ¿quieres hacer tu aplicación móvil?, ¿tienes alguna mejora de vida a través de la tecnología?, cuéntame, ¿Tienes un plan?, ¿Qué dice tu exploración?, ¿en qué fase estas?

me gustaría conocer tu punto de vista , iniciar una charla y poder aprender siempre de todos.

Espero les sirva y dejen sus comentarios para seguir mejorando, comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!

Twitter
YouTube
Facebook
Linkedin

Buenas Prácticas Para Desarrollar Aplicaciones en Azure

Ricardo Josue Perez Altamirano — Sun, 21 Aug 2022 08:52:59 +0000

Continuando con los post anteriores, después de revisar las opciones de arquitectura de soluciones y algunas propuesta de servicios viene la siguiente pregunta, ¿ ahora que procedimientos debo tomar en cuenta para realizar la implementación de mi arquitectura?
Bien, para eso Microsoft nos proporciona un compendio de buenas practicas para así en combinación de algunas o todas las practicas podamos ofrecer soluciones mas robustas a nuestros clientes, siempre preservando los atributos de calidad de nuestras soluciones, este compendio se conforma por las siguientes prácticas:

Diseño de API:
Para diseñar nuestras API debemos considerar algunos puntos estratégicos de nuestra arquitectura, ya que no solo se trata de exponer todo a través de una API, ya sea web o algún ensamblado, se trata de proveer a nuestro consumidor la funcionalidad que se necesita, y para esto nos podemos basar en implementar nuestras apis con algún patrón de arquitectura como clean architecture o DDD sobre .NET para con ello mejorar la experiencia de desarrollo y consumo por parte de nuestros clientes.

Implementación de API:
Como se menciona anteriormente una vez diseñada la arquitectura de software ahora viene la parte de la implementación, y para esto podríamos empezar a visualizar diferentes alternativas, por ejemplo si tenemos nuestra aplicación con DDD o Clean architecture tenemos la posibilidad de separar en microservicios y para eso podemos montarlo en Azure Service Fabric o Azure Kubernetes Services pero si no es necesario podríamos utilizar App services o Storage, cada que se implementa el API hay que considerar el performance, control de excepciones y el manejo de solicitudes de gran tamaño.

Escalabilidad Automática:
Una vez mas, todo parte del diseño, este es un gran reto por que nuestra solución debe ser capaz de de utilizar los recursos que se proporcionen a medida, es decir que cuando se asignen o se desasignen recursos la solución deberá ser capaz de continuar trabajando y utilizar esos mismos a demanda, para esto el runtime de .NET 6/7, etc ofrece muy buenas características para la programación y Azure provee escalado automático en muchos componentes.

Trabajos en segundo plano:
Suele pasar, siempre hay un proceso en la empresa que tarda o es necesario trabajar con lógica de negocio y muchos datos en un momento, para eso podríamos implementar trabajos en segundo plano o por lotes, por ejemplo para poder procesar grandes volúmenes de información de muchos clientes podríamos usar un Azure Streaming Analitics en conjunto con algún almacenamiento como Azure Cosmos DB, ya que podríamos desencadenar eventos o trabajar con los resultados de las tareas.

Almacenamiento en cache / Red de entrega de contenido:
El usuario lo quiere ya!, si resulta ser que tenemos estándares muy altos de respuesta, ya que nuestra aplicación con un app services básico con 5 usuarios anda genial, pero, cuando llega un golpe de 100M usuarios que pasa?, si, si sabes que pasa. Para esto en diseño de nuestra solución podríamos considerar el uso de servicios de almacenamiento en caché, esto con el fin de leer los datos con mas frecuencia pero que no se modifican constantemente, por ejemplo con Azure Redis Cache podemos dar solución a la parte de datos pero ¿Qué pasa con el contenido estático?. Para eso podríamos implementar algún CDN por ejemplo el que nos provee Azure mismos para reducir de manera considerable el tiempo de carga de los sitios web o apps que tenga nuestra solución.

Creación de particiones de datos:
La data, el corazón de las soluciones, para poder manejar grandes volúmenes de información podemos aquí empezar a pensar en que podemos tener un almacenamiento poliglota, es decir que podemos tener diferentes tipos de base de datos dependiendo el fin al que queremos, por ejemplo para nuestras transacciones podemos seguir utilizando nuestro SQL Server pero para búsquedas podríamos Utilizar un Cosmos DB , o un Data Lake para crear un DataWarehouse entre otras características. Con esto nuestro sistema de vuelve mas escalable y resiliente ante cambios de reglas de negocio u otros aspectos.

Supervisión y diagnostico:
El seguimiento es vital, necesitamos saber que pasa con nuestra aplicación en todo momento para tomar buenas decisiones de mejora de arquitectura o performance , recordemos que constantemente para mejorare nuestra solución podemos revisar algunos logs o estadísticas en tiempo real que ayudan perfectamente a revisar, analizar y decidir los siguientes features o fix bugs necesarios en nuestra solución. para eso podemos usar por ejemplo el conocido application insights para llevar un control de todo lo que pasa en nuestra aplicación.

Estrategia de reintentos:
Podemos adaptar nuestra solución para implementar mecanismos de reintento, ya sea por algún SDK de algún proveedor o nosotros realicemos esa programación, es una característica esencial para desarrollar aplicaciones y soluciones resilientes y adaptables al cambio mas cuando las carga de trabajo de nuestra aplicación es impredecible.

Bien ¿tu que opinas?, cuando desarrollas soluciones ¿Cómo lo haces?, ¿sabias de alguno de estos principios?, si los sabes ¿los aplicas? , me gustaría saber tu opinión acerca de estos puntos y como todo, no es una verdad absoluta solo es una serie de recomendaciones propuestas por Microsoft para darle calidad a nuestras soluciones en Azure.
Hasta aquí el post de hoy, espero les sirva y dejen sus comentarios para seguir mejorando, comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!

Twitter
YouTube
Facebook
Linkedin

Estilos de Arquitectura Para Aplicaciones Cloud en Azure

Ricardo Josue Perez Altamirano — Wed, 03 Aug 2022 05:13:00 +0000

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!

Twitter
YouTube
Facebook
Linkedin

Diseñando Arquitecturas Para Aplicaciones Cloud en Azure

Ricardo Josue Perez Altamirano — Wed, 20 Jul 2022 05:31:33 +0000

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

Ciclo de vida del software - SDLC para sistemas en .NET

Ricardo Josue Perez Altamirano — Sun, 10 Jul 2022 02:31:44 +0000

Que tal a todos y todas el día de hoy platicaremos sobre SDLC y como llevarlos en sistemas .NET .
El ciclo de vida del desarrollo de software (en ingles: SDLC - Systems Development Life Cycle) es una estructura que contiene procesos relacionados con el desarrollo, despliegue y mantenimiento de un producto de software.
esta estructura abarca la vida completa del software, desde la definición de requerimientos hasta la capacitación y mantenimiento.

a fin de cuentas esta metodología trata de evitar costes de errores de implementación utilizando un método que permita a todos los involucrados en el software adelantarse para mejorar los resultados del proyecto.
a continuación, en listaremos las fases del ciclo de vida y describiremos brevemente en que se enfoca cada una:

1.- Comunicación
En este momento un cliente solicita un producto de software predeterminado, y nos contacta como empresa de software para mostrar sus necesidades concretas y puede presentar una solicitud de desarrollo de software

2.- Planificación y análisis
inicia una fase de planificación incluyendo un análisis de los requisitos, estos mismos deben ser estudiados por si son ambiguos o están incompletos, se recomienda indagar a profundidad y no dar nada por hecho, siempre preguntar todo.

3.- Estudio de viabilidad
Después de verificar los requisitos, se crea un plan para procesar el software, se analiza que partes del mismo cubren los requisitos. también se verifica si es viable financiera y tecnológicamente.

4.- Análisis del sistema
hasta este punto el equipo asigna recursos y ahora se planifica tiempo de duración del proyecto, además de tratar de encontrar limitaciones del producto y si su desarrollo implica impactos sobre la organización

5.- Diseño
En esta fase ya se comienza a visualizar cual será la solución por que ya se planificaron las anteriores, en este punto entrarían las discusiones sobre que arquitectura llevara (Clean, DDD) o sobre que framework o tipo de proyecto estará (.Net Core, Blazor , Asp Net Core MVC)

6.- Codificación
También se conoce como fase de desarrollo, una vez elegida la arquitectura y el framework que llevara se procede a desarrollar el software como tal, teniendo como objetico construir la funcionalidad para poder entregar unidades funcionales, y al final de todo esto poder entregar un PMV (producto mínimo viable)

7.- Integración
En este punto se realiza la integración con sistemas, bibliotecas o bases de datos de otros proveedores

8.- Pruebas
esta fase entra en un ciclo continuo junto con el desarrollo, cada que se completa una fase de desarrollo inmediatamente se procede a probar hasta que todas las funcionalidades sean del 100%, estas pueden automatizarse con UnitTesting

9.- Integración
En este punto se instala o despliega el software y de evalúan los atributos de calidad.

10.- Capacitación/Formación
En esta fase se planifica un tiempo de adaptación del usuario, esto es vital para el proyecto ya que es importante comprobar el nivel de uso y experiencia del usuario para poder mejorar.

11.- Mantenimiento y funcionamiento
Esto no acaba aquí, lo que sigue es, con base en un monitoreo constante encontrar errores y garantizar que el proyecto siga funcionando como se espera.

y volvemos, después de este ultimo paso es posible tomar requerimientos para actualizaciones o corrección de Bugs, teniendo en cuenta el orden del ciclo, es bastante organizado y aplicable en muchos casos.

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