 Hi, and welcome everybody to DAPA Day 2024. In the next session, we will talk about .NET Aspire and DAPA. Will it be a new doing team or not? And I'm Robin. I'm your guide for the show in the next 30 minutes. I'm enterprise and solution architect currently working at Ripple with 17 years of experience in IT and 12 years in experience in Azure and also in building distributed systems at scale. You can find a lot of information about me and my work on my personal website or Twitter now called xjitab or LinkedIn. Feel free to connect on any of these platforms if you have any question after the talk or if you need more information or simply want a small exchange. So the state of enterprise developers is slightly mixed in the industry. But most of us must develop resilient, scalable, and distributed apps that interact with multiple services or consist of multiple services. And all of these enterprise developers mostly want to focus on writing code and not learning new infrastructure predicament and new ways to deploy stuff. So this is all influenced by the trend of serverless platforms with simple code to cloud pipelines. Also low code and no code environments. And this all combined results in the use of multiple languages and frameworks during development. And this is definitely a point where we need help to make a little bit easier. And this is also the reason why most of us are hold it back on this to create or develop distributed applications. So there's a limited set of tools and run times to build distributed applications. DAPA is for sure one of the good examples to use. So run times have limited language support, a tightly controlled future set. And especially for the needs of developers, it's mostly too complex to work with in the daily business. And also the run time mostly targets specific infrastructure platforms with limited portability. Local debugging is mostly nearly impossible if you develop distributed applications. And all this is already tagged slightly by the well-known DAPA framework. And you know with all this components and functionalities built in and the ability to host it on multiple cloud platforms and so on. But the real interesting thing to get this on a local developers in a loop running, there's a new way. So we can say hello to the new kid on the block. And it's simply .NET Aspire. So what's .NET Aspire? .NET Aspire is an opinionated, cloud-ready stack for building observable production already and distributed applications. So to sum it up, .NET Aspire will help you in setting up C-sharp applications mainly in Azure Cloud. Or if you do so later on to develop them locally. So what's in? .NET Aspire consists of three major parts, I would say. So that one part is the orchestration. .NET Aspire helps up to wire up a multi-project application and their dependencies with ease. So you have the possibility to easily define your application and to easily orchestrate the startup, the new deployment for tests and so on, and for the local run-up. So .NET Aspire also consists of components. So .NET Aspire provides components as new packages for commonly used services like Redis, Postgres, Cosmos DB, Service Bus, SQL Database, and so on. And .NET Aspire also comes with a tooling. The tooling brings templates for projects for adding .NET Aspire to existing projects and also a nice integration into Visual Studio and the .NET CLI. I guess later on there will be also an integration for Visual Studio Code, but for now we are fixed to Visual Studio. And to make all this work, .NET Aspire has a few fundamentals. In the end it's about 10 fundamentals. So first fundamental is orchestration. So .NET Aspire provides APIs for expressing resources and dependencies with a new distributed application that you want to debug or run locally or later on also deploy to Azure with Azure Developer CLI. And for this to make it more consumable in the end, .NET Aspire also adds another fundamental, the .NET Aspire dashboard. So the .NET Aspire dashboard is a built-in dashboard that brings your observability and visibility to all these applications and projects and dependencies in your distributed application. So it will help you to have a look into logs, traces, environment configurations, metrics in real-time, and it will also give you an overview about container spin-up during the process. The third fundamental you already heard about it before are components. So components are simply a created set of new packages that facilitates integration of cloud-net applications. So it's mostly fixed to the prominent services like Cosmos DB, Redis, SQL Database on Azure, and so on. Or a source account. For most of the components, you can also use the emulator to run them really locally without deploying a bit into the cloud. So, but for sure you can also use .NET Aspire to deploy Pulumi, Terraform, or Bicep templates. The next thing, the next fundamental in this group would be networking. So one advantage of .NET Aspire is that it wires up all this inner loop networking by itself. So you define the dependencies and .NET Aspire takes care of the connection between. And this is really great if you have huge apps because you don't need to deal with IP addresses, ports, and so on. It's all done by .NET Aspire. And for this, .NET Aspire also brings service discovery. So fifth fundamental. So it used the built-in capabilities of .NET and it's configuration-based endpoint resolver that's added in .NET Aspire. So later on, I will show you the app host project and where you define all the dependencies and this configuration-based endpoint resolver will help you to wire up everything. So it's a combination of networking and services discovery in this board. Next big thing are service defaults. So cloud native applications have a lot or have the need to be configured a lot and to get a convenient and streamlined, streamlined log experience and also streamlined way of working of the applications, you need to take care of a lot of management of settings and all this can be combined in .NET Aspire with the service defaults. Now, after we have defined service default, seven networking place components used, the dashboard is still there and the orchestration is clear. We have a part where it comes also tricky on this route applications. So in some scenarios, you want to store or persist data. For this, .NET Aspire brings volumes which can be used to persist data during the applications are running because otherwise the containers would really start empty on each try and with this way you can store your database content in this volume or store your uploaded files on the .NET storage emulation or something else. And they will be available after restart of the .NET Aspire app host project. The next big thing are health checks. So if you build your application and you need always to know how is the health status of your overall application and this is something .NET Aspire also brings with ease. So it uses a built-in .NET infrastructure for health checks and adding them to the project. So it's really helpful to get a full observability over the orchestrated project. So you can check the status of each app you fired up. And the last big thing, for me, it's mostly the importance, it's telemetry. So if you have this telemetry in place or if you have overall telemetry in place you have a really good insight into your application. And this can be easily done with open telemetry and for this, .NET Aspire for sure uses the .NET open telemetry SDK and leverages from its powerful integration. So for now on, there's also the functionality to use the dashboard and send the telemetry from other applications in. So it's there since the latest preview version they released recently. And I guess there will be a lot of development in this case, in this direction that you also can only leverage from specific parts of this framework. And to understand the example I will show you later on there's another thing we should talk about and it's the .NET Aspire terminology. So you see the basic definition of a really simple weather forecast project where the web front end is creating an API that's randomly generates weather forecasts. And the references you see here, they're defined for the web front end is on one hand the API and on the other hand the cache for the front end payout to cache. So and to make it a little bit more clear what's happening there, I borrowed the graphic from Microsoft Learn and you can see how this app host project is defined. So overall you have this app host orchestrator project. So it always has an app host suffix in the end by convention. And within this project you define your app model. In this case, it's a distributed application. And with this builder that's created there you can simply define resources like the cache, the API service or the web front end. In the end it's also a resource even it's don't have a variable to be referenced later on. And to make it then more easily to reference everything or every component within your project, it's easily to add the references as already mentioned for example in the web front end. So if you spin up or want to spin up the web front end with a reference to the cache and the API services it's all you need to do is to add these references and for sure also provide this written short codes or magic strings into the web app. So it's not the nicest example in the end but for sure it's a valid example to show you the terminology. So and if we want to combine Donut, Aspire and Dapper I think we are on a really, really good track to combine both technologies. So Donut, Aspire provides the built in possibilities to inject the Dapper sidecar into the local developers in a loop of .NET based applications. So I will show you in a live demo how you can simply add this Dapper sidecar into your developer loop. So and to get this combination why we also have Dapper in this game is so Dapper provides on the other hand the APIs for building reliable and secure microservices and as Dapper and .NET Aspire are complementary technologies Aspire will help you with service discovery to limit the resilience and health checks out of the box. So always in case you write or develop .NET on C sharp applications. And to understand a little bit more I will simply explain a little bit deeper in the next slide why I think .NET Aspire is a good choice to use the abstractions of the underlying cloud platform from Dapper and combine it with the opinionated configuration of the cloud technologies that .NET Aspire provides to you. So one of the main pain points most of us or most of our developers always face Docker compose. So it's an excellent technology but it's getting really unproductive when you only want to run multiple projects or executables. So you have to do a lot of configuration and to do this configuration we already at the next valid point. So one big disadvantage is declarative code at this point. So Docker compose requires you to write YAML code but YAML gets quite complex by adding abstractions to other services. And if you also then add compositions it's gets even more complex. And by writing this YAML code you don't get support by thick by strong it's not strongly typed in this case you don't have intelligence fully available and debugging of YAML files we all know what is really pain in the ass. So this is a real big pain point if you work with Docker compose. And to make it feel better or make it even better I think the use of imperative code or an imperative coding language will help you and this is what Don and Aspire does. So to make it at this point to an end what's the reason why we want to add Don and Dapper but Don and Aspire to this point is that we have a kind of abstraction that brings. So if we don't use Don and Aspire we mostly need to write specific code for specific technologies. So if we want to use Kubernetes or console we need to write different things as we want if we use other technologies. So this is where Don and Aspire simply steps in and the next few minutes I will show you and guide you through the Don and Aspire demo and we'll combine this with Dapper and within this demo. So I will slightly switch the screens. So I need to move to my virtual machine and now you can see the full power of Don and Aspire combined with Dapper as we have our already mentioned app host project and within this app host project we have defined the app model in this case always the distributed application at the cache as before as you have already seen it in the stateful example and in this case we already added a state store a Dapper state store to our environment or our application. We define the API service again in this case I added the state store at this point to store the forecasted weather for 10 seconds and in the end we also define the web component with a double sidecar name web and also the reference cache. So what's happening there to have a look into the code on the app services it's pretty simple and straightforward. We added the Dapper client in the builder added the service defaults from Don and Aspire and also we add the forecasting logic in there so we have some summaries or weather we have a weather forecast that checks for a stored forecast in the state store and if there is no forecast it will generate a new one and save it to the state store again. So if it's not already finds some forecast it will or if it's already finding a forecasted one it will just returned and to define all this you see we only reference the state store we defined already here. So it uses a name we define here to get it back or to derive it from the service discovery and that's everything we have to see like here. If we have a look into the web component we have also adding the Dapper client to the builder of the application and that's simply all we did at this place but in the weather client that simply calls our API that I showed you before we invoke a Dapper client and we are giving in that we need to talk to the API Dapper Sidecar and we want to use the weather forecast API we created before and this is nearly everything you need to do within your application so you don't need to deal with IPs you don't need to deal with ports or something else it's all handled internally by .NET Aspire and I already showed you that we add the service defaults to the startup code you can see it at this point here and we also do adding the latest output cache at this point we defined also in our app host project and if you then have a look to the service defaults then are simply added to the applications by baladot.addServiceDefaults is everything needs to be done to add the open telemetry and the default health checks and the service discovery to the project is combined in this extension so we have done all this in one place for all of your projects and all the projects using the standard service defaults are doing it in the same way so the configuration of open telemetry the added services to the builder are always the same and they always use the same settings over all applications you fire up so you have also the possibility to enable the Azure Monitor exporter enable the Promotors exporter and also you can do more things with Promotors and so on so it's most of these things are pretty fine but you feel free to extend it if you need it so there's a lot of possibility to extend it in the end so you can also add more meter providers and so on so and if we fire up our app host project to see Donut, Aspire and DAPA in action it simply builds the application and fires up the app host project and this will take a few seconds and afterwards we will already get the chance to see the beautiful Donut, Aspire dashboard so you can see that we have a container in there where we edit the latest cache we have the DAPA sidecar for the API services we have the DAPA sidecar for the web frontend and we have the both projects API service and web frontend so to have a look into there you can see that if you use the endpoints link you are already redirected to the right API endpoint or if you click on the endpoint for the web app you always get redirected into the right place of the web app. Well, after this I want to show you what adds into the DAPA dashboard into the Donut, Aspire dashboard, sorry for that and you can view for example the configuration the environment variables of the projects in so if we have a look at them in the web frontend you can have a look into each of them and you can easily click on the I and it will show you the value so this is pretty straightforward and you see the configuration for example for the cache and so on that's always or that's added here as environment variable or the DAPA HTTP port and you can also view them for the API service and also for the cache DAPA sidecar is mostly is also filled with some values so you have a fuel observability about all settings so you also can have a look into the matrix and the logs so you have the console logs for example from the API service DAPA sidecar you could have also a look into the console logs of the web frontend it's just a startup process in you have the possibility to have a look into the structure logs and also in traces so and you see already the call we have done and if we now go through our web app and just open the weather tab there's another forecast generated it's slightly different from the one I loaded in this case on the first call to the API and if we have a look to the traces they are updated in nearly real time or in a real time in this case and you can also have a look into the metrics of your application so if we have a look in the metrics of the web frontend and we can have a look into the request duration or active requests per second so it's all shown in near real time so if we just reload the page you then should see also an active request coming in so this is what I want to show you in a quick demo I think most important is the fact that it's really easy to add the DAPA sidecar without any further configuration and also without any further writing of YAML and if you would use the Azure developer CLI you could also deploy this directly to Azure so I will not show this because of the time limit we have and I will step back to the presentation and summarize a little bit what we talked about so I strongly see the positive things that come in with Don at Aspire and I'm a big fan of imperative programming languages so the abstraction and simplification capabilities of Don at Aspire which is coming with the tool are much more powerful than the voices that stands against adding another tool to the tool chain so use the power of Don at Aspire and makes your life and the life of all your developers easier so to sum it up a little bit so imperative language support is the key for success at this point so use the power of your IDE and leverage from various advantages like types, intelligence, abstractions and so on so Don at Aspire is for now in public preview it's currently preview four it's already provides a solid ground to work with it and it will be extended under this first general available release that is proposed for this year and I think this will be the game changer on working with DAPA in Donat and Azure environments mostly because of its integration and of its tooling because you have all the power at hand you have this components you have the integration in Visual Studio and the Donat CLI you have a template so that you can easily edit to your existing projects with ease and without too heavy state so begin your journey utilize Donat, Aspire and DAPA to improve the developer's day-to-day work experience and feel free to join the DAPA Discord channel there you will find me also and I will respond to your questions slightly and I will publish the code example from this from my talk in the session on my GitHub account and you will find it there within the next days so enjoy the rest of the day have fun watching the other sessions and see you next time, bye.