Last year, I shared my thoughts on the importance of Developer Experience (DX) in software development and how it directly affects productivity. Building on that discussion, we started working on a new platform called Mews Atlas—designed to help teams ship code faster while keeping everything secure and compliant. To kick things off, we introduced automated scripts using Docker Compose to manage local environments and simplify development. This initially boosted developer productivity. However, as more teams joined the mix, we faced challenges with expanding our component offerings and keeping the scripts updated.
During Microsoft’s presentation of .NET 8 last year, I experienced a “lightbulb moment” when .NET Aspire was introduced. The presentation was truly inspiring, especially the demonstration of the framework’s orchestration features. I was amazed by how effortlessly it could manage multiple dependencies within a .NET project with just a few lines of code. It quickly became clear that this new framework could address our challenges by providing a simple and standardized way to orchestrate local development environments.
In this post, I’m excited to share my journey with .NET Aspire, the changes we’ve made, and the positive impacts we’ve seen so far.
What is orchestration and .NET Aspire?
Before diving into the details of our journey, let me explain what we mean by orchestration and how .NET Aspire fits in. In the context of software development, orchestration refers to the process of managing and coordinating different components of an application, such as databases, messaging systems, and other services, ensuring they work together seamlessly. This is critical for modern applications that rely on multiple systems working in sync.
.NET Aspire simplifies this orchestration by allowing us to define and manage these components within our .NET projects using a standardized approach. Instead of manually configuring scripts and environments, Aspire helps automate and streamline the setup, making it easier for developers to manage dependencies like databases and message queues. The result is a more efficient, consistent development environment that reduces the need for manual intervention.
We do not plan to use its cloud deployment capabilities, as we are continuing to use Pulumi for managing infrastructure as code. This allows us to keep our local development setup simple while addressing our cloud needs separately.
Introducing Mews Atlas
Mews Atlas is our new platform designed to help development teams at Mews ship code faster and more securely. It provides a unified environment where developers can work efficiently while ensuring that all services remain compliant and scalable. The goal of Atlas is to streamline the development process, offering the necessary tools and infrastructure to enhance productivity across teams. By standardizing workflows and managing dependencies, Atlas empowers developers to focus on delivering high-quality features with less overhead.
With Atlas, our focus on improving DX required us to rethink how we manage the growing number of components and services, which is where .NET Aspire came into play.
Challenges with our previous approach
As we developed Mews Atlas, it became clear that relying on custom Bash and PowerShell scripts had its downsides. What began as a straightforward solution evolved into a landscape with various script versions as our services multiplied.
When more teams joined, the demand for new components increased. We had a limited set of components at the time and no immediate plan for expanding them. The building blocks available for our code were more than we could effectively mock, making it tough to test scenarios like message queues. Plus, developers had to be comfortable with Bash, PowerShell, and Docker to extend the scripts, which added extra complexity. The lack of a standardized way to manage these scripts didn’t help either.
All these factors showed us that we needed a more scalable approach to support our growing needs.
Discovering .NET Aspire
During Microsoft’s presentation of .NET 8, I experienced a “lightbulb moment” when .NET Aspire was introduced. Aspire simplifies the orchestration of local development environments, making it easier to manage dependencies with minimal configuration. It addresses crucial aspects like component communication, resilience, health checks, and observability.
By adopting Aspire, we could move away from our complex script-based approach and instead rely on a more consistent, standardized framework to orchestrate our development environments across multiple teams.
Our implementation journey
Establishing a Golden Path
We’ve created a “golden path” for local development, which is a recommended workflow for all developers. This guideline aims to boost efficiency, cut down on errors, and improve teamwork. While it’s encouraged to follow this path, it’s not mandatory; developers can explore different approaches if they find something that works better for them.
Practical integration examples
We plan to leverage the official documentation of .NET Aspire to create practical integration examples for components like SQL Server, Redis, Kafka, etc. This will help developers get started without dealing with complex configurations. By using existing resources, we can avoid reinventing the wheel and make sure our examples align closely with Microsoft’s documentation.
Do you have experience with adopting .NET Aspire (or a similar framework)?
Let’s talk!
Consistent developer experience
We’ve also extended the .NET Aspire workload to the monolithic Mews backend. This move will provide developers with a standardized development environment across services, making it easier to switch between the monolith and the Atlas Services. Importantly, we can use the features of .NET Aspire with our existing code building blocks, minimizing the impact of this change by only replacing the orchestration part while keeping the rest intact.
Ongoing positive changes and outcomes
While our initiative to adopt .NET Aspire is still in progress, we don’t have extensive results or measurable impacts to share yet. However, we’re optimistic about several positive outcomes in the immediate future:
Enhanced developer experience
As more teams start using .NET Aspire, we expect improvements in onboarding and overall productivity. New team members should quickly set up their environments, allowing them to focus on delivering value rather than troubleshooting setup issues.
Community and Collaboration
We believe the transition to .NET Aspire will encourage better collaboration among teams. With a standardized framework, developers will be able to support each other more effectively, creating a more cohesive working environment.
Understanding the limitations of .Net Aspire
Of course, no tool is perfect, and .NET Aspire is no exception. It’s tailored primarily for Microsoft technologies like Azure and Visual Studio. While it provides powerful solutions for many scenarios, it’s not a one-size-fits-all tool. We remain mindful of how we integrate .NET Aspire into our workflows, particularly when it comes to deployment pipelines and infrastructure management. For cloud deployment, we continue to rely on Pulumi for managing infrastructure as code.
The future of DX at Mews
In summary, our ongoing journey to adopt .NET Aspire has transformed our development processes. The framework has simplified our workflow and enhanced the overall Developer Experience. While we’re still in the early stages of adoption and measurement, I’m excited about the potential benefits on the horizon. I encourage you to share your experiences with similar transitions and join the conversation on how we can continuously enhance DX.
