Several years ago, I purchased a digital “smart” thermostat for my home. I wanted to be able to set the temperature remotely, and check on it while I wasn’t there. I set it up and connected it to the manufacturer’s cloud backend. All was fine, or so I thought.A couple weeks later, I received an email from the manufacturer about an upcoming upgrade to its service. During the time of the upgrade, which would last several months, the company would bring down its application “for many hours at a time,” and would do so at “various times of the day” (those times were not specified). The company, of course, apologized for the inconvenience ahead of time.What? So at seemingly random times, my thermostat was going to stop working for many hours at a time, and this would go on for months? I don’t think so. The next day, I replaced the thermostat with one from another company. There is no way I was going to deal with that level of bad service.Availability matters.In order to receive certain benefits, my son has to report his income to the US government. To do that, he uses an application on his cell phone. Once a month, he logs into the application to report his income for the previous month. This iPhone application, however, has a major problem with it. When you launch the application at the wrong time, it shows you a message: “This application only works between the hours of 8am-5pm ET, Monday-Friday.”Huh? What? That’s right, this online, SaaS-based application only operates during “normal business hours.” This obviously makes the application very hard to use. Why would they restrict the hours that you’d use an application like this? As a government institution, they undoubtedly figured they didn’t want to let the application run when nobody was in the office to support it. After all, how could they possibly fix anything that went wrong if they weren’t in the office?Planned downtime is downtimeThese two examples are extremes. But they illustrate a common problem in many online applications: The companies operating the applications create “maintenance windows”—periods of time where they regularly bring the application offline in order to perform routine maintenance and upgrades. Then they treat these windows like they are “free downtime.” They feel they are free to bring their applications down and work on them, without it “counting” as downtime. Nothing could be further from the truth. Downtime is downtime. Whether it is planned, expected, or unplanned and unexpected, if your customers want to use your application and the application is not available for any reason, it is downtime.You cannot operate a modern, digital, online application or service without maintaining a high level of availability. When your customers want to use your service, they expect your service will be operational. They do not care about schedules. They do not tolerate downtime. They use your application when it’s convenient for them, not when it’s convenient for you.It’s bad enough when an application failure causes your availability to suffer. But planning on having downtime, in the form of a maintenance window, is just formalizing customer dissatisfaction.In these modern times, with the tools and services available for modern application development, there is no reason why a digital application should require any sort of downtime at all for any maintenance or upgrades. In today’s world, it is unnecessary. From a customer’s point of view, it is unacceptable. Almost any upgrade can be made live without any downtime. Even upgrades that require database schema changes and other data migration tasks can be implemented without requiring downtime. Maintenance tasks can be performed while the application continues to operate. There is no longer any valid reason for you to plan on bringing your modern application down.Maintenance windows are technical debtIf your application really does require maintenance windows due to some historical architectural issue, then you should treat this as a problem. This is technical debt imposed on your application that is costing your company money. It is something that must be addressed. Your customers don’t care why your application is down. They just care when it is down.As your application grows and expands, it will be harder to justify having a regular downtime window. Customer usage patterns expand, and customers expect the application to operate at all times of the day and night.Additionally, building systems and processes for your development organization that don’t require the use of maintenance windows encourages adherence to deployment and operational best practices. We developers tend to get lazy when we act like we know we have a maintenance window available for our use. Designing and implementing changes that don’t require a maintenance window requires additional time and thought, which encourages better attention to detail. When developers are required to think about the operational impact of a change, they tend to produce fewer operational issues than when they simply “throw it into production” and do not consider the ramifications. When you depend on maintenance windows, overall quality and availability suffer.Even if you currently have easily identifiable “low usage” times during which you feel you can afford to bring your application down, that doesn’t mean that those same “low usage” times will be available to you as you expand and grow. International expansion, product set expansion, and customer base expansion can all contribute to the increased need for 24×7 availability.The high cost of maintenance windowsA previous client of mine regularly scheduled a two-hour maintenance window each week, so they could perform upgrades and data adjustments, while allowing them to keep operating normally the rest of the time.The problem is that the maintenance window is, by itself, a major hit to availability. A two-hour maintenance window means that the greatest availability you can offer to your customers is 98.8%. By definition, you will not be able to operate greater than 98.8% of the time.By comparison to other online applications, 98.8% is a horrible statistic. For example, the Amazon S3 service guarantees 99.99% service availability (and has an even higher data integrity SLA). This guarantee amounts to a maximum of 61 seconds of downtime each week. In order for Amazon S3 to make this SLA consistently, Amazon can never plan to have any downtime for any maintenance, ever. Any outage at all will cause them to fail their contracted SLA.And they back up this policy with money. If Amazon S3 is down a mere 4.3 minutes in any given month, then AWS will refund 10% of everyone’s storage costs for that entire month. As you can imagine, this would be a significant amount of lost revenue.And it’s not just S3, it’s a mindset across AWS and across all of Amazon. This commitment is ingrained in the minds of every engineer at Amazon. You build everything so that no downtime is ever needed, no matter what the change to the system involves. No downtime, ever.Yes, 99.99% is a high level of availability to guarantee, and not every company needs that level for their business to thrive. But even at a lower percentage of availability, there is little room for planned maintenance windows:
99% availability means 1.6 hours per week of maximum downtime.
99.9% availability means 10 minutes per week of maximum downtime.
99.99% availability means less than 61 seconds per week of maximum downtime.
Even at these lower availability levels, a planned two hours of downtime each week means your application will always fail its SLA. Some companies don’t count planned downtime as downtime—but your customers do, and that’s what matters.
Copyright © 2021 IDG Communications, Inc.
Source link