If a requirement is not described fully, perhaps it's not important to the question being asked. Notice that the exam guide highlights fail-over right next to elasticity. Why would that be the case? Well, consider this example. A client comes to you and says, "We're happy with our data center solution. We want to use the cloud, but only for fail-over and disaster recovery. Can you help?" So, you provide an IT solution in the cloud that gives them a disaster recovery scenario and fail-over capabilities. So, if elements of their existing solution go down, the cloud can provide an alternative. Some time goes by and the client comes back to you with an additional request. "The fail-over solution is working great, but we have another problem. Sometimes we get demand above our capacity and we don't want to invest in more data center capacity. Can you help us burst into the cloud so when we have extra demand, we can use the cloud for temporary extra capacity?" You modify some of the elements that you built for fail-over and you give them cloud bursting capability. So, there is the elasticity. Some more time goes by and the client isn't happy with their colo. They're paying for racks and they don't want to pay more and the equipment needs a refresh and they ask you for some help, "Can you help us migrate our application fully to the cloud so we can scale more dynamically to meet growth?" Of course you help them. Now, this is a very common adoption pattern. This is a natural and orderly progression of events. Now, you see why they're located together in the exam guide. For the exam, you need to think about what you would measure in the situation. You might not need to calculate anything, but knowing what you need to be measured will help you focus on what information is important in this question. Architectural principles. Compose simple services and evolve them, plan to avoid conditions that would lead to failure such as bottlenecks, consider the hardware or service limitations in the cloud, but also plan for resiliency and fast recovery when failure occurs. Consider the time value of the result of the solution. Here's an example. If a data processing job takes 3,000 years to run, the proposed method might not fit the business requirements and an alternate solution might be better. An old business saying, in business, all values are real-time values. Meaning that you might want to determine when a metric might change or how this will affect the value to the business. So, time value, what happens if the solution is delivered sooner or later? In a design class, we often say that all values are real time. In this case, constant value might not have any additional value if it's delivered earlier or later. Here's example two. This is a solution that has additional value if delivered sooner. So, the sooner it's delivered, the more value it provides. In example three, it's a solution that has diminishing value if it's delivered late. An example four has a solution that has no value if it's not delivered on time. One example would be an online ordering system tied to an event. If it's ready early, it provides no value because the customers are not ready to take orders and if it comes in a day late, then the customers will no longer be interested. Always take note of state information and consider the impact of storing and retrieving state information on scalability. All work in all systems can be divided up into job shops and assembly lines. In a job shop, a single server, service, or unit performs multiple steps. In an assembly line, each server, service, or unit performs one well-defined step and hands the work off to another worker for the subsequent steps. Food preparation can help illustrate these principles. Here's an assembly line kitchen. Each person is responsible for a specific action. One person places one kind of food on the plate, another puts on the sauce, a third places the garnish. On the one hand, there's not much to remember because each person individually just does one discrete thing over and over again. So, there isn't much state information. But what this model requires is coordination. If something happens and one person changes what they're doing, the line has to adjust. If a person in the middle takes a break, everyone further down the line stops working and the work queues up from the workers earlier in the line. However, this approach can really be worthwhile because each individual can focus on being really fast and efficient at their task. So, this model scales very well. In this instance, there is a single chef who's doing all of the steps, placing the food, adding the sauce, garnishing, so forth. The chef needs to remember what step was just performed and what step needs to happen next. They may need to change tools or fetch different resources. All of that information needs to be remembered for the work to proceed is called state information. Just exactly how much state information is required and where the state information is stored has a huge influence on scalability. just to recap, a job shop has to keep track of where it is in the process and that's the state information. The assembly line doesn't need to keep track of state. However, the units or microservices have to coordinate with each other. So, queuing and messaging becomes important as an alternative to keeping state. You can't get away from state in all cases. In those cases, you have to try to make state scalable and reliable and that leads to another common design pattern you'll want to know. Familiarize yourself with common design patterns, not just what they are, but how they work. It can come in handy to imagine the question in the context of a solution. For example, dividing the problem solution into front-end and back-end, stateless and stateful can be very helpful in surfacing the key design issues. There are resources, for example, architectures in our online documentation. The design shown is a general solution. It doesn't fit all cases, but is very common. First there's a scalable front-end with fail-over. Second are many small stateless servers for back-end scalability. Third, is the state information isolated and separated from the front and back-end.
