Aspire looks pretty good and I'm excited to see where it goes. Your example is nice if everything is under one solution but we all know that's not how we dev in reality. What I'd like to know Nick is; how do wire up aspire when your frontend projects and APIs are in separate solutions?
Came to say this. In reality all our projects are in separate repos. I’m struggling to see how Aspire can be used with that structure. It seems like it’s only good for multiple projects in one solution ?
@@apr0lI've been looking at the Aspire documentation from Microsoft to see if there is examples of the above use case and I don't see anything that's black and white. I think you'd have to use its service discovery option to find services and there is mention of k8s or azure containers discovery. I've not attempted to play around yet. I'm hoping nick or someone's done the hard graft and will provide a nice short overview soon
This is fantastic, please make a series and take this to the limits. Can we have different components like workers that consume service bus messages, how does one del with connection strings and so on. What aspire packages are there, and what do they offer. I am dealing with microservices, and bringing up the local environment means running this and that container, storage and service bus in Azure (storage could be also in the emulator), and running other parts in VS to do debugging, and then command line to fire up tests against this setup. it is really a pain everytime I want to debug
I was so hyped when seeing this!🎉 Can you please make a video on how to deploy that on azure and aws? And even perhaps on self hosted vServers? A lot people would benefit from this❤
To be honest, starting in the middle of the video, I just sat with my mouth open in surprise and admiration. This deserves every imaginable and unimaginable ovation towards the developers of this product! Bravo! Nick, need more information/tutorials on working with this project!
An export to k8s yaml or at least to docker compose is a must. A can see that deployments been handled to the DevOps guys and the dev team like "I did the aspire thing"
That's a LOT of rope! Newbie bootcamp developer can now create an entire distributed system in a few hours and once deployed can accidentally rack up tens of thousands of dollars worth of compute time in a matter of seconds. Genius Microsoft :)
I'm skeptical. How would it work for heterogenous systems (here I mean systems with components created using different programming languages/technologies)? Let's say I have a FE written in js/ts and not blazor? Or I have a BE component(s) written in go/ruby/rust/python/anything else? Also, as mentioned here multiple times, it will work painlessly only for monorepos.
As for heterogenous systems - they include in repo an example for NodeJS. It looks like this: builder.AddNpmApp("frontend", "../NodeFrontend", "watch") So I assume, they allow to extend this builder with other commands, essentially allowing to connect anything As for monorepo - maybe as a fan of monorepos I'm a bit biased, but I'd say all issues with it in polyrepos are frequent issues with polyrepos in general. The 'defaults' project can be shared via some package - you have to keep track of versions, but that's the point of polyrepo. The 'host' project is used for 2 things: running all locally and generating the manifest file for deployment. So in polyrepo you'll probably have one for each deployment units (probably one per repo).
I'd assume it's essentially just .net lifecycle hooks integrated into dev containers. For 'foreign' tech stacks you'll likely have to specify whatever's needed for the entrypoint of those apps.
If you explore the web app with react js template then it is just a matter of configuration. Probably don’t have to touch Aspire because the config links the frontend and the web app
It's pretty cool. I usually add a docker-compose file to manage a fairly similar flow, including otel-collector and grafana stack images. It's much easier with Aspire. It would be great to learn how to use an Aspire based approach in a production environment. I'm guessing this will be supported out of the box for Azure, but not sure about Kubernetes and other cloud platforms. Thanks for sharing, lots of useful and inspiring content!
The orchestrator doesn’t run in production. The assumption is that we can model the local environment when you are deployed. So for deployment we can setup your cluster in a way to preserves the experience when you run on k8s (or azure or aws).
Might be useful for smaller, new projects that are tightly integrated to .NET. One fundamental issue I see is that it seems completely tied to monolith repos. How is it supposed to work in a microserviced architecture without having annoying git submodules all over the place?
Yes very good point and also how to split across dev/code and a built/running environment. It often not possible to run everything locally and you want to point at share dev services that are already running.
It doesn't. It will only work for smaller projects with not too many services/moving parts. The idea that you can run an entire large distributed system on your dev machine is fundamentally flawed, so there is a hard ceiling with how far you can go with this.
Immediately thought of Project Orleans (and DAPR too). Use-case might slightly differ, but they solve most of the problems + introduce "actor" framework that is designed to solve async problems in distributed systems
I'd be careful using DAPR for big scale, production scenarios, the component bindings have unfortunately still a way to go, and many pieces are still missing or only entering preview. The same applies for mentioned projet tye, if it's even still alive. And all that makes me feel this is going to end up the same - sounding too good to be true at first, then for ages still not yet production ready, and then not anymore alive...
@@colebq we had multiple, mostly with EH and Cosmos bindings, but also with resiliency not implemneted, with app health checks not respected, etc It should be coming soon but it wasn't there yet
Totally agree regarding Microsoft Orleans. In my opinion, MS Orleans solves most problems of a distributed system natively without any extra fuss. Unfortunately, it has never received the necessary attention from Microsoft itself because it makes many Azure products and services redundant and Microsoft would sell fewer Azure services.
Hey Nick, thank you for this Aspiring ;) demonstration. I am very interested in an example on how one can deploy an aspire application with containers. Where would the containers be hosted, how will they be deployed etc. Thanks!
hi Nick, you are, in my view, one of the most reliable and resourceful mentor for many developers currently. May i suggest however, that you slow your speech down so that your videos speak to us, rather than hurrying to get to the end. I think many do not mind sitting to your 2 hour videos, so the length doesnt throw us off...pretty please
thats kind of an internal docker compose seems cool for fullstack devolpment using blazor, but do you see aspire useful for backend devs as well? btw, that dashboard is nice, is it available also without using the aspire builder?
Super excited for this! Looks amazing. Can you do a video on how would set this up for micro services? I'm a little confused how you would get other solutions to recognize the app host unless you would publish it as a nuget package or something.
@nickchapsas can you make a video on how we can create our own Aspire Components? I would like to use it to run containers locally for databases/services not currently offered.
My architect always says "microservices is not a technical implementation per-se, it is a team management implementation" (Before anyone comments, i know there are additional technical benefits to microservices!) We moved away from Monolithic applications because 20 developers all working on the same project step on each others toes... so we will break our application up into services, now each team could own a service or whatever.... but now my application is not a SLN with 30 services(and each "service" could have 2-3 CSPROJ projects!) but separate repo's with their own commit lifecycle and release lifecycle.. We are shipping individual services to production 2-3 times a day.... not sure how this will overcome that..
I don't think it's supposed to. Physical services != logical services, so you could have each team working in their own aspire universe (this is what people are doing today with docker compose). If you do need to call another service, there are a couple options, but it shouldn't fundamentally change what you are doing today.
This is very cool. I look forward to your next videos. I'll have to check the .NET Conf content, but the three things that I'd like to know about are: 1) what's the auth story? can we set up and mock client apps to delegate to a provider like Entra or Google? 2) what's the best practice for protecting the API with token-based auth? roll-your-own with filters, or is there something out of the box in Aspire? 3) what's the native client story? anything that works for Blazor webassembly that wouldn't translate to Blazor hybrid (MAUI/WPF/WinForms)? interested in that answer for both auth, and just in general.
Is there a way to have it multirepo? Since we're speaking about microservices would be great to have services divided in different git repositories (without submodules) but it doesn't seams so easy. I mean, you need references for all the projects in that AppHost
I love this, but i really wants to see what it looks like with a lot of microservices in a fully fledged application. Also, we're gonna have to wait for extra tooling to bring none dotnet based web pages to aspire (because i'd love to monitor my react to the same interface while debugging). I also don't mind containers and apis to be different pages. There's other UIs choices (like the metrics filters being unreadable) that are more important to tackle first IMO
This is actually cool, will make building micro services architecture alot easier... wiring it all up. Would like to know how to deploy such a project with a dependency on a docker container.
I don't know about that. Microservices are supposed to be independently deployable and independent of each other. Having to reference each service defeats the purpose I think
@@Demonata1223 Yeah I find it a little bit weird. I wonder if we can export that manifest.json with enough data for other people to get the docker images configured with all the variables and run in their system without depending on my repo. It also seems to be more specific for http workflows. Not sure about the benefits of using Aspire with the Rabbitmq package.
@@Demonata1223 Ah, I was more looking at it from an easy wiring it all up to each other, I was under the understanding you can still independently deploy it from each other...
"Best Practices" has become the phrase that directly translates to "Whatever will allow Microsoft to continue to take the maximum money they can from you". If they were truly interested in helping companies innovate, there would be comprehensive and simple upgrade paths from the last version of their web framework to the next. There is no "evolution path" because there's no money in that. However, there is money to be had in Microsoft Consulting rebuilding your product for you from scratch... again and again. I was on that side of the fence for a long time and I know how it works. Small development teams cannot keep up with Microsoft's pace at the same time they are trying to implement their own company's internal requirements. And don't get me wrong... I've been 100% in the Microsoft development camp since the 80s and have never strayed from that path. Although, now, it's no longer a walking path but a 10-lane highway with no speed limit and everyone is getting run over.
Great intro video Nick, thanks for sharing it. MS documentation is also pretty sufficient to this point (e.g. I was wandering whether someone would still need Dapr and is answered in MS Aspire FAQs). I just wander if Aspire is tight to Blazor or you can have solutions with different frontend technologies.
This is really cool, and I love your enthusiasm! I would be keen to understand more about how to take this from local development to cloud deployment (I use Azure)
Great introduction. From my perspective it feels like Aspire tries to solve.a problem where teams have a lot of distributed applications... but is the solution really another tool, or maybe it should be to consolidate some of the applications? With that said, I do think it is good that they are pushing more good defaults with otel and also makes it easy to connect things locally. I also wonder how, and if, it is possible to include something like a nextjs application into this world? I mean, create API in .NET, use docker for redis, and what do I do with an "external" thing like a nextjs application?
I was thinking this same, I wish they focused on completing the OTEL support or better cover typical scenarios in the default SDKs so it needs less boilerplate and hacks, other than trying to come up with just another layer on top of those. It's quite amazing for example how poorly EventHubs work with both OTEL and AppInsights out of box -> fix that. Or how much work you need to for proper batching or alerting in the EH SDK. But no, instead we get another abstraction layer that looks all cool and fancy, but which no one will use in a serious project, cause he'll hit a wall sooner or later.
@@kocot.This isn't an abstraction layer. This isn't tied to Azure. We're working with SDK teams in the general ecosystem to make OTEL better so that the dashboard *is* more useful.
This is my primary question. Does it have the power to simplify things when you’re using, say, an Angular front-end. My expectations are quite low, but if aspire turns out to be a hit, they’ll probably start adding those kinds of features, since it’s far easier to be language agnostic on the backend these days than the frontend.
@@Bliss467 I totally agree, and if this simplifies integrating multiple dotnet projects in a deployment of multiple technology stacks, that could just mean less burden on devops, by having less to worry about.
apparently it supports it - in their examples I found integration with NPM Node backend app: builder.AddNpmApp("frontend", "../NodeFrontend", "watch") I guess they can wrap any app you can run with a command, so it shouldn't be a problem
This is all nice, but I always roll my eyes when you get something "out of the box" and have to trust that it's doing what it's supposed to do. I like to have manual control over things.
What that is really insane dealing with all that will be tricky but reaching docker is crazy thing this is going to be the Futcher of distributed systems
Can you please extend the usage of Aspire with Identity for example, and how to keep all the authorization and authentication separate from the frontend?
What's the purpose of this tool? Is it supposed to be use in production or in development? Is it going replace Application Insights and/or Elastic APM?
The comments under this thread are crazy... "Do you not configure Git correctly and use branches" and "If you need more than 10-15 services you have done something horribly horribly wrong", are people joking or do they not have enterprise experience?
@@brandonpearman9218 We have almost 150 projects under a single solution... We just unload what we aren't working on, use Git submodules, it has never been an issue even with two dozen developers on the project.
Nick i would love to see your thoughts on the tech itself. I dont understand its use cases. In a distributed system you should be able to independently deploy services. This tech makes a distributed system function as a monolith. What are the use cases for that??
@filiphajek4103 Making services reference each other for debugging makes zero sense. You can already start multiple services with docker compose and debug them. I can see that maybe they wanted to be able to make distributed systems without the use of docker. And perhaps that's what it's for. So that you can create a distributed system easier without leaving the Microsoft ecosystem. But if that's all it is, it's nothing to be excited about. I won't use it personally just because ms has a tendency to drop tech like this. Docker is more proven.
@@Demonata1223 Yep, agree. But it is nice option, i can see some people using it .. including me. We have basically .NET only microservices .. i will give it a try.
"In a distributed system you should be able to independently deploy services" - you can have a distributed monolith, which is sometimes considered an antipattern, but it actually has some applications Anyway, host project is responsible for running apps locally and generating manifest for deployment pipeline. So I'd assume, you have one for each deployment unit and that's it
@qj0n Yeah, sorry, I've never seen a good case for a "distributed monolith." I've only seen inexperienced devs attempt distributed system and accidently making one. Which is extremely common. I can see that perhaps you could setup a host for each project. Although I'm pretty sure MS is leaning into single deployment as "the way" to do it. Regardless of any of that. Maintaining clean lines of separation in a distributed system is hard. Having tech that forces your services to reference each other will only make it harder. It very much seems to be the case that MS has made aspire to help create distributed systems that are forced to be anti pattern. As such, it's use cases are limited to cases where a "distributed monolith" are needed. Which. I've never seen a need for in my career. This is definitely going to go the route of orleans, fading into the background quick, I'd predict
@@romanhrytskiv8845 distributed traces and structures logs? A pattern for setting that up? Adding orchestration without having to build a container? Aspire isn’t a framework, it’s a stack and patterns to accelerate the things you can already do manually today.
Everything aspire does can be done by manually. If you’ve already have this setup for local deployment and for your deployment environment then you’re golden and don’t need it.
You have some misunderstanding of what Aspire aspires to do. It’s not to replace what’s already there. It’s to facilitate and improve the workflow as a whole esp. from the dev’s end. Do more research before posting something negative plz.
This looks like one of those MS things that look fancy now, but will be abandoned. You will have to work on some codebase with this (then obscure) technology and say "wth did they pick this proprietary thing that is now so old and no longer supported? why can't we migrate away anymore... too hard? :("
This is very cool, the one thing missing is "how to work with multi-repo". By default works great in a monorepo, but in reality most of companies running microservices have repo/service setup. How would this work in that case?
So many questions left. Please continue describing the topic. For instance how service descovery exactly works. Do you know something about Microsoft Orleans?
I could see this as being pretty useful where I work. Just wonder if there is a way to have it load an app into a browser tab by default and focus it, so when testing you don’t have to click the link in the portal to start testing your main project, but can still switch to the portal if you want.
This is largely what Java's Jini platform provided 30 years ago. Here we once again see the masses suddenly feeling like Microsoft is innovating when all they are doing is copying what's already been known, has been done before, and is known computer science. But, since everyone has been just using whatever MS provides, they've been locked out of being this productive for decades already.
Look. I was specialized in C# in 2010 instead of Java, thinking it would replace it. If 20 years of efforts of a monopolistic corporation that comes preinstalled in every computer of the planet, have not been enough to give C# any meaningful adoption... I wouldn't expect it any time soon.
How do you secure the dashboard. I mean if you run this in a production environment, can you add access rights to it? And can you also see to it that some environment variables are masked, as in some situations there is one team handling the system and another team handling the development and they aint usually allowed to access passwords but they are interested in seeing logs.
The name including ".NET" kind of makes it seem like it has fundamental runtime changes. I wonder how MS will manage, distribute and organize it alongside the runtime, now that there's an additional .NET subproduct.
Looks very promising. I wonder will it be possible to run a single project after it's configured as a aspire component? For example, if I want to only quickly debug the api project.
Aspire can be useful no matter how big or small your app is, the dashboard in particular provides a lot of great details during development that could be useful to anyone developing a .NET app.
I remember reading about them adding the workload commands to the dotnet CLI earlier this year, but I feel like it wasn't described why. I guess it was added because of Aspire, and Aspire was still on the down low. Fair enough
Aspire looks pretty good and I'm excited to see where it goes.
Your example is nice if everything is under one solution but we all know that's not how we dev in reality. What I'd like to know Nick is; how do wire up aspire when your frontend projects and APIs are in separate solutions?
I'd like to add, does everything need to be on dotnet 8 for aspire to work?
aspire template is only in latest preview version of vs, so looks like yes@@2u1u
Came to say this. In reality all our projects are in separate repos. I’m struggling to see how Aspire can be used with that structure. It seems like it’s only good for multiple projects in one solution ?
Use nuget packages maybe? Idk if it'll work like that tho
@@apr0lI've been looking at the Aspire documentation from Microsoft to see if there is examples of the above use case and I don't see anything that's black and white. I think you'd have to use its service discovery option to find services and there is mention of k8s or azure containers discovery. I've not attempted to play around yet. I'm hoping nick or someone's done the hard graft and will provide a nice short overview soon
I've never tried distributed applications before because they are so overwhelming. Maybe this will be the start of something new.
This is fantastic, please make a series and take this to the limits. Can we have different components like workers that consume service bus messages, how does one del with connection strings and so on.
What aspire packages are there, and what do they offer.
I am dealing with microservices, and bringing up the local environment means running this and that container, storage and service bus in Azure (storage could be also in the emulator), and running other parts in VS to do debugging, and then command line to fire up tests against this setup. it is really a pain everytime I want to debug
This is huge. We use AWS cdk in our company and that is a pain in the neck. If this works for aws in the future, will be a big win
That’s the hope!
This has to be one of the best thing coming out of .Net in a while. Hopefully they release a stable version.
I was so hyped when seeing this!🎉
Can you please make a video on how to deploy that on azure and aws? And even perhaps on self hosted vServers?
A lot people would benefit from this❤
Self-hosted would be awesome
@@petropzqi yep -I suspect it would be possible on self-hosted. Would be awesome for my org.
I'd live to see a helm deployment example of those to eks or aks
To be honest, starting in the middle of the video, I just sat with my mouth open in surprise and admiration. This deserves every imaginable and unimaginable ovation towards the developers of this product! Bravo!
Nick, need more information/tutorials on working with this project!
This is a brilliant addition. It has the power of Azure Service Fabric without all the overhead and complexity. Nicely explained by Nick.
You named the reason why it won't be popular.
An export to k8s yaml or at least to docker compose is a must. A can see that deployments been handled to the DevOps guys and the dev team like "I did the aspire thing"
A
This looks interesting, I’d love to see some follow up with practical use cases. I guess that’s a Dometrain course in the making 😂
That's a LOT of rope! Newbie bootcamp developer can now create an entire distributed system in a few hours and once deployed can accidentally rack up tens of thousands of dollars worth of compute time in a matter of seconds. Genius Microsoft :)
I'm skeptical. How would it work for heterogenous systems (here I mean systems with components created using different programming languages/technologies)? Let's say I have a FE written in js/ts and not blazor? Or I have a BE component(s) written in go/ruby/rust/python/anything else? Also, as mentioned here multiple times, it will work painlessly only for monorepos.
As for heterogenous systems - they include in repo an example for NodeJS. It looks like this: builder.AddNpmApp("frontend", "../NodeFrontend", "watch")
So I assume, they allow to extend this builder with other commands, essentially allowing to connect anything
As for monorepo - maybe as a fan of monorepos I'm a bit biased, but I'd say all issues with it in polyrepos are frequent issues with polyrepos in general. The 'defaults' project can be shared via some package - you have to keep track of versions, but that's the point of polyrepo. The 'host' project is used for 2 things: running all locally and generating the manifest file for deployment. So in polyrepo you'll probably have one for each deployment units (probably one per repo).
I'd assume it's essentially just .net lifecycle hooks integrated into dev containers. For 'foreign' tech stacks you'll likely have to specify whatever's needed for the entrypoint of those apps.
If you explore the web app with react js template then it is just a matter of configuration. Probably don’t have to touch Aspire because the config links the frontend and the web app
It's pretty cool. I usually add a docker-compose file to manage a fairly similar flow, including otel-collector and grafana stack images. It's much easier with Aspire. It would be great to learn how to use an Aspire based approach in a production environment. I'm guessing this will be supported out of the box for Azure, but not sure about Kubernetes and other cloud platforms. Thanks for sharing, lots of useful and inspiring content!
The orchestrator doesn’t run in production. The assumption is that we can model the local environment when you are deployed. So for deployment we can setup your cluster in a way to preserves the experience when you run on k8s (or azure or aws).
Might be useful for smaller, new projects that are tightly integrated to .NET. One fundamental issue I see is that it seems completely tied to monolith repos. How is it supposed to work in a microserviced architecture without having annoying git submodules all over the place?
Nuget?
maybe, have an aspire repo that submodules all the microservices / apps
@@BarbarosYurttagul sounds like a pain in the ass to maintain tbh. You'll have to update the submodule every time something changes
Yes very good point and also how to split across dev/code and a built/running environment. It often not possible to run everything locally and you want to point at share dev services that are already running.
It doesn't. It will only work for smaller projects with not too many services/moving parts. The idea that you can run an entire large distributed system on your dev machine is fundamentally flawed, so there is a hard ceiling with how far you can go with this.
Immediately thought of Project Orleans (and DAPR too). Use-case might slightly differ, but they solve most of the problems + introduce "actor" framework that is designed to solve async problems in distributed systems
I'd be careful using DAPR for big scale, production scenarios, the component bindings have unfortunately still a way to go, and many pieces are still missing or only entering preview. The same applies for mentioned projet tye, if it's even still alive. And all that makes me feel this is going to end up the same - sounding too good to be true at first, then for ages still not yet production ready, and then not anymore alive...
@@kocot. Hi. People seem to use Dapr in production. What are the specific problems you are referring to?
@@colebq we had multiple, mostly with EH and Cosmos bindings, but also with resiliency not implemneted, with app health checks not respected, etc It should be coming soon but it wasn't there yet
Totally agree regarding Microsoft Orleans. In my opinion, MS Orleans solves most problems of a distributed system natively without any extra fuss. Unfortunately, it has never received the necessary attention from Microsoft itself because it makes many Azure products and services redundant and Microsoft would sell fewer Azure services.
@@kocot. Bs. Dapr is already used in production for sometime now. Even big companies like NASA is using it
now THAT seems pretty damn cool, can't wait for this to mature!
This is such a cool advancement, can't wait to give it a try
Hey Nick, thank you for this Aspiring ;) demonstration. I am very interested in an example on how one can deploy an aspire application with containers. Where would the containers be hosted, how will they be deployed etc. Thanks!
hi Nick, you are, in my view, one of the most reliable and resourceful mentor for many developers currently. May i suggest however, that you slow your speech down so that your videos speak to us, rather than hurrying to get to the end. I think many do not mind sitting to your 2 hour videos, so the length doesnt throw us off...pretty please
This is so cool. look forward to more on this.
As always simple explanation, thanks nick!
thats kind of an internal docker compose
seems cool for fullstack devolpment using blazor, but do you see aspire useful for backend devs as well?
btw, that dashboard is nice, is it available also without using the aspire builder?
Looks awesome, looking forward to the new videos about it.
.Net Aspire has WingLang written all over it. I love it, and can't wait to put it to good use. :)
Awesome! Will make writing code for distributed apps way easier!
Really appreciate the black friday deals. Money has been tight and ive been wanting to check out the logging class so finally picked it up!
This is a good feature for monitoring, thanks for sharing :)
That's probably one of the best released features by Microsoft in the last few years. I am thrilled to see more what Aspire can do
As with many things I wish this was present when I started working on the setup I am currently working on...
So much effort to change.
Great Video. Thanks. Looking forward to learning more.
Super excited for this! Looks amazing. Can you do a video on how would set this up for micro services? I'm a little confused how you would get other solutions to recognize the app host unless you would publish it as a nuget package or something.
Same here, I'm also curious to know how this works with projects running in different solutions.
+1 we should look deeper into this
@nickchapsas can you make a video on how we can create our own Aspire Components? I would like to use it to run containers locally for databases/services not currently offered.
Look very cool. This is definitely something to deep into. Thanks!
Great work by MS, and thanks Nick for bringing it up in very elegant way.
Aspire is the best that happend since a long time!
My architect always says "microservices is not a technical implementation per-se, it is a team management implementation" (Before anyone comments, i know there are additional technical benefits to microservices!)
We moved away from Monolithic applications because 20 developers all working on the same project step on each others toes... so we will break our application up into services, now each team could own a service or whatever.... but now my application is not a SLN with 30 services(and each "service" could have 2-3 CSPROJ projects!) but separate repo's with their own commit lifecycle and release lifecycle.. We are shipping individual services to production 2-3 times a day.... not sure how this will overcome that..
I don't think it's supposed to. Physical services != logical services, so you could have each team working in their own aspire universe (this is what people are doing today with docker compose). If you do need to call another service, there are a couple options, but it shouldn't fundamentally change what you are doing today.
This is very cool. I look forward to your next videos. I'll have to check the .NET Conf content, but the three things that I'd like to know about are: 1) what's the auth story? can we set up and mock client apps to delegate to a provider like Entra or Google? 2) what's the best practice for protecting the API with token-based auth? roll-your-own with filters, or is there something out of the box in Aspire? 3) what's the native client story? anything that works for Blazor webassembly that wouldn't translate to Blazor hybrid (MAUI/WPF/WinForms)? interested in that answer for both auth, and just in general.
There's no new auth story outside of what already exists.
Is there a way to have it multirepo? Since we're speaking about microservices would be great to have services divided in different git repositories (without submodules) but it doesn't seams so easy. I mean, you need references for all the projects in that AppHost
Monorepo would be the best solution
I really hope Microsoft has something in mind. It's been said its done for big projects as well, and have it in one huge monorepo is not ideal
Git submodules perhaps?
maybe, have an aspire repo that submodules all the microservices / apps
@@GianlucaIselli How do you run today? Are you coupled to other projects to run your slice of Microservices?
This is really cool project! Thanks for sharing!
wow, thank you. This is great, will make managing micro-services more easier
This is seriously cool! Just wish I had access to this a year ago when I was setting up a distributed application 😄
I love this, but i really wants to see what it looks like with a lot of microservices in a fully fledged application. Also, we're gonna have to wait for extra tooling to bring none dotnet based web pages to aspire (because i'd love to monitor my react to the same interface while debugging). I also don't mind containers and apis to be different pages. There's other UIs choices (like the metrics filters being unreadable) that are more important to tackle first IMO
This is actually cool, will make building micro services architecture alot easier... wiring it all up.
Would like to know how to deploy such a project with a dependency on a docker container.
I don't know about that. Microservices are supposed to be independently deployable and independent of each other. Having to reference each service defeats the purpose I think
@@Demonata1223 Yeah I find it a little bit weird. I wonder if we can export that manifest.json with enough data for other people to get the docker images configured with all the variables and run in their system without depending on my repo. It also seems to be more specific for http workflows. Not sure about the benefits of using Aspire with the Rabbitmq package.
@@Demonata1223 Ah, I was more looking at it from an easy wiring it all up to each other, I was under the understanding you can still independently deploy it from each other...
@332glenn Each service has to have a reference to each other. Which means each service is deployed together.
@@Demonata1223 Good point 👍👍
This seems like it could be really powerful. From what I understand from your video, this is similar to creating a docker compose project.
My brain has just exploded. All these new things that Microsoft did for C# are insane. Thank you for giving us knowledge for all these new features.
Put out the "way more Aspire content"! NOW! This looks awesome! And: When will Aspire be out of preview?
"Best Practices" has become the phrase that directly translates to "Whatever will allow Microsoft to continue to take the maximum money they can from you". If they were truly interested in helping companies innovate, there would be comprehensive and simple upgrade paths from the last version of their web framework to the next. There is no "evolution path" because there's no money in that. However, there is money to be had in Microsoft Consulting rebuilding your product for you from scratch... again and again. I was on that side of the fence for a long time and I know how it works.
Small development teams cannot keep up with Microsoft's pace at the same time they are trying to implement their own company's internal requirements. And don't get me wrong... I've been 100% in the Microsoft development camp since the 80s and have never strayed from that path. Although, now, it's no longer a walking path but a 10-lane highway with no speed limit and everyone is getting run over.
Great intro video Nick, thanks for sharing it. MS documentation is also pretty sufficient to this point (e.g. I was wandering whether someone would still need Dapr and is answered in MS Aspire FAQs). I just wander if Aspire is tight to Blazor or you can have solutions with different frontend technologies.
This is really cool, and I love your enthusiasm! I would be keen to understand more about how to take this from local development to cloud deployment (I use Azure)
Amazing! keep it up man
Great introduction. From my perspective it feels like Aspire tries to solve.a problem where teams have a lot of distributed applications... but is the solution really another tool, or maybe it should be to consolidate some of the applications? With that said, I do think it is good that they are pushing more good defaults with otel and also makes it easy to connect things locally. I also wonder how, and if, it is possible to include something like a nextjs application into this world? I mean, create API in .NET, use docker for redis, and what do I do with an "external" thing like a nextjs application?
I was thinking this same, I wish they focused on completing the OTEL support or better cover typical scenarios in the default SDKs so it needs less boilerplate and hacks, other than trying to come up with just another layer on top of those. It's quite amazing for example how poorly EventHubs work with both OTEL and AppInsights out of box -> fix that. Or how much work you need to for proper batching or alerting in the EH SDK. But no, instead we get another abstraction layer that looks all cool and fancy, but which no one will use in a serious project, cause he'll hit a wall sooner or later.
@@kocot.This isn't an abstraction layer. This isn't tied to Azure. We're working with SDK teams in the general ecosystem to make OTEL better so that the dashboard *is* more useful.
Looks really cool! How would this work with multi platform/language orchesration?
This is my primary question. Does it have the power to simplify things when you’re using, say, an Angular front-end. My expectations are quite low, but if aspire turns out to be a hit, they’ll probably start adding those kinds of features, since it’s far easier to be language agnostic on the backend these days than the frontend.
@@Bliss467 I totally agree, and if this simplifies integrating multiple dotnet projects in a deployment of multiple technology stacks, that could just mean less burden on devops, by having less to worry about.
apparently it supports it - in their examples I found integration with NPM Node backend app:
builder.AddNpmApp("frontend", "../NodeFrontend", "watch")
I guess they can wrap any app you can run with a command, so it shouldn't be a problem
This is all nice, but I always roll my eyes when you get something "out of the box" and have to trust that it's doing what it's supposed to do. I like to have manual control over things.
What that is really insane dealing with all that will be tricky but reaching docker is crazy thing this is going to be the Futcher of distributed systems
@nickchapsas, thanks for the video!
I’d love to see your thoughts on Dapr someday.
Simply AWESOME
Can you please extend the usage of Aspire with Identity for example, and how to keep all the authorization and authentication separate from the frontend?
What's the purpose of this tool? Is it supposed to be use in production or in development? Is it going replace Application Insights and/or Elastic APM?
Looks like this requires teams to work on the same solution. Could be difficult
I've never understood why people say this. What issues are you facing? Do you not configure Git correctly and use branches like you should?
Consider have a thousands of microservices, can be difficult to put all those in one solution…
@@thiagomaia6351 you can use filtered solutions
The comments under this thread are crazy... "Do you not configure Git correctly and use branches" and "If you need more than 10-15 services you have done something horribly horribly wrong", are people joking or do they not have enterprise experience?
@@brandonpearman9218 We have almost 150 projects under a single solution... We just unload what we aren't working on, use Git submodules, it has never been an issue even with two dozen developers on the project.
What if one of my services is not written in .NET? What if I have a Typescript front end for example?
I guess like the redis cache container component, your Typescript app needs to be deployed as a container and loaded like so in your aspire project
So how is it distributed? It’s running on your single PC. How do we use it in kubernetes?
Nick i would love to see your thoughts on the tech itself. I dont understand its use cases. In a distributed system you should be able to independently deploy services. This tech makes a distributed system function as a monolith. What are the use cases for that??
Local debugging/developing. Thats it. It has nothing to do with deployment of services.
@filiphajek4103 Making services reference each other for debugging makes zero sense. You can already start multiple services with docker compose and debug them.
I can see that maybe they wanted to be able to make distributed systems without the use of docker. And perhaps that's what it's for. So that you can create a distributed system easier without leaving the Microsoft ecosystem. But if that's all it is, it's nothing to be excited about. I won't use it personally just because ms has a tendency to drop tech like this. Docker is more proven.
@@Demonata1223 Yep, agree. But it is nice option, i can see some people using it .. including me. We have basically .NET only microservices .. i will give it a try.
"In a distributed system you should be able to independently deploy services" - you can have a distributed monolith, which is sometimes considered an antipattern, but it actually has some applications
Anyway, host project is responsible for running apps locally and generating manifest for deployment pipeline. So I'd assume, you have one for each deployment unit and that's it
@qj0n Yeah, sorry, I've never seen a good case for a "distributed monolith." I've only seen inexperienced devs attempt distributed system and accidently making one. Which is extremely common.
I can see that perhaps you could setup a host for each project. Although I'm pretty sure MS is leaning into single deployment as "the way" to do it.
Regardless of any of that. Maintaining clean lines of separation in a distributed system is hard. Having tech that forces your services to reference each other will only make it harder.
It very much seems to be the case that MS has made aspire to help create distributed systems that are forced to be anti pattern. As such, it's use cases are limited to cases where a "distributed monolith" are needed. Which. I've never seen a need for in my career. This is definitely going to go the route of orleans, fading into the background quick, I'd predict
I don’t see a usecase for this at all, we already have everything setup with docker and kubernetes and there’s no place for this
The aspire components and telemetry are still useful if you already have orchestration handled both in dev and prod!
@@davidfowl we already have metrics and they're scraped by prometheus. Can you explain what more value this Aspire can bring us?
@@romanhrytskiv8845 distributed traces and structures logs? A pattern for setting that up? Adding orchestration without having to build a container? Aspire isn’t a framework, it’s a stack and patterns to accelerate the things you can already do manually today.
Everything aspire does can be done by manually. If you’ve already have this setup for local deployment and for your deployment environment then you’re golden and don’t need it.
You have some misunderstanding of what Aspire aspires to do. It’s not to replace what’s already there. It’s to facilitate and improve the workflow as a whole esp. from the dev’s end. Do more research before posting something negative plz.
This is beautiful
nice informative video thanks. I need a kubernetes deployment description, because not much description about that, please add about this too.
.NET Aspire is amazing. Nicely explained @Nick. Thanks!
Its actually like full elastic + rancher + docker hub and metrics and more holy shit.
Amazing! This is so coooool!
Ya know, I was really hoping Microsoft would add some more "magic" with poor documentation. Glad to hear they've been working on it...
This looks like one of those MS things that look fancy now, but will be abandoned. You will have to work on some codebase with this (then obscure) technology and say "wth did they pick this proprietary thing that is now so old and no longer supported? why can't we migrate away anymore... too hard? :("
Maybe ok for small projects, but seems counter to solving dev team issues. Which is why microservices, etc are used to replace a monolith.
This is great, but how do you work with a true distributed application? For example when repositories are seperate and dont live in the same project?
what is the terminal that you are using? Looks very nice :)
how scaling works?
how deployments done on different cloud provider?
how it will work on Kubernetes cluster?
how it will work on on-prem server farms?
awesome! thanks
This is very cool, the one thing missing is "how to work with multi-repo". By default works great in a monorepo, but in reality most of companies running microservices have repo/service setup. How would this work in that case?
Why would you want this for a multirepo? It is for running all your services together. You wouldn't do that for a multirepo anyway.
So many questions left. Please continue describing the topic. For instance how service descovery exactly works. Do you know something about Microsoft Orleans?
What is Orleans?
I could see this as being pretty useful where I work. Just wonder if there is a way to have it load an app into a browser tab by default and focus it, so when testing you don’t have to click the link in the portal to start testing your main project, but can still switch to the portal if you want.
Ok. Now add Aspire to a distributed app composed from a "pure" Angular app (that's it, not using that MS project template) and a .NET API app.
This is largely what Java's Jini platform provided 30 years ago. Here we once again see the masses suddenly feeling like Microsoft is innovating when all they are doing is copying what's already been known, has been done before, and is known computer science. But, since everyone has been just using whatever MS provides, they've been locked out of being this productive for decades already.
Video on how aspire will work on multiple environments like dev , qa , prod ?
this is exciting
Look. I was specialized in C# in 2010 instead of Java, thinking it would replace it. If 20 years of efforts of a monopolistic corporation that comes preinstalled in every computer of the planet, have not been enough to give C# any meaningful adoption... I wouldn't expect it any time soon.
Amazing!
I don't see a Node.js component available (for now?). It would be great to see how this could integrate with Node.js projects.
How do you secure the dashboard. I mean if you run this in a production environment, can you add access rights to it?
And can you also see to it that some environment variables are masked, as in some situations there is one team handling the system and another team handling the development and they aint usually allowed to access passwords but they are interested in seeing logs.
The name including ".NET" kind of makes it seem like it has fundamental runtime changes. I wonder how MS will manage, distribute and organize it alongside the runtime, now that there's an additional .NET subproduct.
this is awesome!
Thanks a lot.
What IDE do you use and what theme for the terminal?
Thanks
hmm does this mean that this only works if everything is in the same solution? Must use a mono repo?
Looks very promising. I wonder will it be possible to run a single project after it's configured as a aspire component? For example, if I want to only quickly debug the api project.
Aspire components are nuget packages, but yes, if you configure your apps with the right configuration, you can still launch them individually.
How would you manage this with 1 repo per microservice? Would you have an aspire repo that submodules all the microservices / apps?
This is probably the most logical answer
Very cool, what do you think the future of this will look like? Will it stick around?
this is amazing
Sounds awesome 👍
But do you think you should use this already like in the example for an api and frontend or only for more complex structures?
Aspire can be useful no matter how big or small your app is, the dashboard in particular provides a lot of great details during development that could be useful to anyone developing a .NET app.
Yep. It’s “cloud native” but the tech is pretty general purpose. A single app with dependencies also works.
Wow. Neat.
Really cool, but what about solutions that are spread across teams, not sharing repos or solutions file?
I remember reading about them adding the workload commands to the dotnet CLI earlier this year, but I feel like it wasn't described why.
I guess it was added because of Aspire, and Aspire was still on the down low. Fair enough