Requirements that are uselessly vague. "Architected to never go down"? That's not a requirement, that's wishful thinking. It's as useful a requirement as "Must be attractive to Unicorns."
Engineering a web scale service for robustness is a series of tradeoffs, increasingly expensive tradeoffs as you make the system proof against bigger threats. Geographical redundancy alone more than doubles your costs, and (if you're doing it right) only adds a third or fourth 9 to your availability numbers.
But "Architected to never go down." does not guide the implementer, it doesn't communicate anything they need to know about what the limits of system are; and most importantly it ignores the reality principle.
You're missing the point. This isn't a job ad, it's a question about what would you pick to use if you had to develop a web app. "Architected to never go down" should be read as "Stability is important". No web stack will satisfy everything the author asks for, but they are bringing up all the different factors (or at least most of the broad ones) that need to be considered when making an architecture decision. How would your favourite web stack match up against the different evaluative dimensions?
The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
Unless we completely reinterpret the requirements (as per your suggestion), (s)he really can't. It is impossible to meet the requirement "Architected never to go down."
What actually confuses me more than anything is how wildly the strength of the writer's connection to reality varies. I mean, two of the "requirements" are:
# Architected to never go down
and
# Employs security features
The first is impossible. The second is trivial. All software employs some sort of security feature - the alternative is for the software to be perfectly insecure.
I think that you are taking this as a programmer (i.e. too literally).
If I asked you to recommend a car that is fast and safe you wouldn't reply "all cars are fast" and "no car can be perfectly safe", you would suggest a car that maximises those requirements.
Similarly, the author is looking for what frameworks/stacks maximise (among other things) reliability and security.
Comments
Requirements that are uselessly vague. "Architected to never go down"? That's not a requirement, that's wishful thinking. It's as useful a requirement as "Must be attractive to Unicorns."
Engineering a web scale service for robustness is a series of tradeoffs, increasingly expensive tradeoffs as you make the system proof against bigger threats. Geographical redundancy alone more than doubles your costs, and (if you're doing it right) only adds a third or fourth 9 to your availability numbers.
But "Architected to never go down." does not guide the implementer, it doesn't communicate anything they need to know about what the limits of system are; and most importantly it ignores the reality principle.
You're missing the point. This isn't a job ad, it's a question about what would you pick to use if you had to develop a web app. "Architected to never go down" should be read as "Stability is important". No web stack will satisfy everything the author asks for, but they are bringing up all the different factors (or at least most of the broad ones) that need to be considered when making an architecture decision. How would your favourite web stack match up against the different evaluative dimensions?
The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
Unless we completely reinterpret the requirements (as per your suggestion), (s)he really can't. It is impossible to meet the requirement "Architected never to go down."
What actually confuses me more than anything is how wildly the strength of the writer's connection to reality varies. I mean, two of the "requirements" are:
and The first is impossible. The second is trivial. All software employs some sort of security feature - the alternative is for the software to be perfectly insecure.Eh, I dunno.
I think that you are taking this as a programmer (i.e. too literally).
If I asked you to recommend a car that is fast and safe you wouldn't reply "all cars are fast" and "no car can be perfectly safe", you would suggest a car that maximises those requirements.
Similarly, the author is looking for what frameworks/stacks maximise (among other things) reliability and security.