analysis

Nov 6, 20258 mins

Microsoft’s Aspire development framework has dropped .NET from its name and moved to a new website, as it is now becoming a general-purpose environment for building, testing, and deploying scalable cross-cloud applications. Aspire has already proven to be a powerful tool for quickly creating cloud-native C# code. Is it ready to support other pieces of the modern development stack?

I’ve looked at Aspire before as it’s long been one of the more interesting parts of Microsoft’s developer tools, taking a code-first approach to all aspects of development and configuration. Instead of a sprawl of different (often YAML) files to configure services and platforms, Aspire uses a single code-based AppHost file that describes your application and the services it needs to run.

Along with the platform team at Microsoft, the growing Aspire community is developing an expanding set of integrations for what Aspire calls resources: applications, languages, runtimes, and services. There’s a standard format for building integrations that makes it easy to build your own and share them with the rest of the Aspire community, adding hooks for code and OpenTelemetry providers for Aspire’s dashboard.

Making Aspire cross-language

How does Aspire go from a .NET tool to supporting a wider set of platforms? Much of its capability comes from its architecture and its code-based approach to defining the components of your applications.

Using AppHost to bring together your code is the key to building polyglot applications in Azure. It lets you mix and match the code you need: a React front end, a Python data and AI layer, and Go services for business logic. You define how they’re called and how they’re deployed, whether for test or for production, on your PC or in the cloud.

Such an approach builds on familiar tools. There’s no difference between instantiating a custom Go application in a container and doing the same for an application like Redis. The only difference is whether you use a Microsoft-provided integration, one from the growing Aspire community, or one you’ve built yourself.

If you want to use, say, a Node.js component as part of an Aspire application, use the Aspire command line (or Visual Studio) to add the Node.js hosting library to your project. With a prebuilt application using Express or a similar framework, your AppHost simply needs to add a call to Aspire’s builder method using AddNodeAppfor an application or AddNpmAppfor one that’s packaged for Node’s package manager.

Node.js needs to be installed on your development and production systems, with code providing an appropriate REST API that can be consumed by the rest of your application. If you have other JavaScript code, like a React front end, it can be launched using the same tooling, packaging them all in separate Docker files.

An important piece of Aspire’s polyglot future is the Aspire Community Toolkit. This is a library of tools for hosting code and integrating with services that may not be in the official release yet. It gives you the tools to quickly extend Aspire in the direction you need without having to wait for a full internal review cycle. You get to move faster, albeit with the risks of not being able to use official support resources or of working with features that may not be quite ready for production.

If you use features from the Aspire Community Toolkit in your AppHost, you’re able to start with cutting-edge tools to build applications, like the Bun and Deno JavaScript/TypeScript environments, or you can work with memory-safe Go and Rust code. You can even bring in legacy Java code with support for a local JDK and popular enterprise frameworks like Spring.

There’s a long list of integrations as part of the Aspire Community Toolkit documentation, covering languages and runtimes, multiple container types and containerized services, and additional databases. If you want to use a specific client for a service, the toolkit includes a set of useful tools that can simplify working with APIs, including using popular .NET features like the Entity Framework. There is support for using Aspire to work with mock services during development, so you can connect to dummy mail servers and the like, swapping for live services in production.

Aspire Community Toolkit integrations began life as new custom integrations, which you can use to create your own links to internal services or to external APIs to use in your Aspire applications. For now, most integrations are written using .NET, adding custom resources and configurations.

At the heart of an integration is the Aspire.Hosting package reference. This is used to link the methods and resources in a class library to your Aspire integration.

Adding custom integrations

Building a new hosting integration starts with a project that’s designed to test that integration, which will initially be a basic AppHost that we’ll use to connect to the integration and display it in the Aspire dashboard. If you run the test project, you’ll see basic diagnostics and a blank dashboard.

Next, we need to create another project to host our new resources. This time we’re creating a .NET class library, adding the Aspire.Hosting package to this project. While it’s still blank, it can now be added as a reference to the test project. First make sure that the class library is treated as a non-service project by editing its project reference file. This will stop the project failing to run.

We’re now ready to start writing the code to implement the resource we’re building an integration for. Resources are added to the Aspire.Hosting.ApplicationModel namespace, with endpoint references and any necessary connection strings. This is where Aspire code will integrate with your new resource, providing a platform-agnostic link between application and service.

Your project now needs an extension method to handle configuration, using Aspire’s builder method to download and launch the container that hosts the service you’re adding. If you’re targeting a static endpoint, say a SAP application or similar with a REST API, you can simply define the endpoint used, either HTTP or a custom value.

With this in place, your new integration is ready for use, and you can write code that launches it and works with its endpoints. In production, of course, you’ll need to ensure that your endpoints are secure and that messages sent to and from them are sanitized. That also means making sure your application deployment runs on private networks and isn’t exposed to the wider internet, so be sure to consider how your provider configures its networking.

You can simplify things by ensuring that your integration publishes a manifest that contains details like host names and ports. Once you have a working integration, you’re able to package it as a NuGet package for sharing with colleagues or the wider internet.

Moving from a .NET-only Aspire to one that supports the tools and platforms you want to use makes a lot of sense for Microsoft. Cloud-native, distributed applications are hard to build and run, so anything that simplifies both development and operations should make a lot of developers’ lives easier. By adopting a code-based approach to application architecture and services, Aspire embodies key devops principles and bakes them into the software development process.

For now, there will still be dependencies on .NET in Aspire, even though you can build integrations for any language or platform—or any application endpoint, for that matter. There are some complexities associated with building integrations, but we can expect the process to become a lot simpler as more developers adopt the platform and as they start to share their own integrations with the community. This is perhaps key to this change of direction in Aspire. If it is to be successful as a polyglot application development tool, it needs to have buy-in, not only from its existing core developers, but from experts in all the languages and services it wants to consume so that we are able to build the best possible code.

Building a bigger community of engaged contributors is key to Aspire’s future. Emphasizing features like the Aspire Community Toolkit as a way for integrations to graduate from being experiments to being part of the platform will be essential to any success.

Contributing Writer

Author of InfoWorld’s Enterprise Microsoft blog, Simon Bisson prefers to think of “career” as a verb rather than a noun, having worked in academic and telecoms research, as well as having been the CTO of a startup, running the technical side of UK Online (the first national ISP with content as well as connections), before moving into consultancy and technology strategy. He’s built plenty of large-scale web applications, designed architectures for multi-terabyte online image stores, implemented B2B information hubs, and come up with next generation mobile network architectures and knowledge management solutions. In between doing all that, he’s been a freelance journalist since the early days of the web and writes about everything from enterprise architecture down to gadgets. He is the author of Azure AI Services at Scale for Cloud, Mobile, and Edge: Building Intelligent Apps with Azure Cognitive Services and Machine Learning.

More from this author