Back to Blog

.NET and Azure for Enterprise Applications

April 23, 2025•5 min read•Michael Ridland

Every few years, someone declares .NET dead. And every few years, I look at our client list—banks, insurers, government agencies, enterprises—and they're all running .NET.

The reality: .NET isn't sexy. It doesn't generate Twitter hype. But for serious enterprise applications in Australia, it's often the right choice. Here's why, and how to do it well.

Why .NET for Enterprise

Let's be honest about the trade-offs.

.NET advantages:

  • Mature, battle-tested framework
  • Excellent tooling (Visual Studio, debugging, profiling)
  • Strong typing catches errors early
  • Azure integration is seamless (same company)
  • Enterprise support and long-term stability
  • Large talent pool in Australia
  • LINQ is genuinely great for data manipulation

.NET disadvantages:

  • Windows heritage (though .NET Core changed this)
  • Historically slower iteration than Node/Python ecosystems
  • Can feel heavyweight for simple projects
  • Microsoft ecosystem lock-in risk

For enterprise—where reliability, maintainability, and long-term support matter more than cutting-edge features—the trade-off usually favours .NET.

The Modern .NET Stack

.NET has evolved dramatically. Modern enterprise apps typically use:

Runtime: .NET 8 (LTS) or .NET 9 Web framework: ASP.NET Core minimal APIs or MVC ORM: Entity Framework Core (or Dapper for performance-critical paths) Authentication: Azure AD / Entra ID Messaging: Azure Service Bus or RabbitMQ Caching: Redis Hosting: Azure App Service, AKS, or Azure Container Apps

This stack handles serious scale. We've built systems on this architecture handling millions of transactions daily.

Azure Architecture Patterns

Pattern 1: Web App + API Backend

The simplest architecture for most applications:

[Frontend SPA] → [Azure API Management] → [App Service (API)] → [Azure SQL]
                                                              ↘ [Blob Storage]
                                                              ↘ [Redis Cache]

Use this when:

  • Team is smaller (<10 developers)
  • Traffic is predictable
  • You don't need independent service scaling

We used this pattern for Coast Smoke Alarms' platform. Simple, reliable, cost-effective.

Pattern 2: Microservices with AKS

For larger, more complex systems:

[API Gateway] → [AKS Cluster]
                    ├─ [Service A]
                    ├─ [Service B]
                    ├─ [Service C]
                    └─ [Service D]
                          ↓
                [Service Bus] → [Background Workers]
                          ↓
                [Cosmos DB / SQL / Storage]

Use this when:

  • Multiple teams working independently
  • Services have different scaling needs
  • You need deployment isolation
  • Complexity is justified by scale

Warning: microservices are expensive in complexity. Don't adopt them for a 3-person team building a straightforward app.

Pattern 3: Serverless Event-Driven

For event-heavy, variable-load workloads:

[Event Source] → [Event Grid] → [Azure Functions]
                                      ↓
                              [Cosmos DB / Storage]
                                      ↓
                              [Logic Apps / Notifications]

Use this when:

  • Workload is spiky/unpredictable
  • Lots of integrations with external systems
  • Cost optimisation matters more than consistency
  • You're okay with cold start latency

Common Pitfalls

Pitfall 1: Over-engineering from Day One

I've seen teams spend months building "enterprise-ready" architecture for an app with 50 users. Start simple. Add complexity when you need it.

Rule of thumb: if you can't name a specific problem your architecture solves, you don't need that architecture yet.

Pitfall 2: Ignoring Azure Costs

Azure pricing is complex. Easy to get surprised.

Watch out for:

  • Egress charges (data leaving Azure)
  • Premium storage tiers you don't need
  • Over-provisioned App Service plans
  • Cosmos DB RU consumption
  • Log Analytics ingestion costs

We've seen clients cut Azure bills by 40% just by right-sizing resources and using reserved instances.

Pitfall 3: Premature Microservices

Microservices solve organisational problems (team independence) not technical problems (most of the time).

A well-structured monolith is fine for most applications. Split when:

  • Different services need different scaling
  • Different teams own different parts
  • Deployment coupling is causing problems

Until then, modular monolith is your friend.

Pitfall 4: Not Using Managed Services

Azure offers managed versions of almost everything: databases, caching, messaging, search. Use them.

Self-managing a PostgreSQL cluster on VMs to save money is a false economy. The operational overhead exceeds the cost savings.

Pitfall 5: Authentication Complexity

Azure AD (Entra ID) is powerful but complex. Common mistakes:

  • Rolling your own auth when Azure AD would work
  • Mixing authentication strategies unnecessarily
  • Not understanding token lifetimes and refresh
  • Ignoring service-to-service authentication

Get authentication right early. It's hard to retrofit.

Performance Patterns

Caching Strategy

Request → Check Redis Cache → Cache hit? Return cached
                           → Cache miss? Query database → Store in cache → Return

Cache liberally, but:

  • Understand cache invalidation for your data
  • Monitor cache hit rates
  • Have fallback for cache failures

Async Processing

Long-running operations should be async:

API receives request → Validate → Queue message → Return 202 Accepted
                                       ↓
Background worker → Process → Update status → Notify

Use Azure Service Bus for reliability. Queue storage for simple cases.

Database Performance

Entity Framework is convenient but can be slow. Patterns that help:

  • Use .AsNoTracking() for read-only queries
  • Project to DTOs instead of loading full entities
  • Use compiled queries for hot paths
  • Consider Dapper for performance-critical operations
  • Index strategically based on query patterns

Monitoring and Observability

Non-negotiable for enterprise:

Application Insights: Request tracking, dependency monitoring, exceptions Log Analytics: Centralized logging with KQL queries Alerts: Proactive notification of issues Dashboard: Real-time visibility into system health

Set up monitoring before you need it. You don't want to add observability during an outage.

Security Considerations

Enterprise apps handle sensitive data. Minimum requirements:

  • Azure AD authentication (not custom auth)
  • Managed identities for service-to-service
  • Key Vault for secrets (no secrets in config)
  • Private endpoints for databases
  • TLS everywhere
  • Regular dependency scanning
  • Audit logging for sensitive operations

Australian enterprises often have additional requirements around data sovereignty (keeping data in Australian regions) and regulatory compliance.

Our Experience

We've been building .NET enterprise applications for over a decade. Recent projects include:

  • Field service platform handling thousands of daily work orders
  • Banking and fintech applications with strict compliance requirements
  • Healthcare systems with patient data protection

We're not religious about technology. Sometimes Node.js or Python is the right choice. But for enterprise systems that need to run reliably for years, .NET and Azure are hard to beat.

Talk to us about your enterprise application needs.