This is not meant to spin up a production environment. It is meant to make it easier for developers to create a local dev environment and cloud dev environment. There is also an alpha tool infrasynth to get the bicep files. This would be a great starting point for the infra and devops people to create test and production environments.
As other have said .NET Aspire has nothing to do with deployment, the team itself has mentioned that the main purpose of .NET Aspire is in the development realm, to facilitate development of Distributed Cloud systems, reducing the need of configuring everything manually, improving productivity and centralizing development configuration. The deployment manifest is just a bonus so we can test the apps beyond dev.
Development of distributed cloud systems without a deployment strategy? .Net aspire ends at the manifest file, the problem starts at consuming it, for example terraform doesn’t parse json. I like aspire, I think the tooling is the worst part but its early days we’ll see how it pans out..
@@RawCoding Yeah terraform does not consume it yet, the manifest is by design created so that 3rd parties who want to take advantage of it can create their own tools.
@@RawCoding While watching your video I kept thinking you were comparing Aspire to another set of development tools and a deployment workflow that already works better for you. I would be interested to see a follow-on video from you that demonstrates a better alternative to Aspire.
@@RawCoding >Development of distributed cloud systems without a deployment strategy? There are a lot of tooling and effort put into deployment strategies for distributed apps already. As others has mentioned, Aspire is focusing on better developer experience. Makes it a lot easier to clone a project and get it up running on your local machine.
I disagree, Aspire is not over-hyped at all. It does not form any opinion around deployment, so its incorrect to suggest otherwise. AZ is leveraging it to generate BICEP definition files and we use ACA, so it's a great fit. As for roll-back, that's got absolutely nothing to do with Aspire, we maintain our own, and separate CICD services that track and manage roll-back. I have been testing this with our services and love the local dev experience. It's early days but I am seeing unnecessary integrations that I didn't know were occurring, such as not leveraging cached results (in some scenarios) with acquire access tokens. We are using this with Dapr, and will utilize AZ support for ACA deployment. I am sure Aspire will be enriched over time with increased adoption.
I concur. The problem is that for many viewers this video will represent someone's first introduction to Aspire when in fact it is a broad critique that Aspire is a partial solution for production calibre deployment pipelines, something it is not designed to do. It would be like criticizing the design of an Airbus A320 for sinking after an hour following an unplanned landing on the Hudson River. The simplified cloud deployment story enabled for Aspire is just a developer convenience for injecting a .Net distributed application direct from desktop into the cloud. The Azure Container Apps target is a perfect fit for this objective.
It's for orchestration yet working with multiple repos isn't supported... How do I get this set up for my 134 repos with services, IDPs, cache providers etc?
I think that this tool (same as tye) could be great for spinning up local development environment and for now I don't see any advantage to use it in other scenarios
It’s more than just a tool tbh. The aspire manifest file becomes a single light weight file that describes all components in your solution, including interoperability and how they communicate. There’s awesome power in that.
Great summary and I fully agree that Aspire should stay out of deployment. I suspect MS agrees and has included `azd provision` and `azd deploy` mostly for demo purposes. It would be very interesting to hear your opinion on their observability integrations (logging, metrics and tracing). How flexible is this system and how much do you get out of the box?
Yeah Aspire doesn’t really do deployment, its bad wording on my part. As im mostly unhappy with the tooling im really shitting on azd here, but thats what aspire provokes it needs the tooling around it to get there. As for telemetry “observability” its pretty good. And the way the api in .net is setup itll just work.
I kind of agree with that. In my opinion the published json manifest with all the configurations is all you need to then port everything fairly easily to almost any CI tool.
I don’t know about that, ill have to investigate. My hunch is that having to handle the intermediary format twice for iac and deployment is more work than templating variables.
Made it to 12:52. A screencap of that frame should be the thumbnail of the video so the watcher knows what kind of meandering stream of consciousness he is in for.
Well the documentation never mentioned micro services. Maybe this is only for the local environment and local testing (I think this is also what was demoed) and for staged deployment you use what you are using now.
For me you don't have to judge a product at its first version. Also, Microsoft stated that this is only the beginning of a journey. If Aspire will grow from both Microsoft, vendors and the community could become a great tool for develop microservice applications
Using Aspire and aspir8 and focusing on ephemeral deployments is what this is for. I think saying aspire is for simple projects and fixating on how this tools attempts to deploy to prod deployment is a misunderstanding of what problems its solving. Bc no one should actually be deploying to prod that easily via a cli. This is clearly a tool for self serving environments for developers testing a new feature, or qa easily having an environment spun up and spun down is what the azd integration is for.
I have yet to try aspire, but I always loved the docker-compose integration of VS and Rider. If it's doing just that with a bit more features on top, then I feel like I could like it. But the entire dev-ops-as-a-service thing? I don't think that this is very useful. I know very little projects which are published on a click-once basis without a custom pipeline behind it.
Та же история. Для локальной разработки это вредно, потому что напрочь отучает разработчиков думать и понимать что как должно быть связано. Для деплоя это не подходит совершенно.
.Net Aspire is for local dev and testing. It has nothing to do with deployment. Microsoft Radius is for deployment. As for vendor lock in, notice the name is ".NET" Aspire.
perfect explanation, might not look useful as it is now but I can see where it can evaluate in future. Still there are container management systems like Kubernetes where we can create relationships between containers, manage them and visualize relations. Aspire can be nice tool if it creates infrastructure for microservice relations and can be deployed on other platforms than Azure
Interesting video, thanks!! 12:15 I doubt long term it will be bicep only, that’s not their style these days IMHO. Sure, easy buttons for the MSFT stack but not lockin.
