Pros and Cons of Building an API on .NET Framework on IIS, .NET 9 on IIS, and .NET 9 on Linux

This comparison focuses on performance, connection handling, scaling strategy, migration path, cost, and long term support.


1. .NET Framework on IIS

Pros

Mature Enterprise Platform

  • Long history in enterprise environments
  • Deep Windows Server integration
  • Stable IIS hosting model

Integrated Windows Features

  • Native Windows Authentication
  • Tight Active Directory integration
  • Mature monitoring tools

Cons

End of Major Innovation

  • No active feature evolution
  • Performance improvements limited
  • Modern libraries target .NET Core and .NET 9

Windows Only

  • Requires Windows Server licensing
  • Higher infrastructure cost
  • No native Linux or lightweight container support

Performance and Concurrency Limits

  • Thread per request model is heavier
  • Async support less efficient than ASP.NET Core
  • Higher memory consumption under load

Under high concurrency, worker threads block more easily. Thread pool exhaustion occurs faster than modern runtimes.


Connection Handling and Scaling

Connections

  • IIS manages connection queue
  • Each request consumes managed threads
  • Higher memory per connection

High connection volume increases memory pressure and reduces throughput.

Scaling Strategy

Primarily vertical scaling:

  • Increase CPU
  • Increase RAM
  • Increase server size

Horizontal scaling requires:

  • Load balancer
  • Session state externalization
  • Manual configuration

Scaling beyond a few instances becomes complex and expensive.


Migration Considerations

  • Requires full framework rewrite to move to .NET 9
  • API surface differences significant
  • Configuration model changes

Migration cost can be high for large legacy systems.


2. .NET 9 on IIS

ASP.NET Core runs behind IIS using the ASP.NET Core Module. IIS acts as reverse proxy. Kestrel handles request processing.


Pros

Modern Runtime

  • Efficient async pipeline
  • Lower memory per request
  • Better CPU utilization

Improved Connection Handling

Kestrel supports:

  • Event driven async IO
  • Efficient handling of thousands of concurrent connections
  • HTTP 2 and HTTP 3 support

Compared to .NET Framework, concurrent request capacity increases significantly.

Incremental Migration Path

  • Easier port from .NET Framework
  • Keep IIS infrastructure
  • Migrate service by service

Cons

Windows Licensing Cost

Still requires Windows Server.

Dual Layer Hosting

  • IIS reverse proxies to Kestrel
  • Two configuration layers
  • Slight performance overhead

Connection Handling and Scaling

Connections

  • IIS terminates connection
  • Kestrel processes request
  • Async IO reduces thread blocking

Under high load, connection density per node improves significantly compared to .NET Framework.

Scaling Strategy

Supports both vertical and horizontal scaling.

Horizontal scaling options:

  • IIS load balancing
  • Azure App Service scale out
  • Windows containers

Still heavier than Linux containers due to OS footprint.


Migration Considerations

  • Most controllers port with minimal changes
  • Middleware replaces HttpModules
  • Configuration moves to appsettings and environment variables

Lower migration friction compared to full rewrite from .NET Framework to Linux.


3. .NET 9 on Linux

ASP.NET Core runs directly on Kestrel, often behind Nginx or a cloud load balancer.


Pros

Highest Performance per Node

  • Lightweight OS
  • Efficient async networking
  • Lower memory footprint

Benchmarks consistently show higher requests per second compared to Windows hosting under identical hardware.

Superior Connection Density

Linux networking stack and Kestrel support:

  • Large concurrent socket counts
  • Lower memory per connection
  • Efficient epoll based event handling

Better suited for high traffic APIs with long lived connections such as WebSockets or streaming.

Cloud Native Scalability

  • Native Docker support
  • Optimized for Kubernetes
  • Rapid pod scaling
  • Rolling deployments without downtime

Lower Cost

  • No Windows Server licensing
  • Smaller VM sizes required
  • Better container density

Cons

Operational Shift

  • Linux administration skills required
  • Different logging and monitoring stack

Windows Specific Integration Gaps

  • Integrated Windows Authentication requires extra setup
  • Legacy Windows only libraries unsupported

Connection Handling and Scaling

Connections

Kestrel handles connections directly.

Advantages:

  • Fully async request pipeline
  • Minimal thread blocking
  • High concurrency per CPU core

Suitable for:

  • High RPS APIs
  • Real time systems
  • Streaming workloads

Scaling Strategy

Primarily horizontal scaling:

  • Add containers
  • Add pods
  • Auto scale based on CPU or queue depth

Stateless design simplifies scaling. Session state typically externalized in Redis or database.

Scaling to dozens or hundreds of instances becomes operationally simple.


Scaling Comparison Overview

flowchart TD
A[.NET Framework IIS] -->|Vertical Focus| B[Limited Horizontal Scaling]
C[.NET 9 IIS] -->|Hybrid Scaling| D[Improved Horizontal Options]
E[.NET 9 Linux] -->|Horizontal Native| F[Cloud Optimized Scaling]

Support Lifecycle

.NET Framework

  • Maintenance mode
  • Security fixes only
  • Long term but no innovation

.NET 9

  • Active development
  • Regular performance improvements
  • Modern support lifecycle with defined LTS releases

Linux and Windows both supported equally at runtime level in .NET 9. Platform choice affects infrastructure support, not runtime feature parity.


Summary of Key Differences

Performance Highest. .NET 9 on Linux High. .NET 9 on IIS Lowest. .NET Framework on IIS

Connection Handling Most efficient. .NET 9 on Linux Strong. .NET 9 on IIS Heaviest per connection. .NET Framework

Scaling Flexibility Best. .NET 9 on Linux Moderate. .NET 9 on IIS Limited. .NET Framework

Migration Complexity Lowest incremental path. .NET 9 on IIS Higher infrastructure shift. .NET 9 on Linux Highest rewrite cost. .NET Framework to modern stack


Strategic Guidance

For new APIs expecting high traffic:

  • Choose .NET 9
  • Prefer Linux for maximum scalability and cost efficiency

For gradual enterprise modernization:

  • Use .NET 9 on IIS
  • Migrate incrementally

Avoid starting new systems on .NET Framework unless legacy constraints require it.

Ryan Stevens

Software Systems Architect