NET Aspire Made Easy (MEAP) (Fiodar Sazanavets)（Z-Library）

.NET Aspire Made Easy 1. welcome 2. 1_Getting_Started_with_.NET_Aspire 3. 2_Managing_Infrastructure_Components_With_Containers_and_Integrations 4. 3_Using_Database_and_Storage_Components 5. 4_Building_a_Food_Delivery_App 6. 5_Building_a_ChatGPT_clone_with_.NET_Aspire,_Ollama,_and_Semantic_Kernel 7. 6_Integration_Testing_and_Monitoring 8. 7_Components_for_Messaging_and_Caching 9. 8_Application_security_in_.NET_Aspire 10. 9_Deploying_Aspire_apps_to_production 11. Appendix_A._Setting_up_the_development_environment 12. index

welcome Thank you for grabbing a copy of .NET Aspire Made Easy. I am so excited to be part of your journey on learning the best framework in the .NET ecosystem for developing cloud-native distributed applications. If you are new to .NET Aspire, prepare to be pleasantly surprised. I started playing with .NET Aspire as soon as it was released alongside .NET 8, and it left a lasting impression on me. I have never seen anything like it. While I have been developing cloud-hosted distributed applications for years, I have never seen anything like. There isn’t any other framework I know of where you don’t have to go through a lengthy setup step to make your cloud application work locally. With .NET Aspire, all you need to do is just install your standard .NET development tools and it just works. Your entire distributed application can be launched with a click of a button and all its services will be attached to the same debugger. This is why .NET Aspire is gaining in popularity. We use it in my project at Microsoft to build a large-scale system for a scientific government organization in the UK. The system consists of many moving parts and is capable of continuously handling petabytes of data. Once we migrated our codebase to .NET Aspire, things became so much easier. There is now also much less documentations to read for the new joiners since there are now significantly fewer steps needed to set up the development environment. In this book, you will learn what .NET Aspire applications consist of and how their fundamental components work. You will have a detailed look at how to integrate .NET Aspire applications with infrastructure components, such as a wide variety of database types, message brokers, distributed caches, etc. We will go through the step-by-step process of deploying Aspire-hosted apps to the cloud. We will cover Azure Container Apps and cloud-agnostic Kubernetes clusters as examples of these. We will apply some special use cases, such as hosting raw Docker container inside Aspire and applying

Single Sign-on security to distributed apps. Finally, we will go through some examples of how real-world distributed applications are built, such as delivery tracking apps and social media platforms. I hope you enjoy reading .NET Aspire Made Easy as much as I enjoyed writing it. If you have any questions or suggestions, I will be open to hearing them in the liveBook Discussion forum. —Fiodar Sazanavets In this book welcome 1 Getting Started with .NET Aspire 2 Managing Infrastructure Components With Containers and Integrations 3 Using Database and Storage Components 4 Building a Food Delivery App 5 Building a ChatGPT clone with .NET Aspire, Ollama, and Semantic Kernel 6 Integration Testing and Monitoring 7 Components for Messaging and Caching 8 Application security in .NET Aspire 9 Deploying Aspire apps to production Appendix A. Setting up the development environment

1 Getting Started with .NET Aspire This chapter covers Overview of .NET Aspire Distributed applications and the challenges they face The concept of an orchestrator inside distributed applications The structure of the Aspire Host project Using service discovery in Aspire In November 2023, the .NET community was taken by surprise. This is when .NET 8 was released along with C# 12. While these updates were completely expected, a thing that got released alongside them was completely unexpected. This thing was .NET Aspire. There were no announcements of it before its initial release. It was developed in total secrecy. However, once it was released, it had a huge impact on the .NET development community. Every .NET influencer and blogger started talking about it, and many businesses started adopting it. The reason behind such a huge success was that Aspire provided an elegant solution to a problem that plagued software engineers for many years. It provided an easy way to develop and debug distributed applications locally. Traditionally, building distributed applications was very hard. Developers had to launch different processes, emulate various services, and disable some parts of the application to make it even possible to run on a development machine. Aspire changed all of it. The whole distributed application can now be launched locally in a single process, and all of its services can be easily debugged. Just like Docker before it, Aspire enabled applications to run in a development environment the same way they can be run in production. The goal of this book is to teach you how .NET Aspire works and how you can use it for building and deploying distributed applications of any complexity level. While it doesn't cover all possible things you can do with Aspire (as there are way too many of these things to cover in a single book),

it does explain all of the fundamental principles that will allow you to become a competent user. This chapter will provide a high-level overview of what .NET Aspire is. If you are new to the domain of distributed applications that .NET Aspire operates in, you will also learn, at a high level, how distributed applications operate in general. Once you are familiar with how distributed applications work, you will learn how .NET Aspire fits into the picture. We will talk about what .NET Aspire is and how it makes the development of distributed applications way easier than any other tool. 1.1 Introduction to distributed systems .NET Aspire is a type of orchestrator. Therefore, before we can start learning it, we will need to understand, at least at a high level, what orchestration is. Since orchestration is done in the context of distributed applications, let’s start by learning what this term means. A distributed application is a collection of autonomous services, each running in its own process and communicating with lightweight mechanisms, often HTTP APIs. These services are built around business capabilities and are independently deployable by separate teams. Each service within the distributed system is responsible for a specific aspect of the application's functionality and can be developed, deployed, and scaled independently. Figure 1.1 demonstrates the structure of a distributed system. Figure 1.1 Example of a distributed application

In this example, the request into the system is initiated via a Representation State Transfer (REST) API, which is a commonly used type of communication mechanism that allows external clients, such as mobile apps, web pages, etc. to communicate with services hosted on a server. Then, this request triggers a payment process. The payment process is done by separate services, each responsible for an individual action. There is a separate service that performs invoice collection. A separate service adjusts the product stock. Yet another service clears the payment. So, while each service is encapsulated in its own piece of software, they all act together as a whole. While technically, each service in a distributed application is a separate application, it's meaningless on its own. It only serves its purpose as a part of a larger system. In a way, the system is a single application distributed across many components. This is opposite to the so-called "monolithic" application, which is a single application that contains all the business logic. Such an application may still

consist of many separate modules and libraries, but these would still work together as a single executable. A monolithic application with modularized inner logic is known as a "modular monolith". The structure of a modular monolith is displayed in Figure 1.2. Figure 1.2 Modular monolith structure

1.1.1 Advantages of using distributed systems Here are the main benefits of using a distributed application consisting of many separate services: Scalability: Separate services can be scaled separately based on their specific needs. This means you can allocate resources precisely where they are needed, optimizing performance and cost-efficiency. Flexibility and agility: Teams can work on different services simultaneously, enabling faster development cycles. Since each service is independent, updates and changes can be made without affecting the entire system. This agility is crucial for organizations that need to respond quickly to market changes. Technology diversity: Different services within a distributed architecture can use different technologies, such as different programming languages, different frameworks, and so on. Communication interfaces between different services are abstract and completely technology-agnostic. This means we can choose the best tools for each specific task, rather than being limited to a single technology stack for the entire application. Resilience and fault isolation: If one service fails, it doesn't necessarily bring down the entire system. Other services can continue to function, and the impact is contained. This fault isolation makes the system more resilient. Easier maintenance: Since each service is relatively small and focused, it's easier to understand, maintain, and debug. Developers can work on one service without needing to understand the entire application, which can simplify onboarding new team members. Although with .NET Aspire, as you will shortly learn, the entire system can be debugged relatively easily too. Scalable development: Because distributed applications consist of multiple services, multiple teams can work on different services simultaneously. This can significantly speed up development time, as teams can operate independently with well-defined interfaces between services. Improved deployment and continuous delivery: With smaller,

independent services, it's easier to deploy changes. Teams can adopt continuous delivery practices, releasing updates to one service without affecting others. 1.1.2 Disadvantages of using distributed systems Distributed architecture has its disadvantages as well, which make it unsuitable in certain scenarios. Here are the main disadvantages: Complexity: Managing a large number of separate services can introduce complexity, especially when considering inter-service communication, data consistency, and orchestration. Increased operational overhead: Each service requires its own deployment, monitoring, and scaling. This can lead to increased operational complexity compared to a monolithic architecture. Distributed systems challenges: Separate services rely heavily on network communication, which introduces latency and the possibility of network failures. Dealing with these issues, such as ensuring data consistency across services, can be challenging. Testing complexity: Testing distributed systems can be more complex than testing a monolithic application. End-to-end testing requires coordinating tests across multiple services and ensuring each service behaves as expected in different scenarios. Potential performance overhead: The overhead of network communication between separate services can impact performance, especially if services are not designed efficiently or if there is excessive data transfer between services. Security: With multiple services interacting over networks, there are more potential points of vulnerability. Proper security measures must be implemented at each service level and in communication channels. Initial development effort: Breaking down an application into microservices requires careful planning and design. There is an initial overhead in developing the necessary infrastructure and defining service boundaries. However, despite these disadvantages, .NET Aspire helps to significantly mitigate many of these challenges, particularly during development and

deployment. This is precisely why it became so popular among the .NET community. You should now have a sufficient conceptual understanding of what distributed systems are. Let’s now go through the fundamentals of orchestration. 1.2 Overview of orchestration Orchestration in the context of distributed applications refers to the management and coordination of individual services or components within a larger system. When building a distributed system composed of multiple services, containers, or other components, orchestration becomes crucial for ensuring that these elements work together seamlessly to achieve the desired outcome. Orchestration involves tasks such as deployment, scaling, health monitoring, and resource allocation across the distributed environment. Figure 1.3 shows how the process of orchestration works. Figure 1.3 Orchestrated system

1.2.1 Key aspects of orchestration Here are some key components of orchestration: Deployment: Orchestration systems handle the deployment of individual services or components across the distributed infrastructure. This includes starting, stopping, and updating services as needed. Orchestration automates many tasks related to managing distributed systems, reducing the need for manual intervention and improving operational efficiency. Scaling: As the demand on the system changes, orchestration tools can automatically scale services up or down based on predefined rules or metrics. This ensures that the system can handle varying loads efficiently. With automated scaling, orchestration platforms can quickly respond to changes in demand, ensuring that the system can handle varying workloads effectively.

Load balancing: Orchestration can manage the distribution of incoming requests or traffic across multiple instances of a service. Load balancing helps optimize resource utilization and ensures high availability and responsiveness. Health monitoring and self-healing: Orchestration systems continuously monitor the health and status of services. If a service fails or becomes unresponsive, the orchestration tool can automatically restart it or redirect traffic to healthy instances, improving system reliability. Configuration management: Orchestration tools often provide mechanisms for managing configuration settings across the distributed system. This includes handling environment variables, secret management, and other configuration parameters. Resource allocation: Efficient resource allocation is critical in distributed environments. Orchestration platforms can manage the allocation of CPU, memory, storage, and other resources to ensure optimal performance and cost-effectiveness. We will cover most of these aspects in this book. Now, let’s briefly talk about what .NET Aspire is and what benefits it provides to the developers of distributed applications.. 1.3 How .NET Aspire changes the game .NET Aspire is a cloud-native application stack designed to simplify the development of modern distributed systems with .NET. While it’s primarily tailored to developing cloud applications, it can be used to develop any applications hosted on the web that have at least one external component. For example, even a simple monolithic application will probably have some sort of a database connection and may be connected to a message broker. .NET Aspire allows for easy integration of these services inside a development environment. The principles we will talk about in this book will be equally applicable to distributed applications hosted in Aspire .NET Aspire and monolithic applications that rely on external components, such as databases and message brokers. What makes .NET Aspire stand out is that it provides a streamlined experience for building, running, and monitoring applications that consist of

multiple interconnected services. The Stack focuses on reducing complexity by offering a set of preconfigured components and tools that work seamlessly together, making it easier for developers to manage the entire application lifecycle. As well as making all the services of the distributed application talk to each other in the shared debugger process, it allows those services to be easily integrated with necessary infrastructure components, such as databases, message brokers, and so on. Figure 1.4 demonstrates this. Figure 1.4 Hosting code and infrastructure components in the same Aspire process One of the standout features of .NET Aspire is its ability to simplify microservice orchestration. Traditionally, running and coordinating multiple services requires a significant amount of boilerplate code and configuration. Aspire addresses this challenge by introducing an intuitive application model that allows developers to define services and their dependencies

declaratively. This approach not only minimizes repetitive code but also enhances the clarity and maintainability of the system's architecture. Another advantage of .NET Aspire lies in its built-in support for observability. As applications grow in complexity, monitoring their behavior and diagnosing issues become increasingly critical. Aspire integrates with tools like OpenTelemetry to provide comprehensive tracing, logging, and metrics capabilities out of the box. Developers can track requests as they traverse multiple services, quickly identify performance bottlenecks, and maintain the overall health of their applications without the need for extensive manual instrumentation. In addition to simplifying orchestration and observability, .NET Aspire is inherently cloud-ready. Applications built with this framework can be effortlessly deployed to cloud platforms such as Microsoft Azure. Amazon Web Services, or any other cloud host. The configuration system is designed to adapt to cloud environments, reducing the friction often associated with transitioning from local development to production deployment. All of the above points result in a substantial gain in developers’ productivity and improvement of the development experience. .NET Aspire helps teams stay focused on solving business problems rather than wrestling with infrastructure concerns. 1.4 Getting started with the Aspire Starter Project Let’s assume we created a new project based on the Aspire Starter Project template and called it AspireApp. The screenshot in Figure 1.5 shows what we would end up with. Figure 1.5 The structure of the Aspire solution

A complete example of the project we’ll walk through can be found via the following link: https://github.com/fiodarsazanavets/dotnet-aspire- examples/tree/main/AspireStarterProject/AspireApp This setup consists of the following applications: AspireApp.Web, which is a Blazor web application with a user interface that pulls data from an external REST API endpoint. AspireApp.ApiService, which is the REST API application from which the Blazor application pulls data. AspireApp.AppHost, which is the Aspire orchestrator that coordinates the other two applications. There is also a class library called AspireApp.ServiceDefaults, which provides some shared functionality to the applications that .NET Aspire orchestrates. Next, let’s have a look at how orchestration happens. 1.5 Orchestrating with .NET Aspire To launch the distributed application hosted in Aspire, we will need to launch the host application, which is called. AspireApp.AppHost in our example. The host application will launch all other applications. If we launch it and wait for all the services to build, we will be able to see a dashboard that looks like Figure 1.6. Figure 1.6 Aspire dashboard

If we were to run it under an HTTP profile rather than HTTPS, we would see only one endpoint for each service rather than two. However, this scenario is only applicable to a local development environment. This dashboard shows us what services we are running as part of an orchestrated distributed application. The dashboard contains the following information for each of the services: Service type Unique name used in the context of the Aspire environment The state tells us whether the service is running or not Source, which points us to the project that represents the service The service endpoint (if the service has one) Service logs Details of the service We know that the above applications are running. Firstly, this is what the value under the State column on the dashboard tells us. Secondly, if we open the logs for either application by clicking on the Console tab, we should expect it to look similar to the screenshot in Figure 1.7. Figure 1.7 Aspire console log