Having come from a strong background in Windows Systems Administration I have always been fascinated with building scalable infrastructure. Today I am going to dive into some of the solutions I have used to build successful distributed infrastructure with IIS.

The typical take on old-school web administration is that if you need to support more users, you will need a bigger server. With the emergence of cloud hosting, it has become a breeze to simply double the server specs and voila you have a bigger boat. Unfortunately, even the largest cloud providers can only scale vertically so far before you are on the largest system they provide. Beyond vertical scale constraints, the largest problem with a single server is fault tolerance. What happens when you need to patch, upsize or install new software? Offline you go.

By distributing web traffic across multiple servers, you gain the flexibility to add and remove servers based on usage along with fault tolerance. In the event you need to patch and apply Windows updates; you can drain the sessions from web servers, reboot and rejoin them to your load balancer, rinse and repeat. The best part is that if your applications are stateless and your load balancer is not using sticky sessions, there is no impact to your users.

This is part of a multiple article series, take a read through the other articles:

Load Balancer

A load balancer does just what you would think; it distributes requests to a set of systems. The challenge with load balancers is “state". Session state is what a server uses to represent a user and remember them across multiple requests. When a website/service is stateless, it means the server does not preserve session state and that any node in a web tier can process a request. Unfortunately, many applications are stateful and do not play nice with round-robin load balancing. Many load balancers solve this by providing “sticky sessions” which tells the load balancer always to send a user’s request to the same server each time. Another option for stateful applications is to store session state in a database or another sort of cache which is not on the application servers.

Stateless applications make your life easier when it comes to building scalable infrastructure. If you're reading this, your application architecture probably lands somewhere between heavily stateful and stateless micro-services. You will need to get creative and identify which applications should need session affinity and how to handle them.

Replication

Each target node in your load balanced application stack must serve up an exact copy of the websites/services to users. Replication is used to maintain the correct version of files between multiple systems. There are quite a few ways to implement replication, but I will focus on a natively supported feature that comes with Windows Server. DFS (Distributed File System) allows you to configure a namespace and join multiple servers as replication members.

An additional benefit of DFS is that it works flawlessly with the IIS Shared Configuration. A replicated IIS Shared Configuration allows you to make a change to a site binding on one system and have that change more or less instantly replicated to all of your other web servers.

Scripted

You will want to be able to spin up additional nodes to handle traffic spikes as quickly as possible. Usually in Windows, spinning up another host is not as simple as taking a backup of a VM and launching a direct copy due to SID and DNS conflictions. I have solved this challenge by writing a series of Powershell scripts to automate the installation of all required Windows Roles and Features, create the file shares, join into the DFS namespace and finally add the node to the load balancer’s target group. Within a few minutes, a new autoscaled system joined the web-tier ready to serve requests. Solving this in Linux can be much simpler, but alas I am a Windows guy living in a Windows world.