The Modern .NET Show

S08E20 - Aspirifying the Enterprise: Building Modern Apps with Aspire with Joydip Kanjilal

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S08E20 - Aspirifying the Enterprise: Building Modern Apps with Aspire with Joydip Kanjilal
The Modern .NET Show

S08E20 - Aspirifying the Enterprise: Building Modern Apps with Aspire with Joydip Kanjilal

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this episode, software architect and Microsoft MVP Joydip Kanjilal returns to talk Jamie through Aspire (recently rebranded from .NET Aspire) — Microsoft’s opinionated, cloud-ready stack for building, deploying, and monitoring distributed .NET applications.

Joydip frames Aspire as a solution to developer frustration: today’s enterprise systems are no longer single monolithic binaries deployed to a single server, but plethoras of APIs, message brokers, databases, caches, and background workers that all need wiring together. Aspire hides that configuration burden — YAML, XML, and JSON files included — behind an AppHost project where the architecture of the application is expressed in C# code, and where third-party integrations (PostgreSQL, Redis, Kafka, RabbitMQ, SQL Server) come as NuGet packages.

He outlines Aspire’s three core objectives — orchestration, components, and tooling — and is keen to dispel a common misconception: Aspire is not just for microservices. It works equally well for modular monoliths, doesn’t require Azure, and is not tied exclusively to Blazor or any single front-end. Along the way, Jamie and Joydip explore the built-in OpenTelemetry dashboard (which Joydip considers Aspire’s biggest selling point), Bing’s use of Aspire in production, and the “aspirified” Bitwarden experiment from the Aspire team’s Friday live-streams.

The conversation turns practical with Joydip’s advice for teams considering adoption: Aspire can be added incrementally alongside ongoing development, but only if the existing application is already modular and loosely coupled. If it isn’t, decoupling has to come first — and that’s worth doing anyway, regardless of whether Aspire ever enters the picture.

Whether you’re an enterprise architect weighing up the lift of aspirifying an existing system, or a developer who’s heard the buzzword and wants to know what’s actually in the box, this conversation lays out the business case, the technical pillars, and the practical starting points for adopting Aspire in the real world.

Episode Transcription

It is providing you a… unified stack, a cloud ready stack for building distributed applications where the configuration… you can say the configuration files that we usually maintain, like YAML files, XML files, json files. So it is generally taken care of those nitty gritties.

- Joydip Kanjilal

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today, Joydip Kanjilal returned to the show to talk about Aspire and where it fits in the modern enterprise application stack. We also talk about how Aspire isn’t just for microservices or nanoservices, it will work quite well with modular monoliths, too. As long as your application code isn’t highly coupled.

Maintaining large scale distributed systems requires deep visibility into… how the services are interacting, how the services are behaving over a period of time. So that helps enterprises to understand how the applications are behaving. If something goes wrong, what went wrong? Why is it that the application is not being able to scale? why is it not… able to handle, more you know, requests in a specific period? What are the security loopholes and everything?

- Joydip Kanjilal

One side note: we recorded this episode shortly before Aspire was rebranded from “.NET Aspire”. So if you’re listening in wondering, “wait. That’s not what it’s called,” please bear with us because we both used the old branding for half of the episode. Let’s hope that the PM for Aspire, Maddy Montaquila, doesn’t notice. Sorry Maddy.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : Joydip, welcome back to the show. It’s been a couple of months since we last talked, and a couple of weeks since your last episode where we talked about GitHub Copilot. Folks, if you haven’t heard that one, go back and listen to it.

But welcome back to the show.

Joydip : Thanks, Jamie. Thank you so much.

Jamie : No worries. So for the folks who maybe haven’t heard your previous episode, I was wondering, could you give a really brief elevator-pitch intro to you?

Joydip : Sure. This is Joydip. I’m a software architect, Microsoft MVP for seven years — six of them were consecutive. I am from India, and I have been in this industry, in the software industry, for the last almost three decades. It’s more than 25 years now.

I have been working in .NET from the time .NET was publicly made available, say around 2000-2001. At the time it was in beta, and the very first version of C# was released. From then on, I have seen a lot of developments happen over the years, over the decades you can say, in .NET technologies and all related technologies as far as .NET and its ecosystem is concerned.

I have written quite a few books, I have reviewed more than a dozen, and I have written around a thousand articles in various websites around the world. I blog at InfoWorld, and I am on the verge of launching a newsletter as well, where I will be focusing primarily on those aspects of technology I have been speaking about in recent times — like .NET Aspire, which I will be speaking about today, and building AI and AI agents using .NET. Anything and everything around .NET obviously, and also some other languages which are very popular, which you can work with in your IDE, like Python. So I will be talking about that.

I will update my profile accordingly and mention the link to my newsletter, so that when the readers go through those articles, they will be able to learn more about the technologies that I speak about in the podcast. They will be much more hands-on. The readers will be able to get source code and hands-on exercises to get started using those technologies.

Jamie : Last time we talked about GitHub Copilot, today we’re going to talk about something completely different. We are going to talk about .NET Aspire. There have been a few episodes on .NET Aspire so far, but we’re going to take this rather than from a theoretical “here is what .NET Aspire is and here are the vague ideas of what you can build with it”, which is the target for more of an intro to .NET Aspire. We’re actually going to talk about how you can use it to build enterprise applications using .NET Aspire in a modern way.

So I figured maybe the first thing we could talk about briefly is what .NET Aspire is, because I appreciate that whilst there are folks listening to this show who are at the forefront with us, there are also folks who maybe don’t get to try out these new technologies every day during their day-to-day work. They’re not as lucky as say you or I, or some of the other listeners. Maybe if you could tell us real quick what .NET Aspire is, just to set the level.

Joydip : In order for us to understand .NET Aspire, we first have to understand the intent of a stack like this. We have to understand the problem.

Today, enterprise systems are not built as single monolithic binaries anymore, and they are not deployed on a single server. Instead, they are composed of a set of components: APIs, backend services, data storage, message brokers, queues — message brokers that take advantage of queues to handle how messages are routed and delivered. We also have front-end interfaces to interact with these services, to display the data captured from these services in the presentation layer of the application.

In addition to offering compelling advantages such as scalability and resilience, these distributed applications can also have several challenges, like service discovery, configuration, observability, and deployment, because we are using a plethora of technologies. The technologies may not be of the same type — they may be different. I may be using Kafka for messaging. I may be using PostgreSQL for persistence. I may be using a .NET Web API. I may be using Quartz for background jobs. These are all third-party components, not created by Microsoft, that don’t use the CLR.

In order for us to use the umbrella of these technologies, we need an opinionated stack and a framework for building, deploying, orchestrating, monitoring, and observing distributed applications that leverage all of these technologies.

When we come to .NET Aspire, it is a cloud-optimised framework tailored for the development of production-grade distributed applications. It is an opinionated stack which is cloud-ready, and it provides the entire suite that you need to build a distributed application.

When you create an application in Aspire — I’ll just briefly give an example — you end up having several projects. You have an API project, an AppHost project, the service defaults, the web project, and the test projects as well. It is built in such a way that you don’t have to bother about maintaining these layers, or aggregating these technologies and getting them unified inside a single umbrella. You don’t have to worry about that. It provides you a template, you can say, where you can use all these technologies on the same platform.

The main intent is that it provides a unified, cloud-ready stack for building distributed applications, where the configuration files we usually maintain — like YAML files, XML files, JSON files — it takes care of all those nitty-gritties. You don’t have to worry about how they need to be configured. It’s simplified configuration.

You have multiple projects, but you don’t even have to worry about the external dependencies. Say you are using PostgreSQL, you are using RabbitMQ, you are using Redis — they will all be linked effortlessly. You don’t have to worry about how they are being configured internally. Of course, you have to mention where they have been hosted, but it is providing you a single umbrella where these technologies can be unified without having to bother about how they actually are being configured so that they can run together. You use client libraries, components, and external services, but you don’t need to bother about how to configure them. You just have to specify where they reside. The internal intricacies of configuration — that hassle — are taken care of by Aspire.

That is why Microsoft says it provides a unified stack. It provides you NuGet packages that can handle the specific cloud-native concerns. If you want to connect to Redis, to PostgreSQL, to SQL Server as the database, or to any third-party component that .NET Aspire can connect to, they are all available through NuGet packages. You just have to make sure those packages are available — you add them, and then it will be very easy for you to connect to them from your application.

That is why it provides a great tool. I will say a cloud-ready opinionated stack — yes, “stack” is the right word — designed to simplify how developers can build observable, production-ready distributed applications. It streamlines how developers can build, deploy, and monitor cloud-native apps by handling much of the operational setup out of the box. You don’t have to worry about how they are being configured. You don’t have to spend time configuring the infrastructure, wiring up the components, or wiring up the services. That is taken care of by Aspire. That is the main intent of Aspire.

But Aspire is not meant only for microservices. That is a common misconception. In reality, it is not only about microservices. I have seen many developers feel that it is used only for microservices. I have seen them building microservices the moment they create an Aspire application in Visual Studio. But in reality, it can be used for your modular monoliths also. It can be connected to any cloud. It doesn’t need Azure to run — it can run in any cloud. It can internally use telemetry, resources, and health — it can provide you a single dashboard where you can see how your application has been behaving. All those components have been wired up together.

But again, it is not in reality meant only for building microservices. It is for building cloud-native apps, and even apps which may not be residing in the cloud, may not be working in the cloud. Here is the catch though: if your application is not using cloud, if your application is not using containers — suppose you are not using Docker — some of the features of Aspire in your application will be missing, so you will not be able to use them.

The recommended way to use Aspire is using cloud-native services, using services that are hosted in the cloud, and also using containerisation. Microsoft is not rigid here. It’s not that it cannot run without it. It’s just a template. It provides a platform where you can design your services and your front end. By default, it will be generating Blazor in the web project, but that does not mean you have to use Blazor only. You can use React, you can use anything.

To sum it up, Aspire is a platform where you can build, deploy, and monitor cloud-native applications without having to be bothered about the way components are wired together, or how they are configured internally. But it does not necessarily mean that it is only meant for microservices. It can handle service discovery, dependencies, and monitoring — display in a dashboard, in a common place, how your application has been behaving.

But again, it does not have to run only on the cloud. The recommended way to use Aspire is to deploy your services in the cloud, to get the best of this Aspire stack provided by Microsoft. You should host your application somewhere in the cloud, because that way it will be easier. It is meant for distributed applications, so the moment you distribute your services and components, you can leverage Aspire — the features and benefits of Aspire, what Aspire provides you — in a much better way.

The name Aspire — .NET Aspire was named Aspire because it is developers’ aspiration to have a framework. Of course, it is a framework, but a better word will be that it provides a cloud-ready stack where you can build, deploy, and monitor your cloud-native applications.

The moment you create an application in Aspire, you will see multiple projects created. There will be four or five projects depending on what you have selected at the time of creating the project in Visual Studio. But never be carried away by the fact that you are constrained to using only Blazor in your front end. You can use anything. Never be constrained about using SQL Server or PostgreSQL — there’s no constraint. You can use anything, but in the template that is generated for you, it will provide you certain guidelines, I will say.

Even in the test project, if you have opted for having a test project at the time when you are creating the Aspire application in Visual Studio, a unit test method or integration test method will be provided for you by default. It does not necessarily mean that you have to use it — it’s just guidance, I will say, Microsoft’s template, which provides a cloud-ready stack for building cloud-native applications. Microsoft is providing guidance that you can follow this route to build and host your application in such a way that it can be maintained. It can be scaled. You can change your components. Your components become pluggable, so it becomes easy to change and maintain over a period of time. Of course, scale as well.

At the moment, you have your telemetry already embedded in the Aspire stack, and it makes it very easy for you to judge how your application has been behaving in real time. That way you can take necessary steps to improve the performance of your application.

Jamie : Okay, so what I’m hearing is .NET Aspire is more of an orchestrator of your app, right, rather than having to spend the time writing, say, a Docker Compose file, or even touching Docker files. We’ll come on to this in a moment because my understanding is you can actually point at a pre-existing Docker file and include that.

But what we can do is we can say here is a collection of technologies that make up my application. Maybe it’s one or maybe more databases in different technologies. A front-end technology, doesn’t matter what it is. A couple of back-end services. Maybe an authentication endpoint in one technology, maybe data access in a different technology, or something along those lines, right? We’ve got, as it were, a smorgasbord of technologies that make up our application. Maybe we have an Umbraco front end and things like that, right?

Joydip : Absolutely, absolutely.

Jamie : So we’ve got a whole stack of different technologies. We can throw them at Aspire with some configuration. We have to do some manual configuration of that at build time. Then what happens is Aspire steps in and says, “Cool, so the connection string for the database is this. I will replace that at runtime with the actual path to the connection string”, or the URL for this particular service that I know about — it does that round-robin service discovery. It will replace that URL at runtime with the actual URL of that particular endpoint.

You can just put — say you’ve got an API that does authentication, you might want to call it authentication API endpoint. What will happen is Aspire will do some magic — we don’t have to worry about the magic just yet — to replace “authentication API endpoint” with localhost, I don’t know, 7001 slash API for local. But when you push it to whatever cloud you’re pushing it to, it will then go, “Cool, this is Jamie’s super amazing authenticated API dot AzureWebsites dot net slash API”. It does that at runtime for us because it’s already done that discovery phase, right?

Joydip : Absolutely, absolutely. You’re bang on. Just to add to what we were saying, .NET Aspire is an initiative aimed at enhancing the developer experience for developers intending to build cloud-native applications in the .NET ecosystem.

There are three primary objectives of .NET Aspire: one is orchestration, one is components, and one is tooling.

As far as orchestration is concerned, it helps developers in orchestrating multi-project applications and their integral dependencies. This functionality guarantees that there is smooth execution and seamless connectivity between diverse components within the same platform, even when they are built with different technologies.

As far as components are concerned, these are encapsulated within NuGet packages. You can use .NET Aspire to connect to third-party components — Redis containers, PostgreSQL. You can connect to a SQL Server, you can connect to Kafka. All these are available using NuGet packages.

Then you have starter templates — that’s the tooling part of it — where you can incorporate a comprehensive set of tools tailored to streamline the development workflow as a whole. You have project templates and tooling experiences integrated into your development IDE itself. That is where Microsoft empowers developers to create and interact with the apps that comprise your .NET Aspire ecosystem — the applications that you are building. Since it will be having many components, a plethora of components, services, and third-party components as well, it provides a tooling framework that enhances productivity. It provides a cohesive environment for developing and managing everything, right from configuration tooling to how you can configure them — because the internal integration is taken care of by Aspire. You just have to mention where it has to connect.

In your AppHost — that is the AppHost project that will be created for you by default when you create a new .NET Aspire project — you configure the different projects and the services that your application needs to connect to. So these are the three core objectives of Aspire: orchestration, components, and tooling. Essentially, scaling and performance optimisation using a unified framework.

Jamie : That makes sense, right? Because there are so many tools out there to be able to do all of this — orchestration and tooling and system setup and all this kind of stuff. I remember talking to David Fowler about Aspire when they first started releasing it, and I was like, “So why does this exist, right?” I didn’t put it like that, but that was essentially the question I asked. He said, “I hate YAML.”

Joydip : Yeah, yeah, yeah.

Jamie : Especially since there are multiple flavours of YAML, and depending on what you’re doing, you need a different flavour of it. This is why it’s so difficult to get started in this industry, right? Everyone’s got an opinion.

But I think you’re right that the opinionated base — the problem is, in .NET specifically, we didn’t have, until Aspire came along, an opinionated way to build microservices, right? It’s not that this is the only way, but this is a way you can do it. It strips away all of the difficulty for you, so you can actually — we’ll get on to this in a second, but essentially, once you’ve installed the template with dotnet new template install or whatever it is, or if you’re running a relatively recent version of Rider or Visual Studio, you can actually go File > New Project and it’s all there, right?

When you do that, it sets everything up for you. There is a new template, like you said. There’s an AppHost, which is the central part that controls everything. Then you just register different application components within that and you push go, and it just works, right?

Joydip : Yeah.

Jamie : I’ve had a couple of clients over the last few months where, just getting onboarded, it was a case of, “Cool, okay, follow this guide.” Great. I’m on macOS, then none of this is going to work, because you’ve assumed everyone’s on Windows. .NET’s open source now and cross-platform, so I can do this on a Mac. So then I translate all of the instructions, possibly with the help of an LLM, translate all of the instructions to my Mac, run all of these commands bare on my Mac, making system-level changes. Then the app eventually works. There’s no undo setup, right?

Whereas with things like Aspire — and other frameworks have their way of doing it too — you can git clone and then do the equivalent of dotnet run, and everything just appears, right? All of that pain and setup is taken care of for you.

I guess that’s one of the two problems that Aspire is designed to solve, isn’t it? I feel like I’ve fed you the answer here, but I’m interested in your opinion. It’s the developer tooling, and the potentially cloud — but also on-prem — hosting model, right? Since it’s both the same way of doing it (it isn’t really, but from a 10,000-foot view it’s the same way of doing it), you effectively remove the “it works on my machine” excuse, right?

Joydip : What I feel is — this is one of the ways I explain .NET Aspire whenever I have a word with the teams that work with me around the globe — it is a solution to developers’ frustrations. When developers want to deploy cloud-native applications, there are so many concerns, hassles, and challenges in wiring all the components together, getting everything working in the cloud. Aspire is a solution because it provides a simplified way to get your application cloud-ready. It saves a lot of your time.

I will say it is Microsoft’s way to provide a framework which serves as guidance for developers to build, deploy, and monitor cloud-native applications. It does not necessarily mean that the way the projects have been created — the solution structure — can’t be changed. It’s just guidance. It is well thought out. When Microsoft came up with this solution to building enterprise applications that run on the cloud, you definitely need a test project, you need a web project, you need your services running in the background. You also need a place where you can wire up your configuration components — that is what AppHost is.

But again, it is just guidance which can be extended as well. It depends on the developers to what extent they want to extend it. It is provided by Microsoft to simplify cloud-native development. But it does not necessarily mean you have to use exactly whatever Microsoft has provided. You can connect to any company, you can connect to any service. Your API projects can be multiple. If you are building a microservice, most importantly, if you are trying to apply your architectural patterns on top of it, you can do that. There is no constraint as such. It’s just a template that you can follow, extend, and use your own way.

Jamie : A hundred percent, I agree. Yeah.

Joydip : Like Docker. Nowhere has Microsoft specified that you have to use containers, you have to use cloud, without which Aspire will not run. It’s nothing like that. But it is recommended that you use containerisation to leverage the benefits that Aspire provides, and also host your services in the cloud so that you can scale your services in a much more efficient and seamless manner.

But nobody is stopping you from using Aspire the way you want to. The best benefit is that it eases your configuration. I don’t like using configuration files like YAML or XML or even JSON files, where I need to specify so many things. If there’s any tooling that can generate that for me, it saves a lot of my time. So obviously, yes, that’s a great advantage for developers building enterprise applications using the .NET ecosystem.

Jamie : That makes perfect sense, right? One of the things that we haven’t really — I mean, you touched on it a little bit where you said it doesn’t matter, it could be Postgres, it could be Blazor, it could be whatever.

The really cool thing — and I had to go and read the documentation just to double-check that this has been publicly released — is that it can run TypeScript apps now, natively. So it doesn’t have to be .NET specific, right? You can have your Aspire AppHost and say, “Well actually, my server-side component is TypeScript, or maybe my front-end component is React, which uses TypeScript. So use this version of the compiler and these npm setups and things like that."

So yeah, it could greatly reduce that developer tool burden. Even when it comes to publishing to public cloud, private cloud, on-prem infrastructure, or whatever, it just greatly reduces everything, which helps with that inner loop for the developers, right?

Joydip : Yes, yes, yes.

Jamie : So we started this conversation with what Aspire is, but the goal is to talk about building modern enterprise apps with Aspire. What specifically makes this useful for enterprise teams, right? I feel like we’ve covered some of it already.

But let’s say we’ve got an enterprise team of maybe 40 developers — you know, a double-digit team — and we’re all working on maybe one application that’s broken into, I don’t know, 10 or 12 different microservices, and I want to be able to say to the team, “Okay, here is the backlog, here is the source code, talk to your individual project manager about which piece of work you need to do. Go.” How does Aspire make that easier? What is it that’s useful about Aspire for that team?

Joydip : Aspire adds a lot of value, business value, to enterprises. It is especially useful for enterprise teams because it reduces configuration drift and standardises how services are wired, observed, and run across different components or services. It saves a lot of development time and effort. That way, developers can focus on something else, which will definitely amplify productivity.

Accelerated development — that is, faster development — is one of the biggest benefits of using Aspire. The AppHost project serves as a single source of truth. The architecture of the application is defined in code. You’re not using YAML, you’re not using XML files. The architecture is defined rather using C# code in AppHost, making it easy for even new team members who join the team to understand how the system structure has been designed by just reading one single file.

You have integrations to third-party components and third-party services using NuGet packages, where the dependencies are expressed using C# code.

Observability and monitoring is inbuilt. Maintaining large-scale distributed systems requires deep visibility into how the services are interacting, how the services are behaving over a period of time. That helps enterprises to understand how the applications are behaving. If something goes wrong, what went wrong? Why is it that the application is not able to scale? Why is it not able to handle more requests in a specific time period? What are the security loopholes? Everything, because of this observing and monitoring, is presented in a unified dashboard — a web-based dashboard that provides real-time access to logs, metrics, and distributed traces for every part of your application, without you having to do any manual setup at all.

It is built on OpenTelemetry, which means the telemetry data collected during development can be transitioned to production tools, like Azure Monitor.

If you think of the enterprise — I will tell you, from my experience, at that time there was no Aspire. When I was working for the company I worked for last in 2017, that was Dell. At Dell, one of the biggest constraints was there were so many services working. The Dell application actually was meant only for internal use. It was not to be deployed to any other company. It’s only for use in Dell, because Dell is such a vast company that it has to have a way to display the products that are being sold, and maintain them. Suppose you buy a laptop — you would want to exchange the laptop within the warranty period because it is not working. You have a unified application where it is handling end-to-end how the products portfolio can be handled and managed, I will say.

There are so many users accessing the Dell services and Dell services application at the same point of time. So many services are involved. The services have to scale.

What Aspire presents today — at that point of time, in 2017, we had created a dashboard without that, without Aspire of course, because there was no Aspire at the time. We had to write code for that. We had to capture telemetry data and present it so that we could know where things were going wrong. We could know which services were not responding the way they should: unable to scale, becoming slow, where we had specified the threshold that it has to provide a response within such-and-such time, and that threshold was not being met. Suppose we have to have a way to monitor how many requests go to a particular service at any given point of time — all these things were captured and presented for our internal use, like we architects and developers had to know this to provide the best way the application can scale.

Had there been Aspire at that time, it would have been really, really great. That is why I am saying Aspire presents a unified dashboard where you have everything. You can easily find out what went wrong if your application does not behave the way you want it to.

You have deployment flexibility. You can use Docker, you can use Kubernetes, you can use microservices, you can use nanoservices. You can have observability and monitoring in a unified dashboard without having to write too much. This unified platform presented by Microsoft to developers and architects worldwide cuts away a lot of your development effort, so you can save your time and focus on something else, which can definitely add business value for enterprises worldwide using .NET Aspire.

Jamie : Okay, so if I am an enterprise team lead and I’m thinking, “Let’s bring in .NET Aspire”, and let’s say I have some already pre-existing microservices that build up my application, and I’m not using .NET Aspire — or rather, not using Aspire, please don’t hate me, Maddie, they’re going through a rebrand at the minute, so we need to be careful of that — but let’s say I have a set of microservices that build up my app and I’m not using Aspire at the minute. I know that it’s not a zero uplift, but there is some uplift required to put Aspire in place. I know that once I’ve gotten through the setup, setting up Aspire and wiring everything together, things are going to be simpler. So that’s the impetus for going ahead and putting that in place, right?

Absolutely. I think also for the people in that position where I already have a pre-existing application made up of microservices and I need to figure out how to do it — whilst it is a non-trivial step, I think it’s worth folks (and I’ll put a link in the show notes) going and checking out the — I think they call it the Aspire Fridays or whatever, it’s something like that. The Aspire team have their own YouTube channel and Twitch, and all that kind of stuff. They live-stream on a Friday, or they had been doing up until the point of recording — taking any open source application they can find that’s made up of a bunch of different microservices, and effectively building Aspire into it to see how long it would take.

I think the longest one I’ve seen is when they took Bitwarden, I think it was, the password manager. The phrase that they’re using is “aspirified”, right? They aspirified the whole app, the back-end services, the UI, and even the Chrome extension, and got that all working with .NET Aspire — or rather with Aspire. It only took them about three hours, and that included the time at the beginning where they were all making fun of each other and being a bit silly, going, “Whoops, we haven’t set this up, and we haven’t set that up."

So there is a considerable uplift, but depending on the complexity of your application, I’m thinking maybe a couple of days of uplift, right? It’s not the most difficult thing to do, to I guess aspirify, or to convert an application such that it has Aspire running behind it.

Joydip : Absolutely.

Jamie : Then I guess once you’ve done that, there’s not just the tooling side of it. We’ve hinted at it a few times, and you have certainly hinted at it more than I have, but you get telemetry along with it, right? You get an OpenTelemetry dashboard with traces and things like that, which I feel is supremely important for enterprise. We like our metrics and our dashboards in the enterprise world.

I wonder if you could talk about that — and how, once we’ve aspirified something, or when we start from greenfields, we have that telemetry, and that becomes part of the experience, rather than, “Oh, snap, we’ve released and we don’t have any dashboards, how do we add those?”

Joydip : Yeah, so telemetry in Aspire provides built-in automated observability for distributed applications by enabling you to collect logs, traces, and metrics using OpenTelemetry standards, enabling developers to diagnose issues much faster, track service performance, and visualise how the services are interacting with each other in real time, in a unified, integrated dashboard.

The primary objective of telemetry in .NET Aspire is that, by providing you a unified dashboard, it helps you with faster troubleshooting. You can visualise your logs, traces, and metrics in real time. You can quickly diagnose errors.

You have support for distributed tracing, where it maps the path of the request across multiple services — where the services have been moving through from the time the services were called. This real-time monitoring, this built-in observability provided by Aspire by adhering to OpenTelemetry standards, enables developers to understand performance, scalability, what went wrong, and how requests can be handled. Most importantly, developers and architects working on enterprise applications in Aspire can understand the strategies that should be adopted to make the services scale more.

Telemetry is great. The best part is that you have something where you can explore more, while you don’t have to write tedious, monotonous code, or write code to configure things which takes away a lot of your productive time. If that is taken away from your day-to-day activity — you don’t have to bother about how it is being configured internally — at that time, you can focus on something which is much more fruitful. That way, the productivity of the teams can be improved considerably.

That is where the enterprises can leverage Aspire. One of the biggest benefits of Aspire, I feel, is telemetry. I forgot to mention — by utilising service defaults, it integrates the instrumentation of HTTP clients, reducing the manual configuration. In every way possible, Microsoft has taken away the configuration, the internal intricacies, the tedious effort that you have to otherwise put into your project in order to build your application. What is happening is, you have much more time to focus on writing your business logic, focusing on aspects like security, scalability, and performance.

This way, enterprises can benefit because the throughput — the amount of output a development team can provide in a span of time — is amplified. That is where Aspire scales. That is why Aspire has become so popular, and has been widely used worldwide.

Jamie : Absolutely. I mean, logging only gets you so far, right? Especially if you don’t know if you’re logging enough. I think that everybody approaches logging differently. The way that I do it is I log everything whilst I’m running on my local machine, and then I can dial it down because it’s impossible to add more logs after the fact, right?

But with metrics and telemetry, it’s there from day one. You can see in a graph where your hot paths are and the blocks of code which take the longest to process in your application. It makes it way easier to debug that stuff, and helps with the “measure twice, cut once” for benchmarking and all that kind of stuff.

I absolutely agree that the telemetry that’s built in is the biggest upsell for Aspire. I think it’s also worth noting — I’m going to say this, and I don’t know how much public knowledge this is, so I may get in trouble, but that’s okay, I can always edit the episode after the fact — Aspire isn’t just something that the Aspire team have put out and gone, “Yeah, you should use this.” There are key pieces of Microsoft’s own internal infrastructure that run on Aspire. You know, some people don’t like it, but Bing runs on Aspire. It’s a series of .NET apps that run on Aspire. So if you’ve used Bing, you’ve used Aspire. They’re using it in production. So if it’s good enough for them, it’s probably good enough for you, right?

Joydip : Yeah, yeah, definitely. You’re bang on. What matters is whether the application that I’m building and deploying is high-performance, secure, and can scale. These are the three main parameters needed in any enterprise application. Of course, it should be maintainable.

If you use Aspire, you have a platform where you can leverage these benefits easily, because it eases your effort. It cuts away a lot of effort you would otherwise have to spend in writing tedious code for configuration. You don’t have to spend time on configuring the composition. That is why, honestly, I like Aspire so much, because I don’t have to write monotonous code. It was terrible — writing so much configuration.

If you think back, not many years back, say six or seven years back, or maybe a decade back, it was really, really very tedious to write so many lines of code to get everything configured properly when running applications in the cloud.

Jamie : Oh yeah, 100%. Not having to write that tedious code means we can speed everything up. We talked about it earlier on — you talked about it very explicitly earlier on — about developer effectiveness and developer productivity. If we don’t have to wire up the boring stuff, the tedious stuff, then that means we can jump directly to providing value to the end customer.

Because as much as we might enjoy — you know, some people might enjoy it, some people don’t — doing the tedious bits of adding the telemetry in, and adding the metrics in, and all that stuff, that doesn’t add any immediate value to the end customer. The end customer wants to be able to, when I push the button to order the thing, know that within 24, 48, 72 hours, the thing will be delivered to me. I don’t care about the metrics and the logging and the system stability and all that stuff — well, maybe I care about system stability.

Joydip : Yes, absolutely.

Jamie : But what I care about is when I push the button and I give you the money, you give me the thing. We need to always really focus on that. So not having to do the tedious bits of wiring all of the metrics and the logging and the tracing and the telemetry — not having to create the dashboard, because there is a dashboard created for you. It might not be specifically tailored to your enterprise’s needs, but there is a starter one there. Being able to grab all of those things and feed them into Kafka or whatever to be able to build your own dashboards — I think that’s the superpower right there.

It takes this huge chunk, like we talked about earlier on, this huge chunk of busy work. It’s not necessarily difficult, it just takes a sprint or a couple of sprints to set all of this stuff up. If we can push a button and it’s already set up for us, then that’s what we do, right?

Joydip : Yeah, absolutely. .NET Aspire really adds value by accelerating development, reducing the operational complexities, and providing high-quality, reliable cloud-native development. It accelerates developer onboarding as well — not only developer productivity, but new developers when they join. It really eases getting started with your application fast. It reduces development costs, faster time to market, reduced risks as well. Of course, the best part is, I feel, observability and monitoring.

Reduction in development cost is again an excellent way for .NET Aspire to add business value to enterprises, because that is what is needed. When the development costs reduce on a particular project, I can ask my developers, “Hey, you don’t have to write so much code because Aspire is providing that for you. You’re already adding a cloud-ready platform with you, so I need this from you, I need that from you.” That way, enterprises can demand more from developers and architects working on enterprise applications.

Not only that, added to that, faster time to market. On one hand, the development costs get reduced because the developers can quickly connect to databases, services, caches, message queues, and everything, and they don’t have to write repetitive infrastructure code. The development cost obviously gets reduced. At the same time, it also facilitates faster time to market.

That is where businesses can benefit a lot, because that is what is absolutely needed. Businesses need to scale. They need high-quality applications. Faster rolling out of new services and new updates really helps businesses in the long run.

To a business, if I am a businessman, what matters to me is whether I can launch products faster — launch products that are scalable, that are high-performance, that are secure, faster. I may or may not be concerned at all with what Aspire is providing, but I know that, yes, Aspire adds a lot of value to the business. I will take it from the business perspective. I don’t want to go into the technical intricacies because I’m a businessman. That is why it has become so very popular worldwide, and so quickly as well.

Jamie : Yeah, you’ve explored most of the points I wanted to make. But you’re absolutely right. It really is becoming the technology du jour, I guess.

Just real quick on that, I talked earlier about how I can maybe take the pain of aspirifying an app in maybe a week, maybe a sprint, maybe two sprints. Is it an all-or-nothing change, or is it something I can do incrementally?

I have an existing system — we talked about earlier on, I’ve got an existing system, I’ve got a team of 40 developers. I’m going to take 10 of those developers away, put them on a branch, and say, “Aspirify my system.” Do I need to do it all at once, or can I, every sprint for the next number of sprints, slowly replace everything — or rather slowly add that AppHost infrastructure underneath my application — so that then when I’m ready, I can go, “Cool, right, let’s move over to hosting the app as an aspirified app in production”?

Is that something I can do, or is that, from your perspective as an expert on this — is the advice to halt production and actually just spend however long is required to aspirify it? Or is it a case of keep going, keep adding user value, but have a small team that every sprint, every two sprints, every whatever, incrementally adds an aspirified setup? I don’t know. I feel like I’ve used all of my words.

Joydip : That’s an excellent point. To add Aspire to an existing project, the best way to get started is to understand the services in the existing project that is not using Aspire — the business rules of the application, the service boundaries. Then you have to identify where and how you can plug in an orchestrator to manage the services, and a service defaults project for the configurations.

If your application is modular, I will say it will not take a lot of time and effort. Parallel to the current development, in order to aspirify that project, you can have a few developers go ahead adding the orchestration part — the AppHost project and the service defaults — while at the same time not changing anything in the existing code base. This will work provided your application is modular, well structured. It does not necessarily need to be a microservice or a nanoservice — it can be anything — but it has to be modular so that the service boundaries are well defined.

If it is not, then I feel you should not right away get started with Aspire. Rather, you should first make your application modular. Your application’s components should be cohesive but loosely coupled. If the coupling is high, I would say it is pointless to implement anything new to an existing application unless the coupling is reduced. Plugging anything new would become very, very difficult, and many features of the application might fail as well.

To come back to your point, aspirifying a project, I feel the two main things you have to first consider are: you need an orchestrator, and you need a service defaults project for the configuration. Then you can slowly and steadily go ahead getting them connected to the right place. But again, I am repeating the same thing again and again: if your application is not modular, if it is not loosely coupled, it will really be a lot of effort. So we should do that first, then get started using Aspire.

Jamie : Okay. What I’m hearing is — I mean, you’ve literally just said it, but let me just make sure I’ve understood. If your application is heavily coupled, then you’re going to have trouble.

Joydip : Yes.

Jamie : But you’re going to have trouble if you want to shift to a cloud-native stack of any technology, right? Because the whole point of cloud-native, whether it’s microservices or whatever, reducing that coupling where possible makes sense. It’ll make your app — thirty, forty years of scientific papers and real-world examples have shown that if your app code base is loosely coupled but tightly cohesive, you’ll have a better time with testing and mocking and runtime optimisations and just being able to manage it from a humans-managing-code perspective.

To your point, if your application is already quite highly coupled, perhaps investigate: can we start decoupling this application and just putting in maybe layers of abstraction, or something that helps to make our code a little bit easier to manage? Because a change over here should not really affect the code over there, as long as the API between them stays the same.

As a really silly example, if I create a method that takes two numbers and adds them together and then returns that addition, it doesn’t matter to the consumer of that method what else happens in there. I could do, “Add your two numbers together, but then do a whole bunch of other maths that’s not related to what you want, and then return you the sum of those two integers.” It doesn’t matter what’s happening in the middle — as long as from the consumer’s perspective, I give you two integers and you give me the sum, it doesn’t matter. That is loosely coupled, because all I know is, I give you two integers, you give me a different integer that is the sum of those integers. That’s all I need to know.

What I’m getting is, as with any application, applying standard software engineering principles first — if your application is highly coupled, maybe look into decoupling it because it will be better for you anyway, regardless of whether you use Aspire.

Joydip : Yes, yes, yes.

Jamie : Then if you want to use Aspire, once your application is decoupled — or if your application is decoupled, regardless of whether it’s microservices or not, or nanoservices, or whatever term we’re going to use, even modular monoliths will work — you can start putting the work in to, as we said earlier on, aspirify your application by putting in the AppHost and starting to carve off pieces. Sounds really violent, but you get what I mean — taking a chunk of it and putting it into the Aspire runtime.

You know that moment when a technical concept finally clicks? That's what we're all about here at The Modern .NET Show.

We can stay independent thanks to listeners like you. If you've learned something valuable from the show, please consider joining our Patreon or BuyMeACoffee. You'll find links in the show notes.

We're a listener supported and (at times) ad supported production. So every bit of support that you can give makes a difference.

Thank you.

Jamie : That’s really cool. My big worry is that we’re going to start running out of time as we start to wrap up. People will be listening to this going, “Yeah, okay, cool. I want to check out Aspire, and I want to check out some of Joydip’s — you’ve said earlier on a thousand articles and lots of books and things like that. Where’s the best place to find out what’s going on with you in that realm of articles you’ve published, books you’re publishing? Where is the best place for me to go and learn about Aspire? I want to start aspirifying something. I’ve heard Joydip tell me it’s worth the pain, although the pain is very small, it’s worth the pain. How do I go and learn that pain? How do I go and learn to do that?”

Joydip : Just give me a few days. Most probably this weekend, I will be launching my newsletter, where I will be focusing on the hands-on part of all that I have discussed in recent times — in the last few years, in podcasts and webcasts. I frequently get emails where the readers want to know how to use a technology. We discussed Aspire today, but it would be great if I can write an article presenting a detailed step-by-step guide on how to use Aspire — from the time you build your application until you deploy to a cloud like Azure or whatever, how you scale it, how you improve performance, how you monitor it, how telemetry works, and everything.

That way — keeping this in mind, I planned to launch this newsletter, because otherwise, I am discussing many technologies, and have been doing this on your platform. But the thing is, it becomes a bit abstract for the readers unless they get to know a sense of how actually they have to use Aspire. The same way like using AI in Visual Studio Copilot — we discussed Copilot, but it would be great if I can provide a guide so they can go through it, and it would be hands-on completely with snippets of code and screenshots, providing them end-to-end guidance on how to use Copilot, and also Aspire as we discussed today.

Once it is live, I’ll immediately send you an email with a link to that.

Jamie : Sure, yeah, and I’ll make a point to put that into the show notes as soon as that comes out. For the folks who are listening in, there’s a bit of a lead time between when we record and when it goes out. So there’ll be a bit of a gap in time between when we record this and when it goes out, but I will make a point of getting links from Joydip to all of the things that he’s talking about and putting them into the show notes. If you are interested, press through, click through, whatever action it is you do to go through to the show notes, and there’ll be links to everything on there.

So what about getting started with Aspire then? Let’s say — we use user stories all the time, right? As a developer who has never heard of Aspire, who has heard this episode and gone, “That’s it, I want to go and learn that”, where do I go to start that journey?

Joydip : First, the most important aspect a developer has to know is, the developer has to understand the problem. What are the pain points in building modern enterprise systems? Because they are no longer single monolithic binaries. They are no longer deployed on a single server. They’re composed of a plethora of APIs and components and services. That is where the pain point lies, because configuring them and getting them unified in a single platform becomes very, very difficult. It consumes a lot of time. That is where the pain point lies. That is where developers have to understand why developers should use Aspire actually.

By understanding the problem and the pain points, developers then have to understand what a cloud-native application is. What is scalability? What is resilience? What are the capabilities of cloud-native? Why do we talk about cloud-native these days? What makes an application cloud-native, and where is it that Aspire can help in building cloud-native applications?

Then the developer should understand — parallel to learning about cloud-ready — the developer should understand microservices. They should be able to understand nanoservices. Why do we need services, and how does Aspire help in building microservice-based applications? What makes a stack opinionated?

In all those areas, they have to know what Aspire actually provides. What are the features, like orchestration and service discovery? What does service discovery actually mean? What is resilience? What does Aspire show in the dashboard? How can Aspire be used to integrate with third-party services and components? We say that Aspire has support for cross-platform technologies. That is where it helps you to connect to non-.NET components built using non-.NET technologies — like you’re using Kafka, you’re using Redis, but you’re still connecting from the same development ecosystem, I will say.

To sum it up, they have to first understand what the exact problem is. Why do I need Aspire? What is the problem that one wants to solve? What is the pain point of building an enterprise application? Then they have to understand cloud-native, microservices, and nanoservices, and then they have to get started building a very simple application.

This is exactly what I would like to focus on — a series of articles I will be writing about Aspire and Copilot, etc., that I’ve been talking about for the last few years. To get started with any technology, I will always say that first the developer should understand the problem that particular technology is trying to solve. The best way to learn Aspire is to understand what it is meant for, what it is trying to solve.

Jamie : Okay, cool. Yeah, so what I will do is I will be in touch with you. I’ll leave this in so that folks can hear this, but I will be — it makes me accountable, right? I’m accountable to the listeners — I’ll be in touch with you as you start to release these blog posts you were talking about and different articles that folks can go and check out, and I’ll make a point of putting them into the show notes. So folks, there may be a case where this episode has been released, and then I go back and alter the show notes to add more links.

But what I’ll do is make sure that you are checking out Joydip’s website, which will be in the show notes, and make sure that you’re subscribed to that newsletter when it starts dropping. Then you’ll get the notification directly. You don’t have to require me to remind you, right?

Joydip : Yep, yeah, yeah, yeah, yeah, yeah. Absolutely.

Jamie : Thank you very much, Joydip, for joining us today to talk about Aspire, and to give folks a real indication of why it might be useful for them to know this from an enterprise developer’s perspective — because a lot of the demos I’ve seen out there and a lot of the talks I’ve been to have been “Aspire’s great, here, let’s put Aspire on something.” There hasn’t really been a discussion as to what it actually gives you, from a cost-benefit analysis, which I feel like we covered today. Some of the things that are important to know about these kinds of things, all the different technologies that we can use from an enterprise perspective.

Because most of us listening to this show — and I count myself included in that, because listeners, I go back and listen to the early episodes so that I can relearn some things, it’s a great resource — most of us do work in the enterprise, whether we are contractors, consultants, employees, or whatever phrase you want to use. Most of us live in that world of enterprise.

When someone steps up onto a stage and says, “Let me give you 45 minutes of learning this technology and then you can go away and do this”, they don’t cover all the things that are actually important for enterprise developers, because, hey, most of those speakers are paid to be there. So there isn’t actually a drive to be at a point where it’s like, “Let’s talk about the problems you’re going to have."

I’m glad to see that some talks are going in that direction — of “Here are the problems that I had implementing this technology while working on this thing.” But most of them are still “Look at how clever I am, I can talk through the documentation in 45 minutes."

I’m really glad that you were here with us today, Joydip, to talk about this, and I’m so very thankful that you were able to come back to the show for the second time and talk a little bit more about this. So thank you very much.

Joydip : No problem, my pleasure. Thank you so much, Jamie.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places