Cloud is typically associated with outcomes such as lower cost, speed, and simplicity, yet cloud can be very complex even in its most basic form. For example, a single server can have many attributes that must be considered. How many cores? How much RAM? How much storage? Is it a virtual server or a physical one? What operating system? What type of connectivity? Is the server on a shared or dedicated environment? What about going serverless? What about containers?

The answers to these seemingly simple questions have a drastically different economic impact and a huge effect on strategy. Each attribute feels somewhat technical in nature, yet they are more about economics and how economics affect strategy. Why would virtual servers be chosen over physical? Better utilization? Isn't utilization really about maximizing the use of an expensive resource? Virtualization allows for the acquisition of only what is needed for as long as needed. Not really. Virtualization has been around since the 1960s. Recent billing innovations are what allow partial resources to be consumed in very short increments of time. Virtual servers can be deployed faster. True,  but why does that matter? Physical deployments are very manual, expensive, time-consuming, and potentially filled with human error. Virtual machines can be deployed very quickly and programmatically, eliminating much of the expense, time, and effort associated with deployments.

Virtualization and its benefits are well known. Designs using virtualization have been around for several years now. What is so different? For the first time, we see economic models driving design decisions, for example, reserve instance versus current market rate. Reserve instances require a large upfront fee with a very low monthly fee. What situations are better suited for a longer-term commitment with significant money up front? What strategy does this line up with? How does this affect risk? With the high fees up front and longer commitment requirements, reserve instances are better suited for persistent workloads with fairly flat traffic patterns. Cyclical or seasonal traffic patterns do not fit here, as resources would be paid for when they were not being utilized fully. A major change, as mentioned earlier, is that designs can now be created for the low point with burst or up-cycle moves to support increases in the traffic pattern.