Outside the Cloud (data centers and VPS), the underlying computing resources are:
- Effectively fixed because obtaining new resources requires months.
- They are scarce because we try to buy the minimum resources needed.
- Expensive since we have to pay them entirely and amortize them.
But in the Cloud, the underlying computing resources are abundant and fast to provision and this change the rules of the game and deserve a mindset change.
In the Cloud we should:
- Consider the servers/disks/databases as disposable resources, treated as "just one more". This concept is called Pets vs Cattle and even if I don't like the analogy too much, it is true that it is interesting to read about it: The History of Pets vs Cattle and How to Use the Analogy Properly
- Always assume that anything will fail and design for it. The Cloud is based on commodity hardware that is not under our control and allows us to create massive scale systems. Due to the scale, we experience partial failures all the time (machines go down, disks broke, network fail...). As we can not predict at this scale, the best approach is to design for failure and improve the resilience of our system continuously.
- Define the infrastructure as code to allow rapid iteration. You can learn more about this concept in this previous blog post Immutable infrastructure (tech pill).
- Design to take advance of the elasticity of the Cloud. This includes architect for horizontal scalability so you can scale during peak hours without paying for this capacity during low activity hours.
- Pay per use and rent not buy. When we design for the Cloud, we should try to use the resources as much as possible and deal with the variability in the load using the elasticity. The mindset should be, rent the most suited resources for the task and release them as soon as possible.
In summary, understanding the Cloud providers APIs and services is only a small part of your journey to the Cloud. The most critical step is to change your mindset and accept new underlying assumptions.
A new engineering challenge
Construct a highly agile and highly available service from ephemeral and assumed broken components. (Adrian Cockcroft)