Document comparison to Nitric

[flcdrg]

A colleague (@nootn) told me about https://nitric.io which appears to have some similar/overlapping goals to Aspire. Could be useful to document similarities and differences for anyone who is looking to decide between the two.

[davidfowl]

I am so happy to see more of these popping up! That said, I've never heard about it and this is the first time someone has asked 😄 .

TL;DR: Nitric is a more opinionated layer of abstraction over the cloud than what aspire is.

PS: This looks very cool. First glance:

• It looks a lot more complete on the deployment side of the house (taking advantage of pulumi and terraform, we have similar aspirations, pun intended).
• Unclear if it works with existing frameworks (the video mentions integrations for nest and hono for node specifically)? The integrations look deep, but I don't see any examples showing non nitric application code. Maybe that means its more opinionated?
• Unclear if there's anything built into the dev experience for telemetry (otel based). There's a nice dashboard https://nitric.io/docs/get-started/foundations/projects/local-development that has a first class experience for the resources offered in the platform.
• Multicloud with an extensiblity model. Very similar to what we're building right now.
• Hot reload (at least for the JavaScript version).
• Single file for both infra and app code? Looks nice but a little confusing understanding what infrastructure will pop out of this. I like navigating to an aspire apphost and seeing the self documenting layout of the infra all in a single place (but I am biased). Look at how beautiful that is

The goal and motivations behind these projects are extremely similar, Nitric looks even more opinionated than aspire and looks like it's optimized for building cloud native apps (they are also building a framework full of runtime components that are not just integrations). The architecture looks really interesting as well, extremely similar to the way aspire works internally (run vs publish mode and the provider model). Very impressive stuff.

Reminds me of https://www.winglang.io/ but not a new language 😄.

Philosophically the approach is very different in aspire:

1. We don't have any cloud abstractions, we just let you program against integrations that represent the actual service directly and sprinke some configuration and telemetry magic on them. This is a fundamental design choice.
2. We lean heavily into modeling your infrastructure, but at a level understandable to the developer and in a way that doesn't obscure the underlying service (we expose role assignments for azure resources, you can break glass easily by setting the guid if you know it directly). If you want to model a container app environment and an app service environment and kubernenetes at the same time that should be possible.

That avoids cliffs. The nitric, wing and dapr approach is one based on abstractions and implementations on local vs different clouds. Not saying one is better than the other in all cases but it's one fundamental difference with the approaches.

I think in time, when aspire is more capable (in a couple of months) it'll be possible to build more opinionated frameworks like this on top of the core aspire platform. What we will have will be much more extensible.

https://medium.com/@davidfowl/making-software-like-lego-how-aspire-brings-the-pieces-together-d6a99c2c4cde

I'll be posting more about the philosophy and implementation, stay tuned!