My First look at .NET Aspire. What's with the Hype?
ฝัง
- เผยแพร่เมื่อ 11 มิ.ย. 2024
- Follow along as I take a look at .NET Aspire. I've been hearing a lot about it, but is it worth the hype? Good question! I haven't used it or really read much about it in detail so here's my first look and first impressions.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via TH-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - วิทยาศาสตร์และเทคโนโลยี
Great honest review! Local development is definitely where we add the most value! We’ve got lots of feedback as to where to spend time improving (multi repo etc etc). Deployment will be a longer journey but we will get there!
One of the big advantages that people are beginning to realize is the extensibility. We’re seeing people build some very cool things by extending the model.
Ya, for a new project for local dev, I see the value. Although I'm still trying to wrap my mind around not using it for production and how you have service discovery for local, but then for production end up having to use whatever that may be depending where it's hosted. There's a mismatch there I'm trying to find a solution to and can't think of. How would that work?
Personally I find the standalone Aspire dashboard to be more interesting. I see it as being very useful with local dev / docker-compose scenarios so that I can get visibility into my OTEL data during local development but then replace it with an enterprise grade APM solution for staging and production environments.
To me Aspire seems to be one of those things that can make previously straightforward things super trivial and previously complicated things next to impossible. At least for the time being. If you're not familiar with microservices and you're starting a new microservice based project, it can save you a lot of time. But then again you probably shouldn't start a completely new project using microservices if you don't have enough experience with them. Or even if you do. Imho you should resort to a distributed architecture only once it's absolutely necessary and there's no reasonable way to avoid it.
This video is my first look at Aspire and I think I can ignore it for while (maybe forever)
I recently converted my solution to Aspire - 20+ projects. I'm glad that I had my own service defaults. But it was so tedious to do.
I had been using Tye before, and I liked it, but switched to Docker Compose when that experiment ended. I kind of miss the YAML now.
I've been playing around with it and I think it has a lot of promise but it falls just short right now. Specifically when it comes to testing, I'd like to use the same AppHost configuration to spin up instances of my dependencies for integration tests and to configure test services like you can with WAF. It feels very all-or-nothing right now but hopefully, it'll be more flexible in the future.
I've been using a combination of docker/compose/makefile to simplify local setup and I don't think I can walk away from it yet. However I might use both Aspire and my current tooling together in my next greenfield project to get a better sense.
They are adding in WAF testing stuff - there's a big github comment thread and a sample what's to come. I agree - without that, can't use it.
I really liked the Orleans example but the big problem I see is everything being one big solution. First I don't like gigantic solutions hard to use and navigate. Second multiple teams setup where I don't run everything in Debug because it's some others team responsibility. I am not sure how this will scale.
I've been playing with it for a couple of weeks since GA.
The local dev experience is nice so far, though I haven't tried it on a large microservices implementation.
I think there is value add with the C# layer of abstraction on top of docker. I don't care what ports are what, I just want to say which services can talk to what. That's a problem it seems to solve.
ServiceDefaults is really nice to have. It seems like a solution that could be shipped outside of Aspire, maybe, but it's nice to get some recommended defaults for those cross-cutting concerns.
The deployment story is not there yet. It works if you want to use the exact default resource types, but customizing things gets a bit gnarly. infra synth to bicep or using unstable APIs in C#.
We are working on locking down the PublishAsAzure...(....) APIs that enable fine tuning of resources. Feedback heard it is something that is on our priority list. We are working with the Azure SDK team on this.
That giggle at th-cam.com/video/maVXnkYEDIE/w-d-xo.htmlsi=j86VSrADgTAwqrkP&t=23 We already know Fowler's brain is connected to Twitter, he's in the matrix already
Meh... If you're a billy who's just starting out with microservices it might be useful - but is it "better" or does it solve a problem that didnt exist? I'd sit on that fence
Still need to look at this more, my gut reactions to this were a concern about centralized configuration and not quite understanding how or if various teams working on parts of a system would or could use this. It feels like a solition in search of a real problem. Really feels like DevDiv is being asked to try hard to influence devs to use more azure instead of solving real problems. Apologies for the sinicism, I've just been doing this too long. Maybe it will be the next big thing and i'll see the light, as of now though I'm not convinced.
Not all devs are in a situation where there needs to be cross-team consideration, and could benefit from the velocity a platform like this affords smaller start ups and projects.
@@PraiseYeezus why the fuck would they need distributed microservices then 😂
@@MiningForPies because they work on an ecommerce platform in a small team that need to scale services separately because of black friday coming up? Source: real life
Hi @awright18 as @davidfowl indicated above, how we work across multi-repos is a work in progress (we took some initial steps in GA and we'll improve that over time). The workflow that works for you depends a lot more on your organizational structure.
For example, lets say you have an organization where each service/cluster of services are managed by a seperate team, but there are well defined connections between them. Then you might have mutliple repos, each one with a AppHost that helps that service team build and debug the things that they are repsonsible for. Where those services have interdependencies then you can use things like builder.AddConnectionString(...) to reference those external dependencies (just depends on protocols etc).
As teams mature they might find some benefits of having lightweight versions of services that their partner teams can use for debugging locally and so they have things like builder.AddPaymentGateway(...) that allows a partner team to have a payment gateway emulator that they just plug into their services for debugging purposes.
Teams that are more tightly coupled might tackle it a different way. Our goal is to provide building blocks to help people work the way they want. Where we don't have the right shape blocks yet we see that as a potential set of features we can add.
@@PraiseYeezus yeah ok lol. 😂
Cause that’s so common. There’s thousands of shitty little companies that go viral a couple of times a year and need to scale quick 🤣
The standalone aspire dashboard is the easiest way to see Opentelemetry data locally. Using it daily already.
Not sure about the rest of aspire. Feels like there's potential here but also feels like this might turn into yet another excuse to do microservices in the wrong context.
I’ve been using the jaeger all in one container locally for at least 3 years. No need for aspire.
@@DanielGraham655t didn't try Jaeger yet but the aspire dashboard is also just a docker container so super easy to setup in just minutes.
Welcome to IaaS
It's just pointless right now. I was hyped for dapr and that turned out pretty bad when i tried to actually use it but aspire is not even on the level of dapr. It reminds me more of service fabric, which was truly awful.
What's with the Hype?
There is no hype. It's literally just Fowler tweeting about his newest framework pet project because he wants to make it a thing.
Hell yeah
Isn't this supposed to beef up your local development? I think you are missing the point with Aspire.
I think local is where I see the value. That's what I mentioned in the video. It's docker compose in code. For some that might be valuable. Where I'm missing the value is deployment.
@@CodeOpinion okay I get you.
I'll continue to work as a C# Dev for work, but C# is too much for side projects which is why I've moved on to Go
I don't see a lot of value on aspire at this moment.
I’ve used it in anger.
It’s decent enough, but it’s maintained by a knob (David Fowler is horrendously arrogant and unhelpful).
It’s a solution to Microsoft’s problems (a bit like azure which is overpriced hosting).
It’s nowhere near production ready.
Perfect workflow is for developing with dependencies, avoiding docker compose for local is ideal.
Most people won’t benefit though, as if you’re running real microservices it doesn’t work well across teams.
"avoiding docker compose for local is ideal" why? genuinely curious, wanting to get into using containers for my current project
@@Ry4nWTF visual studio support for docker compose is weird. I’ve never liked it. MS do their usual and make things work under the hood that often go wrong and are difficult to diagnose.
Sorry I was unhelpful 😅
@@Ry4nWTF FWIW, using docker compose works well at my work. We have multi-repo and a central docker compose file. It's like 10 lines of yaml per service, most of which is just setting environment variables for config, not exactly difficult, and then you can just docker compose up. You can also just start a specific service and its dependencies. We use renovate to keep the versions of images up to date. As well as local dev, we also use this to run integration tests easily in pipelines. In prod we use k8s.