100% uptime for a web application
serverfault.com
100% uptime for a web application
1–10 of 14 posts
Re: 100% uptime for a web application
#2https://news.ycombinator.com/item?id=3056414 linked from the answers
Re: 100% uptime for a web application
#3I'm a bit disappointed with these answers. Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible.
Assuming you have a client who asks for this, you explain it isn't possible to get 100%, but they still want as good as they can get, and are willing to pay big bucks, what do you do?
Re: 100% uptime for a web application
#4I'm a bit disappointed with these answers. Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible. Assuming you have a client who asks for this, you explain it isn't possible to get 100%, but they still want as good as they can get, and are willing to pay big bucks, what do you do?
I thought the same - this is just a customer with a fundamental misunderstanding. As long as you don't sign a contract stating 100%, they will probably be okay.
Re: 100% uptime for a web application
#5I'm a bit disappointed with these answers. Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible. Assuming you have a client who asks for this, you explain it isn't possible to get 100%, but they still want as good as they can get, and are willing to pay big bucks, what do you do?
I'm disappointed by the top comment as well, it's pretty lazy to say "100% is not possible, therefore I will not answer your question".
Your client isn't technical, he doesn't know. He's got a problem, it's your job to make sure you provide the best solution possible for his budget.
Re: 100% uptime for a web application
#6Every nine after 99 is going to cost exponentially - There are only few critical services that can justify that kind of outlay.
Re: 100% uptime for a web application
#7I'm a bit disappointed with these answers. Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible. Assuming you have a client who asks for this, you explain it isn't possible to get 100%, but they still want as good as they can get, and are willing to pay big bucks, what do you do?
High level items:
- Resiliency of all hardware, software, interconnects i.e. no single points of failure;
- Isolation of the various routes, such that you can pull any plug in the system and there is always a route through;
- An application architecture that supports horizontal scaling, clustering, load balancing, error conditions, enough asynchronicity;
- Enough capacity such that if things start failing, the rest of the system can handle the load;
- Tooling and environments that support stuff such as intraday deploys and rollbacks, including database migrations;
- QA and testing processes to ensure catastrocphic bugs do not slip through!
These are all achievable, but it's when problems start interacting that stuff slips through the cracks.
Re: 100% uptime for a web application
#8I'm a bit disappointed with these answers. Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible. Assuming you have a client who asks for this, you explain it isn't possible to get 100%, but they still want as good as they can get, and are willing to pay big bucks, what do you do?
High level items: - Resiliency of all hardware, software, interconnects i.e. no single points of failure; - Isolation of the various routes, such that you can pull any plug in the system and there is always a route through; - An application architecture that supports horizontal scaling, clustering, load balancing, error conditions, enough asynchronicity; - Enough capacity such that if things start failing, the rest o…
Legal items. Alternatively: The cheat everyone else is using.
1) contractually provide a 100% SLA
2) the "benefit" you give the customer when you don't provide 100% of uptime for a given period is 10% price reduction for that period only
3) To add insult to injury, make the period a day or even an hour.
4) Downtime is only downtime after reception of an email from the designated customer contact, and only if it wasn't resolved at the time they actually noticed. That customer contact must be a person, ready and able (legally allowed) to answer questions and make choices.
This is how a lot of ISPs are doing it.
Amazing how many people consider this a 100% SLA. Then the ISP is down for weeks, and then they get to pay $50 less on a $5000 bill ...
Re: 100% uptime for a web application
#9This is a great lesson in how not to be a pedantic nerd toward clients. By 100%, the client is obviously not specifying an uptime requirement of:
lim (1 - 1/x)
x->inf
Level 1: Single server is connected to a UPS device. Domain's DNS records from multiple DNS hosting companies.
Level 2: Redundant servers load balanced on the firewall.
Level 3: Pool of redundant servers with redundant firewalls and redundant network switches.
Level 4: Geographically separated data centers with traffic routed via anycast.
Level 5: Servers in multiple datacenters from multiple distinct vendors.
Outline ballpark costs at each level plus introduce the required staffing levels to support each level including site reliability engineers to monitor and maintain each site's operation and verify correct data synchronization, 24x7 on-call engineers, equipment to enable remote diagnostics, and so on.
Re: 100% uptime for a web application
#10I'm a bit disappointed with these answers. Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible. Assuming you have a client who asks for this, you explain it isn't possible to get 100%, but they still want as good as they can get, and are willing to pay big bucks, what do you do?
>Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible
I agree with the top comments on StackExchange. It's our job as technical experts to explain to technical non-experts when their expectations are out of line with reality. Anyone who has planned out a redundant system has heard from every single one of their clients that they want "100% uptime".
The problem is that 100% uptime has an explicit definition and it's important to point out that it's not practical as a goal. How much better is it to state, "I know you said 100% uptime, but let's explore what's practical and plan for the down time you will have."
This part is extremely curious itself from the original request:
>In a nutshell, the application will live on servers within the client's network.
All but the largest of clients have no idea how to run a data center that can approach even 99.999% availability. It requires redundant servers, redundant storage, redundant LAN connections, redundant WAN connections, redundant firewalls, robust security, on-site staff operators 24x7, battery backed up power, diesel generator backed up power, a massive storage tank for diesel fuel, a disaster recovery site, plans for phased patching, plans for data synchronization, etc, etc.
To get anywhere near to 5 nines is millions of dollars. There are very few clients that are willing to spent a fraction of that. Why not tell them the truth that they're going to have a couple days of downtime per year and that they should plan for it?