Manos a la obra con Microsoft .NET Aspire Solution Architect

4 4 Agenda de la presentación Introducción Si nunca has visto que es, aquí tienes la introducción teórica Manos a la obra Vamos a adentrarnos paso a pasos con ejemplos

5 5 ¿Qué es Microsoft .NET Aspire? (1/2) El panorama de las aplicaciones nativas de la nube está en constante evolución, exigiendo soluciones eficientes y robustas para construir aplicaciones distribuidas. Pero gracias a .Net Aspire, un stack especialmente diseñado para simplificar el desarrollo nativo en la nube con .NET, los desarrolladores ahora tenemos una poderosa herramienta que facilita la creación de aplicaciones resilientes, escalables y listas para producción, optimizando tanto el proceso de desarrollo como el despliegue en entornos de nube. Piensa en .NET Aspire como un framework para crear aplicaciones en la nube que sean observables, listas para producción y resilientes. No es solo un framework; es un ecosistema cuidadosamente seleccionado de herramientas y patrones que nos guían durante todo el proceso de desarrollo, desde el entorno local hasta el despliegue.

6 6 ¿Qué es Microsoft .NET Aspire? (2/2) ¿Por qué elegir .NET Aspire? ▪ Orquestación Simplificada: Gestiona aplicaciones multiproyecto y sus dependencias con facilidad, evitando configuraciones complejas y configuraciones manuales. ▪ Observabilidad Integrada: Obtén información en tiempo real sobre la salud y el rendimiento de tu aplicación con telemetría y diagnósticos integrados. ▪ Resiliencia por Diseño: Las aplicaciones .NET Aspire son inherentemente robustas, capaces de manejar fallos y recuperarse de manera elegante, asegurando alta disponibilidad. ▪ Preparado para la Nube desde el Inicio: Diseñado para una integración fluida con plataformas en la nube como Azure, AWS y GCP. ▪ Experiencia Familiar en .NET: Aprovecha tus conocimientos y habilidades existentes en .NET sin una curva de aprendizaje pronunciada.

.Net Aspire es una solución integral que aborda los desafíos del desarrollo nativo en la nube, proporcionando una experiencia de desarrollo más sencilla, eficiente y robusta a los desarrolladores de .NET

8 8 Comenzando con .NET Aspire (1/11) .NET Aspire es una nueva tecnología de .NET que ofrece herramientas y bibliotecas para ayudar a crear, depurar y desplegar soluciones .NET construidas utilizando microservicios. A lo largo de la práctica veremos donde podemos ir usando.NET Aspire. Para poder trabajar vamos a necesitas la Línea de Comandos (CLI) de .NET o Visual Studio 2022, en la última actualización que tengas disponible, y .NET 8. Instalación: dotnet workload install aspire Y comprueba que esté instalado: dotnet workload list Las aplicaciones .NET Aspire están diseñadas para ejecutarse en contenedores. Al ejecutar la aplicación localmente, los proyectos se ejecutan directamente en el sistema sin necesidad de un motor Docker. Los contenedores Docker se utilizan al desplegar la solución. Pero como vamos a utilizar alguna imagen de Docker como parte de la aplicación, vamos a necesitar un contendor. En esta presentación vamos a utilizamos el contenedor más utilizado: Docker Desktop. Nota: .NET Aspire también soporta la ejecución de contenedores con Podman y Rancher.

9 9 Cuando .NET Aspire esté instalado, podremos crear un nuevo proyecto que contenga un servicio API y una aplicación cliente Blazor utilizando el siguiente comando dotnet new aspire-starter -o AspireWeatherSample Con esta plantilla, tendremos cuatro proyectos: • AspireWeatherSample.ApiService: Este proyecto contiene un servicio REST que utiliza APIs mínimas de ASP.NET Core. • AspireWeatherSample.Web: Una aplicación ASP.NET Core Blazor que envía solicitudes al servicio API. • AspireWeatherSample.ServiceDefaults: Un proyecto de biblioteca con código de inicialización compartido para todos los servicios de la solución. • AspireWeatherSample.AppHost: El proyecto de host de la aplicación define el modelo de la aplicación de la solución y cómo se conectan todos los recursos. Comenzando con .NET Aspire (2/11)

10 10 Comenzando con .NET Aspire (3/11) Ejecutamos el proyecto:

11 11 Cuando inicias el proyecto recién creado (el proyecto AppHost debe ser el proyecto de inicio como puedes observar en el indicador 1 de la imagen anterior), se abre una consola que muestra los registros de AppHost y el navegador abre un panel de control que muestra los recursos del proyecto, como puedes ver en el indicador 3 de la imagen anterior. Con el panel de control de .NET Aspire, puedes ver los recursos en ejecución (ApiService y Web), el estado de los recursos y los puntos de conexión (endpoints), además de acceder a detalles y registros. En el panel izquierdo, tienes acceso a datos de registros, trazas y métricas. Aunque el panel de control generalmente no se utiliza en entornos de producción (donde se suelen usar Prometheus, Grafana, Azure Application Insights y otros entornos), es muy útil tener toda esta información durante el tiempo de desarrollo que nos ayudará a ver el comportamiento de la aplicación (que iremos viendo a lo largo de esta presentación). Si ejecutamos en punto de conexión (en adelante usaré indistintamente endpoint) de Web podremos llegar a una aplicación ampliamente conocida por todos los desarrolladores de Visual Studio: Comenzando con .NET Aspire (4/11)

12 12 AspireWeatherSample.AppHost/Program.cs Si estás familiarizado con el patrón de construcción de aplicaciones en .NET y la clase Host para configurar el contenedor de inyección de dependencias, la configuración de la aplicación y el registro, encontrarás algunas similitudes en .NET Aspire. Aquí, se utiliza una clase DistributedApplication para crear un IDistributedApplicationBuilder mediante el método CreateBuilder. Este constructor se utiliza para definir todos los recursos necesarios para la solución. Con el código generado, se mapean dos proyectos usando el método AddProject, referenciados con un tipo genérico, por ejemplo, Projects.AspireWeatherSample_ApiService. Comenzando con .NET Aspire (5/11)

13 13 La variable apiService devuelta por el primer método AddProject se referencia con el segundo proyecto, un frontend, utilizando el método WithReference. Esto permite que el frontend acceda al servicio API. La URL del servicio API se asigna como una variable de entorno al frontend, utilizando la interfaz IResourceWithServiceDiscovery. Mientras que el servicio API no necesita ser accesible externamente (solo el frontend necesita acceso), el frontend debe ser accesible desde el exterior. Por ello, se utiliza el método WithExternalHttpEndpoints con el proyecto del frontend. Esta información de configuración se usa para especificar cómo se configura el controlador de ingreso (Ingress controller) añadido como un proxy al recurso. Comenzando con .NET Aspire (6/11)

14 14 AspireWeatherSample.ServiceDefaults/Extensions.cs Comenzando con .NET Aspire (7/11)

15 15 Este proyecto compartido contiene el método de extensión AddServiceDefaults, que implementa una configuración común para las aplicaciones de recursos. En su implementación, se invoca ConfigureOpenTelemetry, otro método de extensión definido por la clase Extensions. Aquí se implementan las partes comunes para el registro, las métricas y el rastreo distribuido, un tema que si sigues mi blog lo he tratado ampliamente y aquí solo vamos a ver lo esencial para que puedas trabajar con ello. AddServiceDiscovery utiliza la biblioteca Microsoft.Extensions.ServiceDiscovery. El método AddServiceDiscovery registra los resolutores de los endpoints de servicio por defecto. El descubrimiento de servicios se configura no solo con el contenedor de inyección de dependencias, sino también con la configuración del cliente HTTP, mediante el parámetro lambda del método ConfigureHttpClientDefaults. ConfigureHttpClientDefaults es parte de la biblioteca Microsoft.Extensions.Http. El paquete referenciado desde la biblioteca ServiceDefaults es Microsoft.Extensions.Http.Resiliency. Esta biblioteca es nueva desde .NET 8 y ofrece extensiones para la biblioteca Polly. En una aplicación distribuida, las invocaciones a veces fallan debido a problemas transitorios. Reintentar invocaciones a estos recursos puede tener éxito en un segundo intento. Esta funcionalidad está integrada en .NET Aspire con la configuración de resiliencia por defecto en AddStandardResilienceHandler. Comenzando con .NET Aspire (8/11)

16 16 AspireWeatherSample.Web/Program.cs El nombre "apiservice" proviene de la definición del modelo de la aplicación, es decir, el nombre que se ha pasado al método AddProject. Antes de los dos puntos, se puede especificar el esquema, por ejemplo, http o https. Separar esquemas con un signo + permite el uso de múltiples esquemas, siendo el primero el preferido. Comenzando con .NET Aspire (9/11)

17 17 AspireWeatherSample.AppHost/Program.cs La configuración "applicationUrl" define las URLs utilizadas al iniciar la aplicación, y este es el enlace que se usa para agregarlo a la variable de entorno. Dado que las variables de entorno forman parte de la configuración de .NET, estos valores son recuperados por el proveedor de configuración de descubrimiento de servicios. Al ejecutar la solución .NET Aspire localmente, los procesos de webfrontend y apiservice usan puertos aleatorios. Por tanto, localmente se añade un proxy inverso automáticamente antes de estos procesos, y el proxy inverso es accesible a través de la configuración de lanzamiento establecida. Con Azure Container Apps y Kubernetes ya se ofrecen características de descubriendo de servicios sin necesidad de añadir más bibliotecas de descubrimiento. Comenzando con .NET Aspire (10/11)

18 18 AspireWeatherSample.AppHost/Program.cs Desde AppHost y usando directivas out-the-box podremos, por ejemplo, usar WithReplicas(2) donde se inician 2 instancias del servicio utilizando tres puertos aleatorios y el mismo número de puerto del proxy inverso. Puedes ver 2 servicios de apiservice ejecutándose con diferentes sufijos y dos procesos con el mismo número de puerto, como se muestra en la imagen anterior. El punto de conexión definido en la configuración de lanzamiento es el del proxy inverso. Cuando abres los Detalles, puedes ver diferentes puertos de destino para cada servicio. Es el proxy inverso quien actúa como un balanceador de carga para elegir una de las réplicas. Nota: Para iniciar la solución con el perfil de lanzamiento http, necesitas agregar la variable de entorno ASPIRE_ALLOW_UNSECURED_TRANSPORT a la configuración de lanzamiento del proyecto AppHost y establecerla en true. Comenzando con .NET Aspire (11/11)

19 19 https://github.com/jmfloreszazo/HandsOnNetAspire/tree/main/AspireWeatherSample Comenzando con .NET Aspire: Demo

20 20 Componentes de .NET Aspire (Parte I) (1/2) Las componentes de .NET Aspire son un conjunto de paquetes NuGet específicamente seleccionados para facilitar la integración de aplicaciones nativas de la nube con servicios y plataformas prominentes, como Redis y PostgreSQL. Cada componente ofrece funcionalidades esenciales a través de aprovisionamiento automático o patrones de configuración estandarizados. Aunque se pueden utilizar sin un proyecto anfitrión (orquestador), están diseñados para funcionar mejor con el anfitrión de aplicaciones de .NET Aspire. Es importante no confundir los componentes de .NET Aspire con los paquetes de hospedaje de .NET Aspire, ya que tienen propósitos diferentes. Los paquetes de hospedaje se utilizan para modelar y configurar varios recursos en una aplicación de .NET Aspire, mientras que los componentes se usan para mapear configuraciones a diversas bibliotecas cliente. Los componentes de .NET Aspire facilitan el uso de características y servicios de Microsoft y terceros dentro de las aplicaciones configuradas. Por ejemplo, Azure Cosmos DB o SQL Server son componentes disponibles para acceder a bases de datos, y RabbitMQ, Apache Kafka o Azure Service Bus son componentes para mensajería. Para utilizar un componente, generalmente se necesita configurar un recurso agregando un paquete NuGet. Por ejemplo, para el componente Azure Cosmos DB EF Core, se debe agregar el paquete Aspire.Hosting.Azure.CosmosDB. Posteriormente, el componente se usa añadiendo el paquete Aspire.Microsoft.EntityFrameworkCore.Cosmos al servicio que accede a la base de datos. Los componentes de .NET Aspire conocen las configuraciones necesarias para habilitar métricas de registro y otros datos, lo que facilita su configuración. Al agregar un recurso de Azure Cosmos DB al modelo de la aplicación y referenciarlo en un proyecto de servicio, la cadena de conexión se configura como una variable de entorno o se almacena en un almacén de secretos, permitiendo su acceso por el proyecto que lo necesita. Para estar al día de los componentes disponibles: https://learn.microsoft.com/es-ES/dotnet/aspire/fundamentals/components-overview?tabs=dotnet-cli&WT.mc_id=AZ-MVP-5004828

21 21 Componentes de .NET Aspire (Parte I) (2/2) A lo largo de estos manos a la obra iremos viendo alguno de ellos en los ejemplos y demostraciones.

22 22 El manifiesto (1/7) El manifiesto de .NET Aspire es un archivo en formato JSON que describe todos los recursos y dependencias de una aplicación .NET Aspire. Este manifiesto es crucial para las herramientas de despliegue, ya que proporciona una representación estructurada y detallada de cómo deben configurarse y desplegarse estos recursos, ya sea en entornos locales o en la nube. Funcionalidades Principales del Manifiesto: 1. Generación del Manifiesto: • Se genera a partir de una aplicación válida de .NET Aspire usando comandos específicos del CLI de .NET. • El archivo resultante (aspire-manifest.json) contiene una lista de todos los recursos y sus configuraciones. 2. Formato Básico del Manifiesto: El manifiesto contiene un objeto principal llamado resources, que a su vez contiene propiedades para cada recurso definido en el archivo Program.cs de la aplicación. 3. Tipos de Recursos: • Container Resources: Recursos que son contenedores, como Redis, MongoDB, SQL Server, etc. • Project Resources: Recursos que son proyectos de .NET, como servicios web o APIs. • Dockerfile Resources: Recursos definidos por Dockerfiles. • Azure Resources: Recursos específicos para Azure, como Azure Redis, Azure SQL, etc.

23 23 El manifiesto (2/7) 4. Referencias y Variables de Entorno: • Los recursos pueden tener dependencias entre sí, las cuales se especifican mediante variables de entorno y referencias dentro del manifiesto. • Ejemplo: Un frontend web puede depender de un servicio API y una caché Redis. Estas dependencias se reflejan en el manifiesto mediante variables de entorno que apuntan a las conexiones y URLs de estos servicios. 5. Campos Comunes y Específicos: • env: Mapeo clave/valor para variables de entorno. • bindings: Definiciones de cómo los recursos se conectan entre sí (esquemas, protocolos, puertos, etc.). • inputs: Parámetros de entrada específicos para ciertos recursos, como contraseñas o configuraciones adicionales. Vamos a crear una aplicación nueva de Aspire que use un componente de Redis cacha: dotnet new aspire-starter --use-redis-cache -o AspireAppWithRedisCache Entramos en el proyecto recientemente cerado y vamos a generar el manifiesto correspondiente: dotnet run --project AspireAppWithRedisCache.AppHost\AspireAppWithRedisCache.AppHost.csproj --publisher manifest --output-path ../aspire-manifest.json

24 24 El manifiesto (3/7) ¿Por Qué el Manifiesto es Importante? Despliegue Estandarizado: • Proporciona un formato estructurado y estandarizado que las herramientas de despliegue pueden interpretar y utilizar para configurar y desplegar los recursos de la aplicación de manera consistente. Interoperabilidad: • Facilita la interoperabilidad entre diferentes entornos de despliegue, ya sea en la nube o en instalaciones locales, al proporcionar una descripción agnóstica de los recursos. Automatización: • Permite la automatización del proceso de despliegue, reduciendo errores manuales y asegurando que todas las dependencias y configuraciones se manejen correctamente. Flexibilidad y Escalabilidad: • Al ser agnóstico a la nube, el manifiesto permite que las aplicaciones se desplieguen en múltiples entornos de nube con poca o ninguna modificación, proporcionando flexibilidad y escalabilidad. El manifiesto de .NET Aspire es una herramienta que simplifica y estandariza el proceso de despliegue de aplicaciones.

25 25 El manifiesto (4/7)

26 26 El manifiesto (5/7) Estructura del manifiesto Recursos y Tipos de Recursos: • container.v0: Define recursos basados en contenedores, como Redis, MongoDB, SQL Server: • type: Especifica el tipo de recurso. • connectionString: Define cómo conectarse al recurso. • image: La imagen de Docker que se utilizará. • bindings: Define cómo el contenedor se conectará a otros servicios (puertos, protocolos, etc.). • project.v0: Define proyectos de .NET, como servicios web o APIs. • path: Ruta al archivo del proyecto de .NET. • env: Variables de entorno específicas del proyecto. • bindings: Define los esquemas y protocolos para las conexiones HTTP y HTTPS.

27 27 El manifiesto (6/7) • dockerfile.v0: Define recursos basados en Dockerfiles. • azure.bicep.v0: Define recursos específicos de Azure, utilizando plantillas Bicep. • value.v0: Utilizado para recursos de tipo valor, como cadenas de conexión de bases de datos. Siendo la referencia al recurso: Y el mapeo clave/valor del entorno:

28 28 El manifiesto (7/7) El manifiesto contiene información sobre el tipo de recurso, variables de entorno, enlaces y más. Con el modelo de aplicación, también se puede especificar el uso de recursos de Azure. Este archivo de manifiesto puede ser utilizado por herramientas para desplegar la solución, por ejemplo, utilizando el Azure Developer CLI para desplegarlo en Microsoft Azure. Más adelante veremos como desplegar en Azure una aplicación. Usando Aspir8, un proyecto de código abierto, ver https://github.com/prom3theu5/aspirational-manifests, es posible desplegar la solución en un clúster de Kubernetes. También lo veremos más adelante. Como el modelo de aplicación se puede personalizar en función de diferentes perfiles de lanzamiento, podremos crear diferentes archivos de manifiesto para desplegar en, por ejemplo, Azure y usar recursos específicos de Azure y en un clúster de Kubernetes local. Es importante saber que el proyecto AppHost que contiene el modelo de aplicación se usa al iniciar y depurar el proyecto durante el desarrollo. Para el despliegue, se utiliza el manifiesto del modelo de aplicación. Cuando se ejecuta la solución en el entorno de producción, AppHost ya no entra en acción.

29 29 Project TYE ¿Cuál es la diferencia entre .NET Aspire y Project Tye? Project Tye fue un experimento que exploró el lanzamiento y la orquestación de microservicios, así como el soporte para el despliegue en orquestadores como Kubernetes. Por otro lado, .NET Aspire es un superconjunto de Tye que incluye capacidades de orquestación y despliegue, además de componentes predeterminados para integrar dependencias comunes en aplicaciones nativas de la nube. En resumen, .NET Aspire puede considerarse la evolución del experimento Project Tye. Si tienes curiosidad sobre que era Project Tye: https://jmfloreszazo.com/trilogia-sobre-modernizacion-de-microservicios/

30 30 .NET Aspire es la mejor manera de experimentar con Dapr durante el desarrollo local. Permite una experiencia de desarrollo local sin YAML ni complicados docker-composes, enfocándose en los servicios y no en la infraestructura. DAPR proporciona un conjunto de bloques de construcción que abstraen conceptos comúnmente utilizados en sistemas distribuidos. Esto incluye comunicación segura y asincrónica entre servicios, gestión de cache, flujos de trabajo, resiliencia, gestión de secretos y mucho más. No tener que implementar estas características por ti mismo elimina el código repetitivo, reduce la complejidad y te permite centrarte en desarrollar las características de tu negocio. Si tienes curiosidad por saber si DAPR puede ayudarte, ya sea por simple curiosidad, porque gestionar tus servicios se ha vuelto complejo, o porque te pidieron realizar una prueba de concepto, .NET Aspire puede ser tu solución. En mi blog tienes una serie de artículos y documentos donde lo trato ampliamente: https://jmfloreszazo.com/?s=dapr Diferencias entre .NET Aspire y DAPR: • DAPR: Abstrae algunas de las plataformas en la nube subyacentes. • .NET Aspire: Proporciona una configuración opinada alrededor de las tecnologías en la nube subyacentes sin abstraerlas. Una aplicación basada en .NET que usa DAPR puede usar .NET Aspire para orquestar el ciclo interno del desarrollador y agilizar el despliegue. Incluye extensiones que soportan el lanzamiento de procesos side-car de DAPR durante el ciclo interno. DAPR (1/2)

31 31 Beneficios de usar .NET Aspire con DAPR: • Representación de tu sistema distribuido a través de código constante y testeable en tiempo de compilación. • Un tablero web centralizado de OpenTelemetry para explorar tus trazas, registros y métricas. • Una forma sencilla de adjuntar sidecars de DAPR a tus aplicaciones. • Poca o ninguna configuración YAML. El uso de .NET Aspire para DAPR reducirá el tiempo de incorporación para tus desarrolladores, permitiéndoles centrarse en usar DAPR para el desarrollo de características en lugar de configurar el entorno local. Y si sumas la integración con OpenTelemetry, será aún más fácil solucionar problemas de interacciones entre múltiples aplicaciones localmente. Veremos un ejemplo donde ambos interactúan, demostrando cómo .NET Aspire y DAPR pueden trabajar juntos para mejorar la experiencia de desarrollo local y la gestión de sistemas distribuidos. DAPR (2/2)

32 32 ¿Qué es Radius? Radius es una plataforma emergente que promete revolucionar la forma en que se despliegan aplicaciones en la nube. Ofrece un mecanismo de despliegue agnóstico a la nube, permitiendo a los desarrolladores definir aplicaciones utilizando "recetas" que se mapean a varios servicios en la nube o componentes de infraestructura. Por qué Radius Completa y Cierra el Círculo de DAPR y .NET Aspire: • Despliegue Agnóstico a la Nube: • DAPR: Facilita la comunicación y gestión de microservicios, eliminando la necesidad de implementar características comunes en sistemas distribuidos. • .NET Aspire: Simplifica el ciclo de desarrollo y despliegue local, integrándose con DAPR para una experiencia más fluida. • Radius: Completa el círculo al proporcionar una capa de despliegue que no depende de un proveedor específico de nube, permitiendo una verdadera portabilidad y flexibilidad. • Modularidad y Simplicidad: • DAPR y .NET Aspire: Juntos, permiten una configuración opinada y modular del desarrollo y operaciones de microservicios. • Radius: Extiende esta modularidad al despliegue, proporcionando una manera unificada y simplificada de gestionar aplicaciones en diferentes entornos de nube. Suma a todo lo anterior el proyecto: RADIUS (1/2)

33 33 • Innovación y Eficiencia: • DAPR: Reduce la complejidad del desarrollo de microservicios. • .NET Aspire: Acelera el ciclo de desarrollo y despliegue. • Radius: Facilita un entorno donde la innovación puede prosperar sin las restricciones de infraestructuras específicas, haciendo que el despliegue sea más eficiente y flexible. • Integración con Kubernetes: • Radius facilita la transición de aplicaciones habilitadas por DAPR hacia estrategias de despliegue en Kubernetes, proporcionando un flujo de trabajo cohesivo y eficiente. Radius viene a cerrar el círculo de DAPR y .NET Aspire al proporcionar el último eslabón necesario para una gestión completa y agnóstica de aplicaciones en la nube. Con Radius, los desarrolladores pueden no solo desarrollar y probar microservicios de manera eficiente, sino también desplegarlos en múltiples entornos de nube sin complicaciones, logrando así una mayor flexibilidad y eficiencia en todo el ciclo de vida del software. https://radapp.io/ Nota del autor: de esta herramienta no vamos a ver ejemplo por qué esta en un estado muy inmaduro y el ejemplo que construya será inservible el día que quieras probar la demo que dejara asociada a esta sección. Suma a todo lo anterior el proyecto: RADIUS (2/2)

34 34 Existen muchos recursos que podemos desplegar de forma manual en local: una cache, un MySQL, un SQL Server, etc. pero otros tantos no podremos como puede ser el caso de un Azure Key Vault, obligatoriamente deberemos tener una cuenta de Azure, aunque en realidad aun no voy a hablar de esto si no de la facilidad con la que puedo desarrollar en local un Azure Key Vault y crear el recurso sin entrar en Infra estructura como código (IaC) o desde el propio portal de Azure. Tu solución .NET Aspire puede integrarse fácilmente con Microsoft Azure y desplegar recursos mientras depuras la solución Para poder lanzar este tipo de magia, .NET Aspire necesita acceso a tu suscripción. Para hacer esto, primero necesitarás: • Instalar: • winget install Microsoft.AzureCLI • winget install Microsoft.Azd • Accede a tu cuenta y no cierres esta ventana del CLI, dejala abierta hasta el final de ejemplo: • az login • az account show --query id --output tsv Azure y .NET Aspire (1/5)

35 35 Entramos en la aplicación AspireWeatherSample y el proyecto AppHost. Desde la línea de comandos y ejecutamos: dotnet user-secrets init Ahora toca inicializar las variables de nuestros secretos ( o bien desde el proyecto con la opción Manager User Secrets): dotnet user-secrets set Azure:SubscriptionId dotnet user-secrets set Azure:AllowResourceGroupCreation true dotnet user-secrets set Azure:ResourceGroup rg-jmfzaspiresample dotnet user-secrets set Azure:Location westeurope dotnet user-secrets set Azure:CredentialSource AzureCli Añadimos un componente: Aspire.Hosting.Azure.KeyVault y un poco de código para trabajar con Azure Key Vault: Azure y .NET Aspire (2/5)

36 36 Ejecutamos el proyecto: Azure y .NET Aspire (3/5) Antes de ejecutar el proyecto no existía Y tras la ejecución ya disponemos del recurso

37 37 Tu nuevo Key Vault desplegado en Azure Suma esto a RADIUS y entenderás por qué es un tándem ganador Azure y .NET Aspire (4/5)

38 38 https://github.com/jmfloreszazo/HandsOnNetAspire/tree/main/AspireWeatherAzureSample Azure y .NET Aspire (5/5)

39 39 Aunque inicialmente consideré presentar un ejemplo extenso que abarcara clientes, pedidos y artículos, he decidido optar por ejemplos más atómicos y, por lo tanto, más sencillos. Mi objetivo es explicar cada funcionalidad de la manera más aislada posible, permitiendo así una comprensión más clara y directa. Posteriormente, será tu tarea ensamblar estas piezas, como si fueran fichas de un puzle, para construir soluciones más complejas y adaptadas a tus necesidades específicas. Ejemplos atómicos y sencillos

40 40 Vamos a realizar el ejemplo con SQL Server, ya que podremos tenerlo en local y por supuesto en el Cloud. Para poder tenerlo en local haremos uso de contenedores, por tanto, si no lo tienes, es el momento para instalarlo en tu máquina, ya sea Docker Desktop (el que usaré en los ejemplos), Rancher o Podman. docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=" \ -p 1433:1433 --name sql1 --hostname sql1 \ -d mcr.microsoft.com/mssql/server:2022-latest Y si lo deseas puedes instalar SQL Server Management Studio (SSMS): winget install Microsoft.SQLServerManagementStudio Una vez desplegados los requerimientos iniciales, vamos a crear un pequeño ejemplo donde vamos a realizar operaciones básicas (CRUD) con los datos, por tanto, nuestra aplicación sería la siguiente: .NET Aspire y Datos (Relacionales/NoSQL) (1/7) API Datos

41 41 El ejemplo se encuentra en: https://github.com/jmfloreszazo/HandsOnNetAspire/tree/main/AspireDatabaseSample Donde podrás observar, desde donde partimos a donde llegamos. Ya que os quiero mostrar como desde el proyecto de inicio vamos a añadir .NET Aspire a una solución ya existente. Comenzamos con la carpeta Inicial: • AspireDatabaseSample.Service/Program.cs, descomentar las líneas 16 a 21 para poder generar la base de datos inicial. • Y podréis interactuar con la API mediante Swagger. Si revisáis el modelo de datos vais a ver algo muy sencillo y no reviste ningún tipo de complejidad siempre y cuando tus conocimientos de Entity Framework sean los mínimos. Una vez arracada la aplicación y que pudieras probar a crear y recuperar información, estaremos seguros de que nuestra aplicación inicial esta lista para poder añadir .NET Aspire. .NET Aspire y Datos (Relacionales/NoSQL) (2/7)

42 42 El primer paso es desde el proyecto AspireDatabaseSample.Service, añadir: .NET Aspire Orchestator Support Y con este sencillo paso: .NET Aspire y Datos (Relacionales/NoSQL) (3/7)

43 43 Nuestra aplicación ya puede usar .NET Aspire, si esto mismo tienes que hacerlo con Docker-Compose, vas a tener que añadir mucha información en el YAML y aún más cambios si usas DAPR. Si entras en Swagger puedes hacer una prueba y ver que realmente está funcionando. Ahora es el momento de empezar como vamos a trabajar con SQL Server, ya que originalmente hemos trabajado con un contenedor preexistente y la idea a partir de ahora es otra que iremos viendo poco a poco. Ahora vamos a añadir esta referencia al proyecto AspireDatabaseSample.Service: dotnet add package Aspire.Microsoft.EntityFrameworkCore.SqlServer .NET Aspire y Datos (Relacionales/NoSQL) (4/7)

44 44 Añadimos el siguiente código en Program.cs: Y dejamos estas referencias: .NET Aspire y Datos (Relacionales/NoSQL) (5/7)

45 45 Ahora vamos a añadir esta referencia al proyecto AspireDatabaseSample.AppHost: dotnet add package Aspire.Hosting.SqlServer Añade el siguiente código en Program.cs: Y ejecuta el programa: .NET Aspire y Datos (Relacionales/NoSQL) (6/7)

46 46 Como puedes observar, se despliega un contenedor: Y la API funciona correctamente: En la carpeta Final, podrás encontrar este ejemplo completo. .NET Aspire y Datos (Relacionales/NoSQL) (7/7)

47 47 Ahora os preguntareis, ¿Cómo puedo ir a producción con el ejemplo anterior? La respuesta es tan sencilla como esto: • Si arrancas desde AspireDatabaseSample.AppHost, el sistema entiende que estas en desarrollo local. • Si arrancas desde el API el proyecto AspireDatabaseSample.Api y has modificado el fichero appsetting.json para que adquiera las variables o bien pasas las variables desde entorno, el sistema entiende que está en producción y leerá esa información de allí. Es decir, si arranco desde AspireDatabaseSample.AppHost y aunque tenga las variables definidas de las cadenas de conexión para ir a otro servidor de SQL Server, no va a sobrescribir esto valores y continuará con la configuración que tengas en AspireDatabaseSample.AppHost. Por tanto, si construyo una imagen docker para la Api con las variables ya sean el appsetting.json (mala práctica, pero se puede) o las añado desde entorno, el sistema sabrá que tiene que coger las variables, eso sí, las variables siguen un formato especifico ya que en el caso de SQL Server que nos atañe es Entity Framework y por tanto cada componente tendrás que ver en la documentación como construir esas configuraciones. Veamos una serie de capturas que nos ayudará comprender mejor esto que estoy contado. .NET Aspire y vamos a producción (1/4)

48 48 El código es el mismo que tenemos en la versión: https://github.com/jmfloreszazo/HandsOnNetAspire/tree/main/AspireDatabaseSample/Final Pero cambia en AspireDatabaseSample.Api/appsettings.json, hemos añadido una configuración específica que está relacionado con Aspire.Microsoft.EntityFrameworkCore.SqlServer: Si observas la https://github.com/jmfloreszazo/HandsOnNetAspire/tree/main/AspireDatabaseSample/Inicial, podrás ver que la configuración de conexión es la habitual de Microsoft.EntityFrameworkCore.SqlServer. .NET Aspire y vamos a producción (2/4)

49 49 Si entras según está descargado el proyecto: AspireContainerDatabaseSample , establece el proyecto API como inicial y lanzas la aplicación (recuerda que SQL Server debe estar conectado y funcionando con Docker), podrás ver que hemos entrado en la base de datos anterior y .NET Aspire no ha creado ningún contenedor a pesar de ser la configuración y el código igual al de la versión Final excepto la nueva configuración en API: Por el contrario, establecemos el proyecto AppHost, veras que se crea un nuevo contenedor: Esta forma de trabajar es extrapolable a los demás componentes con sus variaciones particulares de configuración. .NET Aspire y vamos a producción (3/4)

50 50 ¿Cómo nos vamos a producción? Si has trabajado habitualmente con ASP.NET y ficheros de configuración (o variables de entorno) podrás extrapolar este tipo de trabajo a la forma en la que trabajamos con .NET Aspire con la peculiaridad del nuevo formato de conexiones. Y que además NUNCA vamos a desplegar el proyecto AppHost; aquí la diferencia desplegamos el proyecto API ya sea en Serverless o Contenedores. En el ejemplo he mostrado como trabajar con una sola cadena de conexión. Existen formas de trabajar con varias, tal y como explica esta documentación: https://learn.microsoft.com/dotnet/aspire/database/sql-server-component?tabs=dotnet-cli&WT.mc_id=AZ-MVP-5004828#configuring-connections-to- multiple-databases .NET Aspire y vamos a producción (4/4)

51 51 Desde Postman he lanzado 100 GetAll (con un Collection Runner) para ambos procesos de base de datos anterior, 100 para Inicial y 100 para Final con la configuración establecida en el API (como el anterior ejemplo) con la intención de comprar muy por encima si existe alguna diferencia entre usar las librerías ambos atacando a la misma base de datos local, por eso he puesto aquí. Los resultados:: Como podéis observar, los tiempos son despreciables, entre ambas opciones de “producción”, pero para hacer un buen test debería usar: ttps://github.com/dotnet/BenchmarkDotNet Pseudo-Benchmark (1/2) Aspire.Microsoft.EntityFrameworkCore.SqlServer Si estamos en desarrollo local: ejemplo con AppHost Aspire.Microsoft.EntityFrameworkCore.SqlServer Si estamos en producción: ejemplo con API Microsoft.EntityFrameworkCore.SqlServer Nos da igual producción/desarrollo: ejemplo con API

52 52 Componentes de .NET Aspire (Parte II) Como habéis visto me he centrado mucho en la base de datos, y os voy a mostrar más opciones para configurar ese servidor de SQL Server. Pero lo que vengo a decir esta segunda parte es que cualquiera de los componentes en mayor o menor medida es personalizables de igual forma, solo tienes que ir a la documentación de cada componente y revisar que puedes hacer con ellos: https://learn.microsoft.com/es-ES/dotnet/aspire/fundamentals/components-overview?tabs=dotnet-cli&WT.mc_id=AZ-MVP-5004828 El proyecto AspireContainerExDatabaseSample podréis ver como ejemplo alguna de las características que podemos añadir a un contenedor:

53 53 Hasta ahora no hemos tocado uno de los proyectos que tenemos, se trata de: AspireDatabaseSample.ServiceDefaults, y que a pesar de proporcionarnos telemetría out-the-box, aún no hemos visitado. .NET Aspire y OpenTelemetry (1/4)

54 54 Para generar telemetría vamos a añadir unos logger en toda la aplicación, como, por ejemplo: .NET Aspire y OpenTelemetry (2/4)

55 55 Y observamos el resultado: .NET Aspire y OpenTelemetry (3/4)

56 56 Otro tema ya es añadir Custom Metric o Tag, que es algo exactamente igual que se suele hacer en OpenTelemetry y que se sale de esta publicación. Lo que sí que vamos a ver es a lanzar un Dashboard de Grafana emitir a Prometheus, etc. que al fin y al cabo es configuración de contenedores de .NET Aspire. Añadimos más código en AppHost/Program.cs: Y solo tienes que entrar en Prometheus o Grafana para poder ver la información correspondiente. .NET Aspire y OpenTelemetry (4/4)

57 57 No deja de ser un proyecto normal y corriente (AspireTwoTelemetrySample), donde puedes poner referencias nuevas o acceder a configuraciones: Si quiero ir por Azure Applica Insights, solo me queda poner el valor “Cloud” en vez de “Local”, así de simple y además puedo poner la cadena de conexión de Azure Application Insights en el proyecto API por si quiero trabajar como os he contado en la parte de producción, eso sí, debes buscar como debes poner esa configuración concreta. AppHost y ejecución condicional

58 58 .NET ASPIRE vs Docker-Compose Más de 200 líneas en el fichero docker-compose.yml para montar lo mismo que hacen 8 líneas de código de .NET, que al final no van a producción y por tanto es un trabajo que el cliente no ve. Imagina si tienes que hacer esto para 2 entornos y mantenerlo.

59 59 .NET Aspire y DAPR (1/2) Vamos a crear un proyecto nuevo de .NET Aspire desde el template de nuestro Visual Studio. Si no lo recuerdas puedes seguir los pasos de la sección “Comenzando con .NET Aspire”. Y una vez revisado que funciona nuestro proyecto, vamos a comenzar a poner en práctica le Building Block de DAPR: Service Invocation. • Añadir la referencia Aspire.Hosting.DaprDapr.AspNetCore en el proyecto AspireWithDaprServiceInvocation.AppHost. • Añadir la referencia Dapr.AspNetCore en el proyecto AspireWithDaprServiceInvocation.Web. WEB API

60 60 .NET Aspire y DAPR (2/2) En AspireWithDaprServiceInvocation.AppHost/Program.cs: En AspireWithDaprServiceInvocation.Web/Program.cs: En AspireWithDaprServiceInvocation.Web/WeatherApiClient.cs:

61 61 ¿Qué es el comando azd? (1/4) Ya lo hemos visto en la introducción como crear un recurso en Azure, con muy poco esfuerzo, es asombroso lo fácil que es crear recursos. Pero aún hay más: existe otra forma de tratar la infraestructura en Azure, para ello vamos a partir de un proyecto vacío como el que vimos en la introducción. Lanza una consola del CMD y dentro del proyecto AppHost: azd init

62 62 ¿Qué es el comando azd? (2/4) Una vez inicializado, primero es hacer un login: azd auth login y luego es momento de desplegar con: azd up. Nota: Si la región de Spain os da problemas ir a la región por defecto para revisar cómo funciona este comando y continuar con la práctica además recuerda que “dev” no te valdrá usa algo similar a esto “rg-jmfztestaspiredev”, ya que cra un rg-dev (que no sería único y te dará error)

63 63 ¿Qué es el comando azd? (3/4) Dejamos que concluya y vemos como la magia del comando nos genera un deploy en un Azure Container App sin tener ni idea de este recurso de Azure, vamos a entrar en el dashboard,, último link que aparece tras el deploy.

64 64 ¿Qué es el comando azd? (4/4)

65 65 .NET Aspire y ORLEANS Pues sí, también se puede usar MS Orleans, solo eso, que quede aquí presente: https://learn.microsoft.com/samples/dotnet/aspire-samples/orleans-voting-sample-app-on-aspire/?WT.mc_id=AZ-MVP-5004828 De esto tenéis varios documentos en mi blog: https://jmfloreszazo.com/?s=orleans

66 66 ¿Quieres saber más? Varios enlaces interesantes para ampliar conocimientos: • https://github.com/davidfowl, muchos ejemplos de uno de los artífices de .NET Aspire. • https://github.com/dotnet/aspire-simples, repositorios oficiales de ejemplos de .NET. • https://learn.microsoft.com/dotnet/aspire/?WT.mc_id=AZ-MVP-5004828, documentación oficial de Microsoft. • https://discord.com/channels/732297728826277939/759125320505884752, canal de Discrod de .NET Aspire “Intentar en la media de lo posible no meter ninguno NuGet o componente en vuestros proyectos que no sea licencia MIT y ante de eso lo primero es documentar esa librería en los ADR, que el cliente sea el que admita su uso” Para despedirme, permitirme un consejo muy importante que suelo dar a mis equipos:

En .NET a partir de ahora los microservicios cloud ya no serán tan complejos

No content