‫Hey, welcome back.
‫Availability is one of the most important quality attributes
‫of a large scale system.
‫So in this lecture, we're going to talk about the importance
‫of high availability,
‫how to define and measure availability in general
‫and later we will talk specifically,
‫about what constitutes high availability of a system.
‫So, let's start talking about the importance
‫of high availability.
‫Availability is one of the most important quality attributes
‫when designing a system.
‫Because arguably it has the greatest impact
‫on both our users and our business.
‫When it comes to users, we can only imagine the frustration
‫of a user trying to purchase something from our online store
‫but when they type in the URL of our service in the browser,
‫the page just doesn't load.
‫Or maybe it does load but when they go to checkout
‫instead of getting a confirmation, they get an error.
‫Similarly, if we're an email service provider,
‫we can only imagine the impact
‫of everyone losing in their access to their email
‫for a few hours or even a whole day.
‫On that note, if we are a company that provides services
‫to other companies instead of to end users,
‫the impact of a prolonged outage in our services
‫is compounded.
‫A very famous example of that,
‫is the AWS simple storage, four hour outage
‫in February, 2017.
‫Because hundreds of companies
‫and more than a hundred thousand websites
‫were using that service,
‫it's safe to say that that kind of outage
‫almost took down the entire internet.
‫But system downtime is not always just an inconvenience.
‫In case our software is used for mission critical services
‫like air traffic control in an airport for example,
‫or to help manage the healthcare of patients in a hospital,
‫if our system crashes or becomes unavailable
‫for an extended period of time,
‫we potentially have people lives on the line.
‫Now, from the business perspective,
‫the consequences of our system going down are twofold.
‫First of all, if the users cannot use our system
‫then our ability to make money, simply goes to zero.
‫Now, the second consequence is when the users lose access
‫to our system for too long or too frequently,
‫they will inevitably go to our competitors.
‫So, essentially when our system goes down
‫our business may lose both money and also its customers.
‫Now, that we got a feel of how important it is
‫for our system to be available,
‫let's proceed with defining availability
‫a bit more formally.
‫We can define availability as either the fraction of time
‫or the probability that our service
‫is operationally functional and accessible to the user.
‫That time that our system is operationally functional
‫and accessible to the user,
‫is often referred to as the 'uptime' of the system.
‫While the time that our system is unavailable to the user,
‫is commonly referred to as 'downtime'.
‫Availability is usually measured as a percentage,
‫representing the ratio between the uptime
‫and the entire time our system is running,
‫which is the total sum of uptime and downtime of the system.
‫Now, as a side note, sometimes uptime and availability
‫are used interchangeably.
‫So, if you read in an agreement
‫and you see that uptime is described in percentages
‫and not as an absolute time,
‫they simply talk about availability instead.
‫Another alternative way to define
‫as well as estimate availability
‫is using two other statistical metrics, the MTBF and MTTR.
‫MTBF, which is the meantime between failures,
‫represents the average time our system is operational.
‫This metric is very useful,
‫if we're dealing with multiple pieces of hardware
‫such as computers, routers, hard drives and so on,
‫where each component has its own operational shelf life.
‫Typically though, if we're dealing with an existing service
‫like a cloud service provider or a third party API,
‫those services usually give us their general uptime
‫and availability upfront.
‫So, we don't really need to make any calculations.
‫MTTR, which stands for meantime to recovery,
‫is the average time it takes us to detect
‫and recover from a failure,
‫which intuitively is the average downtime of our system.
‫Because until we fully recover from a failure,
‫our system is essentially nonoperational.
‫So the alternative formula for the availability of a system,
‫is MTBF divided by the sum of MTBF and MTTR.
‫Feel free to post the video
‫and convince yourself that this formula makes sense.
‫And conceptually, is very similar to the previous formula.
‫Now, because this formula is more statistical
‫and talks about probabilities,
‫it's much more useful for availability estimation
‫rather than actual measurement of availability.
‫Now, one very important aspect
‫that we can see in this formula,
‫which we cannot easily see in the previous formula
‫is if we minimize the average time to detect
‫and recover from a failure,
‫theoretically all the way to zero
‫then we essentially achieve a 100% availability
‫regardless of the average time between failures.
‫Of course, in practice
‫we cannot get the recovery time completely to zero.
‫But make a mental note of the effect detectability
‫and fast recovery has on availability,
‫as this serves as a clue
‫on one way we can achieve high availability.
‫Now, how much availability should we aim for?
‫Obviously, 100% availability is what our users would want.
‫But on the engineering side, it is extremely hard to achieve
‫and essentially it leaves us with no time
‫for either planned or emergency maintenance or upgrades.
‫So, what would be an acceptable number
‫that still provides our users with high availability?
‫Before we try to answer this question,
‫let's look at a few percentages of availability
‫and try to get a feel of what that measure means
‫for our users.
‫Let's start with a 90% availability
‫which may seem like a pretty high number
‫but if we look at the table
‫we see that with that availability,
‫our users may not be able to use our system
‫for more than two hours every day or for more than 36 days
‫which is more than a month out of an entire year.
‫So, intuitively we already see,
‫that this cannot be considered high availability.
‫Now, what about 95% availability?
‫Well, that's definitely better
‫but still one day of downtime every month
‫or one hour of every day is not considered high enough
‫for most use cases.
‫So, there's no strict definition
‫of what constitutes high availability
‫but the industry standards set by cloud vendors
‫is generally anywhere between 99% to 100%.
‫Typically at 99.9% or higher.
‫If we look back at our availability table
‫that means that their service may be unavailable
‫for less than one and a half minutes per day,
‫which would not be very noticeable
‫but it still leaves out eight hours
‫of emergency maintenance work, every year if needed.
‫To make discussions about availability a bit easier,
‫percentages are also sometimes referred to
‫by the number of nines in their digits.
‫So for example, 99.9% would be referred to as three nines.
‫99.99% would be referred to as four nines and so on.
‫Now, before we move on to learning about concrete strategies
‫on how to achieve high availability,
‫let's quickly summarize what we learned in this lecture.
‫In this lecture,
‫we learned the importance of high availability
‫both from a user and business perspective.
‫Specifically, we mentioned the two risks
‫that our business faces,
‫if our system goes down for prolonged periods of time
‫or too frequently.
‫Which are the loss of revenue,
‫as well as the potential loss of customers
‫to our competitors.
‫After that, we defined availability as the fraction of time
‫or probability that our service is operationally functional
‫and accessible to the user.
‫And later, we learned about the two formulas to measure
‫and estimate the system's availability.
‫One using the uptime and downtime of a system
‫and another using the meantime between failures
‫and meantime to recovery.
‫Finally, we defined high availability
‫as three nines or above,
‫based on the standard that the cloud vendor set
‫in the industry.