When a scale out triggering event occurs, the infrastructure expands its capacity through the appropriate bursting mode, either auto scaling or cloud bursting.

There is no feedback in the system from the usage of the new capacity to tightly control the amount of resources added or decommissioned from the service based on real world service utilization. A model of the service is used to determine the appropriate scaling activities.

For example, a basic model of our service says that for every 100 active sessions we require one virtual machine in our web tier to provide a 100ms transaction time. Capacity planning data tells us that we need to support 1000 active sessions during weekdays and 250 active sessions on weekends.

During the weekdays the environment scales to 10 virtual machines in the web tier (1000 sessions/100 sessions per virtual machine), and on weekends it scales to three virtual machines in the web tier (250 sessions).

The model describes how many virtual machines per 100 sessions, but it does not account for rogue sessions that might consume significantly more resources than the typical session. It also does not account for transient spikes in resource consumption that might occur, causing our 100 sessions per virtual machine model to be incorrect. In this scenario, the open loop control method does not account for the real-world state of the system, and the end-user experience degrades.