The next thing that I want to say is a bit about upgrades. These terminologies, you've heard of; availability, which is saying what is the fraction of time that a particular system is up and running? Availability is something that may be subject to contractual obligations. So for instance, Google may say that for my business clients, I guarantee 99.9 percent uptime for their service. So it's giving you availability guarantee. That means that if they don't satisfy that, then they may have to either repay the client or whatever. So it's very important that availability is something that is kept up by the system. That plays into what we mentioned about the reliability earlier. So in order to make sure that a system is available, you have to ensure that there's enough redundancy so that you can meet the availability guarantees that you're providing. But in addition to failures that can happen, there is also online evolution of the system that's happening all the time. So the Gmail that you're using today is not the same as what you used yesterday or the day before. So constantly, software is getting upgraded. Similarly, the cloud resources that are in the data centers, that are constantly being upgraded as well. If there are failures happening, you're taking out old fail components, putting in new components. Every couple of years, you maybe changing the rev of the processors. So all of these things, changes are happening. How do you make sure that you can meet availability criterion in the presence of this online evolution? Online is very important, meaning that you're not bringing down the system as a whole, but you are continuing with the system execution while you're doing the growth or upgrade or whatever you're doing. So there's going to be capacity loss because of the fact that you're doing online evolution. The question is, how much time do you have the capacity loss? So one way to do that is if I have n servers, I can simply bring down all of them and then upgrade the software upgrades that I'm doing or hardware upgrade, whatever it is, I'm going to do it one shot and then reboot everybody. That's called the fast reboot. What you see in the time here is the time that you're losing per node. The area under this is the total amount of capacity loss that you're incurring because of the fact that a server is down. This total area that you see here, that's the total capacity loss because of a fast reboot. So that is one way of doing it. This is sometimes a meaningful way to do it if you use diurnal property that, well, maybe this time in parts of Asia is asleep and therefore, let's bring down the servers catering to them so that we can upgrade it. I mean, everybody is up all the time, so I don't know what is off peak and what is peak. So that may be hard to do. But that is one way of doing online evolution. Another way of doing online evolution is what is called a rolling upgrade. If you have four servers, I'm not bringing all four servers at the same time, I'm taking one server down, upgrading it, and then taking the next one down, next one down, next one down and so on. That way, I keep the service always available at a reduced capacity. The capacity loss is only this much every unit of time, the upgrade time period, but we're stretching out the time it takes for the upgrade to be done on all the servers, that is what is called a rolling upgrade. So here, we are losing the capacity for a certain amount of time. All of the servers here, you're using only one nth of the capacity for a certain period of time till the upgrade is done. This is sometimes referred to as a wave upgrade. The last one is what is called a big flip. I mean, this is particularly the way data centers work when they physically relocate a data center from one location to a different location. What they'll do is they will bring down half the servers, upgrade it, then the next half of the servers is upgraded. So this is what is called a big flip, where you're going in between these two extremes, between a fast reboot and a rolling upgrade by reducing the amount of time when you don't have the latest and greatest service available, and also reducing the amount of capacity that is lost in order to do this online evolution. But regardless of which attack you take, you see that the loss is the same for all three strategies. It is the loss per node, the upgrade time that it takes, times the number of servers, that's a total loss that you're going to incur. Whether you incur it in one shot or spread over time, or in a big flip manner, it is all the same. So this is the thing that happens in which you are losing availability of the system for a certain amount of time. There is always this availability versus upgrade conundrum. Software upgrades are absolutely essential because you want to make sure that you're providing the best service. That gives you a competitive advantage to your peers. Rolling upgrade is usually recommended to avoid service downtime because you don't want the system to be completely unavailable. But it assumes that the changes maintain backward compatibility because that is one of the assumptions in doing this. Suppose you say that, "Well, I have to completely change the software." Then it is not going to work as a rolling upgrade. Upgrades in general, it affects availability guarantees. So you have to very carefully orchestrate the upgrades to make sure that you do the upgrade because that agility of upgrading is important for competitive edge with respect to your peers. But at the same time, you have to respect the SLAs that you have guarantees that you've made to your business applications to ensure that you're meeting those SLAs in spite of all these updates happening.
