Как Microsoft Aspire пытается навести порядок в хаосе распределенных приложений

Представьте, что вы запускаете новый проект. У вас есть фронтенд на Vite, бэкенд на Node.js, база данных Redis для кэша и еще пара микросервисов. В первый же день вы тратите пару часов на настройку Docker Compose, прописывание переменных окружения, портов и строк подключения. А потом коллега скачивает репозиторий, и у него всё ломается, потому что версия Node.js не та или порт 6379 уже занят локальным Redis. Знакомая история?

Microsoft представила проект Aspire, чтобы решить именно эту приземленную проблему: как заставить кучу разрозненных сервисов работать вместе без боли при локальной разработке и деплое.

Что это вообще такое

Aspire — это не очередной облачный провайдер и не замена Docker. Это инструмент (оркестратор для разработки), который позволяет описать всю архитектуру вашего приложения прямо в коде. Вы буквально пишете на C# или TypeScript, какие сервисы у вас есть и как они связаны.

Самое приятное здесь то, что Aspire берет на себя скучную работу. Он сам найдет свободные порты, прокинет нужные Connection Strings между сервисами и поднимет контейнеры с базами данных. При этом вам не нужно вручную ковыряться в YAML-конфигах, если вы этого не хотите.

Код вместо бесконечных конфигов

Основная фишка Aspire — концепция AppHost. Это центральный проект, который служит «клеем» для всего остального. Посмотрите, как лаконично выглядит описание связки Redis, API и фронтенда:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

// Добавляем Redis одной строчкой
const cache = await builder.addRedis("cache");

// Описываем API и говорим, что оно зависит от кэша
const api = await builder
    .addNodeApp("api", "./api", "src/index.ts")
    .withReference(cache)
    .waitFor(cache)
    .withHttpEndpoint({ env: "PORT" });

// Цепляем фронтенд к нашему API
await builder
    .addViteApp("frontend", "./frontend")
    .withReference(api)
    .waitFor(api);

await builder.build().run();

Здесь нет магии. Метод withReference автоматически передает настройки подключения из одного сервиса в другой через переменные окружения. Если Redis перезапустится на другом порту, Aspire сам обновит конфиг API.

Зачем это нужно практикующему разработчику

Я часто вижу, как команды мучаются с Service Discovery на локальных машинах. Aspire решает это «из коробки». Вот еще несколько вещей, которые делают его полезным:

1. Единая панель управления. Когда вы запускаете Aspire, открывается браузерный дашборд. Там видно логи всех сервисов в одном месте, состояние ресурсов и, что самое крутое, трассировку OpenTelemetry. Вы видите путь запроса от фронтенда до базы данных без настройки Grafana или Jaeger.
2. Умный запуск. Параметр waitFor гарантирует, что ваше приложение не упадет с ошибкой «Connection refused» просто потому, что база данных еще не успела проснуться.
3. Мультиязычность. Несмотря на то что проект вышел из недр .NET команды, он отлично дружит с Node.js, Python и обычными Docker-контейнерами. Можно собрать «зоопарк» технологий и управлять ими одинаково.

Как попробовать у себя

Установка простая. Для Windows используется PowerShell:

irm https://aspire.dev/install.ps1 | iex

Для Linux или macOS стандартный curl:

curl -sSL https://aspire.dev/install.sh | bash

После этого у вас появится CLI-инструмент aspire. В репозитории лежат шаблоны, с которых можно быстро стартовать, не изобретая велосипед.

Архитектурные нюансы

Внутри Aspire опирается на Developer Control Plane (DCP). Это слой, который оркеструет процессы и контейнеры на вашей машине. Важно понимать: Aspire не заставляет вас использовать Azure. Хотя у него отличная интеграция с Azure Container Apps, вы можете генерировать манифесты для Kubernetes или просто использовать его как удобную «запускалку» для локальной разработки.

Кстати, в репозитории microsoft/aspire лежит не только CLI, но и весь SDK, код дашборда и расширение для VS Code. Проект живой, коммиты летят каждый день, а комьюнити в Discord активно обсуждает новые интеграции.

Стоит ли внедрять это сейчас

Если вы пишете монолит, Aspire вам вряд ли пригодится — это будет стрельба из пушки по воробьям. Но если в проекте больше трех компонентов (например, фронт, бэк и база), профит ощущается сразу.

Главный минус на данный момент — порог входа. Нужно привыкнуть к мысли, что инфраструктура описывается кодом на C# или TS. Для тех, кто привык к чистому Docker Compose, это может показаться избыточным. Но возможность видеть распределенные трейсы и логи всех микросервисов в одном окне без настройки сложной инфраструктуры перекрывает эти сомнения.

Подойдет тем, кто устал от «актуализации» README с инструкциями по запуску проекта и хочет, чтобы команда нажимала одну кнопку F5 и сразу приступала к работе.