What happens when a web application you depend on

goes offline? It can be inconvenient, disappointing and

potentially cause serious problems for you.

But what if you find out that the web application wasn't

working by design, because it was down for maintenance? That

only makes the situation worse. Your customers expect your

application to be operational when they need it. Not when you

find a convenient maintenance windows impose your schedule on

your customers, and can negatively impact their

experience. And there is no reason for it. A well designed,

well operated modern web application never ever has to be

down for scheduled maintenance. In this episode, we'll discuss

why maintenance windows are a thing of the past. Are you

ready? Let's go.

This is the modern digital business podcast, the

technical Leaders Guide to modernizing your applications

and digital business. Whether you're a business technology

leader, or a small business innovator, keeping up with the

digital business revelation is a must here to help make it easier

with actionable insights and recommendations, as well as

thoughtful interviews with industry experts, Lee Atchison.

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 when I wasn't at home.

Basic requirements of a smart thermostat nowadays.

I set it up and connected it to the manufacturers cloud back

end. All was fine. Or so I thought.

A couple of weeks later, I received an email from the

manufacturer about the upcoming upgrade of their back end cloud

service.

During the time of the upgrade, which was going to last for

several months, the company would be bringing down its

applications for quote many hours at a time and would do so

at quote various times during the day.

They wouldn't commit to specific days and times, just that they

would be bringing the system down for a while, seemingly

randomly, many times over the next several months. The

company, of course, apologized in advance for the

inconvenience.

Yeah, right.

What was that all about?

at seemingly random times, my thermostat would stop working

for many hours at a time. And this would go on for months. I

don't think so. The very next day, I replaced the thermostat

with one from another company throughout the old one and wrote

them a scathing negative review, there is no way I would deal

with that level of bad service.

Available availability matters.

Let's look at another example. In order to receive certain

disability benefits that he's eligible for, 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 of the day, it

shows you a message. The message says this application only works

between the hours of 8am to 5pm. Eastern Time, Monday through

Friday.

Hmm, what is that? That's right, this online SAS based web

application only operates during, quote 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?

Availability matters.

These two stories are extreme examples, but they represent

examples of a common problem in many online applications. The

company's operating the applications create maintenance

windows, periods of time where they regularly bring the

application offline in order to perform routine maintenance and

upgrades. Wants to find they treat these windows like they

are free downtime periods. They feel they are free to bring

their applications down and work on

Mmm. Without it counting is downtime.

Well, nothing could be further from the truth. Downtime is

downtime, whether it's planned, unexpected, or unplanned and

unexpected if your customers want to use your application,

and the application is not available for any reason, it's

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

maintenance 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 a real

application failure causes your availability to suffer. But

planning and having downtime in the form of a maintenance window

is just formalizing customer dissatisfaction.

In these modern times, with the tools and services that are

available for modern cloud native application development,

there is simply no reason why a digital application should

require any sort of downtime at all, for any maintenance or

upgrade. In today's world, it's unnecessary. From a customer's

point of view, it is unacceptable.

Almost any upgrade can be made live without any downtime. Even

upgrades are required database schema changes and other data

migration tasks can be implemented without requiring

any 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.

And if your application does require maintenance windows, due

to some historical architectural issue with your application,

they used to treat this as what it is a serious problem. This is

technical debt imposed on your application that is costing your

company money. Your customers don't care why your application

is down. They just care that 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 them to adhere to deployment and

operational best practices. You see, we developers tend to get

lazy when we act like we know we have maintenance windows

available for our years. designing and implementing

changes that don't require a maintenance window requires

additional time and thought, which encourages better

attention to detail and to best practices. When developers are

required to think about the operational impact of a change,

they tend to produce fewer operational problems than when

they simply throw it into production and not consider the

ramifications when you depend on maintenance windows. Ultimately,

overall quality and availability suffers. 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 products

that expansion, customer base expansion can all contribute to

increased need for 24 by seven availability. A previous client

of mine regularly scheduled a two hour maintenance window each

week, so they can perform upgrades and data adjustments

while allowing them to keep operating normally the rest of

the time. The problem is the maintenance window is by itself

a major hit to their availability. a two hour

maintenance window means that the greatest availability they

can offer their customers was 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

Point 99% service availability, their data integrity SLA is even

higher than that. This guarantee amounts to a maximum of 61

seconds of downtime each week. In order for s3 to make this SLA

consistently, they can never planned to have any downtime for

any maintenance ever. Any outage at all will cause them to fail

their contracted SLA. And they back up their SLA policy with

money. If Amazon s3 is down just a mere 4.3 minutes in any given

month, then AWS will refund 10% of everyone's storage costs for

the entire month. As you can imagine, this would be a

significant amount of revenue loss for Amazon. And it's not

just s3. It's a mindset across all of AWS and across all of

Amazon. This commitment is ingrained in the minds of every

engineer that works 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's no room for planned maintenance windows. 99%

availability means 1.6 hours per week of maximum downtime. 99.9%

availability, which is pretty reasonable, means 10 minutes per

week of maximum downtime, and 99.99% availability means less

than 61 seconds per week of maximum downtime. Even at these

lower availability levels. A planned two hour maintenance

window each week means your application will always always

fail its SLA. Now some companies don't count planned downtime as

official downtime, but you can bet that your customers do And

isn't that what really matters. Thank you for tuning in to

modern digital business. This podcast exists because of the

support of you my listeners. If you enjoy what you hear, please

leave a review on Apple podcasts or directly on our website at

mdb.fm/reviews. And if you'd like to record a quick question

or comment, click the Microphone icon in the lower right hand

corner of our website. Your recording might be featured on a

future episode. Make sure you get every new episode when they

become available. Click subscribe and your favorite

podcast player or check out our website@mdb.fm If you want to

learn more from me to check out one of my books, courses or

articles by going to Lee atchison.com. And all of these

links are included in the show notes. Thank you for listening

and welcome to the world of the modern digital business.