las comunidades y a las personas que hacen posible que podamos estar hoy aquí compartiendo un rato agradable. Tu Esto no sería posible sin personas como
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 dogmático 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.
.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. ¿Y por qué no elegir .NET Aspire? ▪ Tecnología nueva: Puede tener una curva de aprendizaje y algunos bugs que Microsoft irá solucionando con el tiempo.
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.
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)
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)
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)
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)
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)
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)
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)
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)
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
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)
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 <your subscription id> 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)
conocimientos: • https://jmfloreszazo.com/manos-a-la-obra-con-net-aspire/, documento más extenso y más ejemplos. • 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
un Game-Changer para el desarrollo de aplicaciones Cloud-Native? • ¿En producción? Alguna persona puede contarnos su experiencia. • ¿Qué tiene que ver .NET Aspire con el Project Tye? • ¿En qué posición queda DAPR con .NET Aspire?, ¿se estancará?, ¿será un revulsivo? • ¿Qué aportará el Project Radius? ¿Será la suma de todo? • ¿Novedades de .NET9?
jmfloreszazo
non97
cyberagentdevelopers
tsujiba
amaotone
kazu_kichi_67
kojiasai
takesection
kazzpapa3
vaaaaanquish
autifyhq
shuzon
shlominoach
bluesmoon
kneath
jakevdp
malarkey
lara
holman
destraynor
bkeepers
thoeni
marktimemedia
rocio
