The seven pillars every engineering team must address to build cloud-native, independently deployable .NET Core services — covering IIS decoupling, observability, resilience, statelessness, and modern DevOps.

Why This Matters

Monolithic architectures built on IIS served a generation of enterprise .NET applications well — but they were not designed for the demands of modern cloud environments. Development speed slows as codebases grow. A single deployment affects the entire application. Teams cannot release independently. Scaling one component means scaling everything.

Migrating to a microservices architecture on .NET Core addresses all of these constraints, but it demands a deliberate approach. This guide distills the seven foundational technical pillars required to make that transition successfully.

Pillar 1 — Decouple from IIS

Traditional .NET applications are tightly coupled to Internet Information Services (IIS), which limits them to Windows infrastructure. The first step toward a cloud-native architecture is removing that dependency entirely.

The Solution: Kestrel + Self-Contained Deployments

.NET Core ships with Kestrel, a cross-platform, high-performance web server that runs on Linux, macOS, and Windows without any host dependency. When combined with self-contained deployment, each service can be packaged as a standalone executable or container image.

Key benefits of this approach:

• Kestrel runs identically in Docker, Kubernetes, Azure App Service, or on bare metal

• Self-contained executables include the .NET runtime — no runtime installation required on the host

• Container-first design aligns naturally with CI/CD pipelines and orchestration platforms

dotnet publish -r linux-x64 --self-contained true -p:PublishSingleFile=true

This single command produces a portable, self-contained binary ready for containerisation.

Pillar 2 — Observability: Logs, Metrics, and Traces

In a distributed system, understanding what is happening inside a service — and across service boundaries — is not optional. Observability is the foundation of operational confidence.

Structured Logging

Replace unstructured log strings with structured events using Serilog or Microsoft.Extensions.Logging with structured sinks. Structured logs are queryable, indexable, and dramatically easier to correlate across services.

Distributed Tracing

Implement OpenTelemetry to propagate trace context across service calls. This makes it possible to reconstruct the full execution path of a request as it traverses multiple services — invaluable for diagnosing latency or failures in production.

Metrics

Use System.Diagnostics.Metrics (introduced in .NET 6) or EventCounters to emit custom application metrics. Expose a /metrics endpoint compatible with Prometheus or Azure Monitor for scraping and alerting.

Health Endpoints

Implement the ASP.NET Core Health Checks API to expose /health/live and /health/ready endpoints. Kubernetes and load balancers use these to determine whether a service instance should receive traffic.

Pillar 3 — Decentralised Data Ownership

One of the most consequential architectural decisions in microservices is data isolation. Each service must own its data exclusively. This principle is non-negotiable.

Database per Service

Every microservice should have its own dedicated database, schema, or at minimum its own set of tables with enforced access boundaries. No other service should query those tables directly.

• Prevents tight coupling through shared data models

• Enables each service to evolve its schema independently

• Eliminates cross-service joins — inter-service data requirements are fulfilled through well-defined APIs or event-driven communication

For large-scale migrations, start by creating dedicated schemas within an existing database, then graduate to separate database instances as team boundaries solidify.

Pillar 4 — Resilience and Reliability

In a microservices environment, failures are not exceptional events — they are expected. A service will occasionally be slow, unavailable, or unreachable. The critical requirement is that a failure in one service does not cascade and bring down the entire system.

Essential Resilience Patterns

• Detect repeated failures and stop sending requests to a degraded downstream service for a configurable period, giving it time to recover: Circuit Breakers

• Automatically retry transient failures — network glitches, brief timeouts — with increasing delays to avoid overwhelming a recovering service: Retries with Exponential Backoff

• Every outbound call must have an explicit timeout. Without one, a slow dependency will exhaust thread pool resources and bring down the caller: Timeouts

• Limit the number of concurrent requests to any single downstream service, preventing one slow dependency from consuming all available resources: Bulkhead Isolation

builder.Services.AddHttpClient<IOrderService, OrderService>()

    .AddStandardResilienceHandler();  // Polly v8 — retry + circuit breaker

Microsoft.Extensions.Http.Resilience (Polly v8) provides these patterns out of the box for HttpClient in .NET 8+.

Pillar 5 — Statelessness

Stateful services — those that store session data, cache data in memory, or write to the local file system — cannot be scaled horizontally. A request routed to a different instance will not find the expected state.

What to Externalise

• Move to a distributed cache such as Redis using IDistributedCache. ASP.NET Core supports this natively: Session State

• Use Redis or Azure Cache for Redis instead of IMemoryCache for any data that must be consistent across instances: Application Cache

• Replace local file system writes with Azure Blob Storage, AWS S3, or equivalent object storage: File Storage

• Relational (SQL Server, PostgreSQL) and document stores (Cosmos DB, MongoDB) remain valid for persistent application data: Database State

Stateless services enable horizontal scaling, efficient load balancing, and graceful recovery from instance failures. Any instance can handle any request.

Pillar 6 — Modern DevOps Automation

The architectural improvements above deliver their full value only when paired with automated deployment pipelines. Manual deployments are a bottleneck and a risk.

CI/CD Pipeline Requirements

• Automated build and test on every pull request — unit, integration, and contract tests

• Containerised builds using multi-stage Dockerfiles to produce minimal, secure images

• Automated image tagging and publishing to a container registry (Azure Container Registry, Docker Hub, etc.)

• Blue/green or rolling deployments to eliminate downtime during releases

• Automated rollback triggered by health check failures or elevated error rates

GitHub Actions, Azure DevOps Pipelines, and GitLab CI all support these patterns natively for .NET Core services. The goal is a pipeline where merging to main is sufficient to deploy to production safely.

Summary: The Seven Pillars at a Glance

Closing Thoughts

Modernising a .NET application for the cloud is not a single event — it is an incremental journey. These seven pillars provide a structured framework for that journey. Teams can address them in phases, validating each improvement before moving to the next.

The result is an architecture that is genuinely cloud-ready: independently deployable, horizontally scalable, resilient by design, and fully observable in production.