## DESIGN DOCUMENT: NEW DOTNET ASPIRE MICROSERVICES & SUPPORTING ARCHITECTURE

### 1. OVERVIEW & OBJECTIVES
- Modernize our platform by building brand-new microservices with Dotnet Aspire.
- Keep legacy websites (MA, MP, AI, and CD) and their existing databases on Helm without migrating or disrupting stable production workloads.
- Introduce and standardize new infrastructure components for the Dotnet Aspire microservices:
– Pub/Sub Queues for asynchronous messaging
– S3 (or S3-compatible) for image storage
– Redis for caching account/profile data
– PostgreSQL for internal microservice data
- Ensure easy integration with our current observability stack: Icinga, Grafana, and Sentry.
- Maintain the flexibility to deploy on-prem or in any public cloud (cloud-agnostic) without forcing a single vendor.

### 2. CURRENT LEGACY LANDSCAPE
- Websites MA, MP, AI, & CD: Legacy applications deployed with Helm.
- Existing Databases: DB MA, DB MP, and corresponding DBs for AI and CD, each tied specifically to their respective websites.
- No additional microservice-oriented infrastructure is currently in place beyond these websites.
- No standardized messaging platform or centralized object storage configured for new services.

### 3. PROPOSED NEW ARCHITECTURE

#### 3.1 Dotnet Aspire–Based Microservices
- Why Dotnet Aspire?
– Suited for Modern, Fast Iterations: Less overhead than forcing Helm for every new service.
– Cloud-Agnostic: Containers built with .NET can run on any Kubernetes distribution, on-prem or in the cloud.
– Modular & Maintainable: Encourages a microservices pattern that’s easier to scale and evolve independently of legacy sites.
– Built-In Coordination & Persistency: Dotnet Aspire provides concurrency primitives (e.g., “WaitFor”) that help coordinate asynchronous tasks, ensure ordered execution, and persist intermediate state when needed—particularly useful in event-driven architectures.

#### 3.2 Pub/Sub Queue Introduction
- Add a pub/sub messaging platform (e.g., RabbitMQ, NATS, or Kafka) for asynchronous data exchange among new microservices and, optionally, the legacy websites.
- Benefits:
– Decouples the Architecture: Reduces direct dependencies and synchronous calls.
– Improves Reliability & Scalability: Handles high throughput, supports horizontal scaling.

#### 3.3 S3-Based Image Storage
- Shift away from storing images locally on servers; store them in an S3 or S3-compatible system (e.g., MinIO).
- Benefits:
– Scalability & Reliability: Offloads backups and replicates data easily.
– Reduced Server File Management: Cleaner deployment model—application servers become stateless.

#### 3.4 Redis Cache for Account Data Service
- Use Redis for data frequently queried by the new microservices—such as account details or profile metadata.
- Benefits:
– Improves Response Times: In-memory lookups are very fast.
– Minimizes Hits on Legacy Databases: Relieves load from DBs MA, MP, AI, and CD if basic user data is cached.

#### 3.5 Dedicated PostgreSQL Database
- Launch a fresh PostgreSQL instance specifically for the new Dotnet Aspire microservices.
- Benefits:
– Clear Separation from Legacy DBs: Lowers migration risk or schema conflicts.
– Widely Supported: Runs easily on-prem or in any major cloud (AWS RDS, Azure Postgres, GCP Cloud SQL, etc.).

### 4. AVOIDING HELM FOR NEW MICROSERVICES
- Rationale:
– Helm Overhead: Maintaining charts, templating, and versioning for small or fast-growing services slows CI/CD and complicates developers’ workflows.
– Autonomy for Teams: Dotnet Aspire microservices can have simpler container-based deployments (plain Kubernetes YAML, Kustomize, Terraform)—no large chart repos required.
– Legacy Separation: The legacy websites remain on Helm, but we don’t saddle new services with that baggage.

### 5. MONITORING & OBSERVABILITY
- Existing Monitoring Tools:
– Icinga: System/network monitoring and health checks.
– Grafana: Visualization and dashboarding tool for metrics.
– Sentry: Error tracking, alerting, and performance monitoring.

- Integration Steps with Dotnet Aspire:
- Metrics & Health Checks:
– Expose a standard /metrics or health endpoint from each Dotnet Aspire microservice. Icinga can periodically poll these endpoints, and Grafana can display metrics from Prometheus or another aggregator.
– .NET’s built-in health checks can be wired to Icinga the same way.
- Error & Performance Tracing:
– Sentry .NET SDK can automatically capture exceptions, performance spans, and track user impact in real time.
– Developers get immediate alerts on critical errors when new microservices misbehave.
- Dashboard Unification:
– Metrics from Dotnet Aspire services can be ingested into Grafana to sit alongside existing Helm-based app dashboards.
– Avoid separate silos by using the same monitoring cluster or aggregator for logs, metrics, and alerts.

### 6. IMPLEMENTATION PLAN

#### 6.1 Phase 1 – Infrastructure Setup
- Provision a dedicated PostgreSQL instance (or cluster) and Redis environment.
- Deploy your chosen pub/sub platform (Kafka, RabbitMQ, or similar).
- Configure an S3 or on-prem S3-compatible system (e.g., MinIO) for image/object storage.

#### 6.2 Phase 2 – First Dotnet Aspire Microservice
- Develop a small “Account Updater” or “Miaderator” service that demonstrates pub/sub integration, S3 usage for file storage, Redis caching, and the new PostgreSQL DB as the source of record.
- Containerize and deploy via minimal Kubernetes manifests (no Helm).
- Integrate with Icinga (health checks), Grafana (metric dashboards), and Sentry (error alerts).

#### 6.3 Phase 3 – Expand and Integrate
- Add more microservices (e.g., group them by domain or business function).
- Ensure each microservice uses the standardized approach:
– Dotnet Aspire for code,
– Pub/sub for messaging needs,
– Redis for caching,
– PostgreSQL for persistence,
– S3 object storage for any file data.
- Connect to legacy websites only where needed, ideally via asynchronous queues or small bridging REST endpoints.

#### 6.4 Phase 4 – Optimization & Maturation
- Tune resource usage, autoscaling settings for Redis, PostgreSQL, and pub/sub.
- Evaluate whether to standardize security scanning, secrets management, etc., across both new and legacy stacks.
- Decide if/when to tackle partial migrations of the legacy Helm-based apps, depending on results and ROI.

### 7. DOTNET ASPIRE VS. HELM: PROS & CONS

Below is a quick comparison of Dotnet Aspire for new microservices and Helm for legacy deployments:

• Dotnet Aspire (New Microservices)
– Pros (Major):
1. Lightweight Deployments: No templating overhead for each new microservice.
2. Built-In Coordination (e.g., “WaitFor”): Simplifies concurrency and persistency for asynchronous service ups.
3. Cloud-Agnostic: Runs anywhere Docker/Kubernetes can be deployed.
4. Rapid Development: Small teams can iterate quickly with minimal friction.
– Cons (Minor):
1. Fewer Helm-Like Structures: Teams used to Helm might require some adjustment in pipeline setups.
2. Possibly Smaller Community for “Aspire”-Specific Features: Mainstream .NET resources are vast, but some Aspire-specific patterns may be less documented.

• Helm (Legacy Websites MA, MP, AI, & CD)
– Pros (Minor):
1. Well-Known In-House: The Infra team is already experienced with Helm.
2. High Adoption in the Kubernetes Ecosystem: Many existing charts and relevant community support.
– Cons (Major):
1. Chart Maintenance Overhead: Templating, versioning, and packaging can be heavy for small/fast-changing services.
2. Slower CI/CD: Each new service or update can require chart rewrites or merges, reducing developer velocity.
3. Risk of “Chart Bloat”: Multi-purpose or shared charts can get overly complex.

### 8. CONCLUSION
This architecture positions our new microservices to be truly cloud-agnostic, leveraging Dotnet Aspire for rapid development with minimal overhead. By adding pub/sub messaging, S3 storage, Redis caching, and a dedicated PostgreSQL database, we create a modern, scalable, and flexible environment—without forcing immediate changes to the stable legacy Helm deployments. The integration with Icinga, Grafana, and Sentry ensures that operators can manage the new services alongside the existing infrastructure in a unified way. Over time, this approach can extend to gradually unify or replace legacy components, as business needs dictate, while retaining the benefits of Dotnet Aspire’s built-in coordination and simplicity.