3 ms·

I'm thinking that a lot of commenters are—understandably—feeling the need to defend the status quo in the name of availability and reliability since the author

I'm thinking that a lot of commenters are—understandably—feeling the need to defend the status quo in the name of availability and reliability since the author zeroed-in on latency, bandwidth, and spend. My takeaway is not a debate against the merits of cloud in the face of trade offs, but against the necessity of—the now ubiquitous—cloud architecture pattern (and related lock-in). The "this-vs-that" is a rhetorical device to introduce an alternative. Of course which solutions are right for different use cases will depend on so many different things, and it's those things that keep engineers employed! :) That said, we can put our engineering hats on to solve for SRE concerns within the patterned proposed by the author; I'm thinking the "what about availability when your one server goes down?!" is a straw-man in the sense that we have different ways of solving the availability story than our Ubiquitous System, and of course the solution must depend on what's actually relevant.

nostrebored 3y ago
How is it a strawman? It’s what anyone sane operating on premise or in the cloud would ask about this in design review
- thomascountz 3y ago
  I agree with you. I mean to say that after reading the author's ideas my takeaway was not that they were suggesting that I irresponsibly construct a single-point-of-failure system for a situation that demands a strong availability story. My takeaway was to mull over and challenge what the availability requirements are before building the ubiquitous cloud system that I'm familiar with. What tradeoffs are made and what risks are budgeted are not ubiquitous, therefore, our architecture should not be. I, for one, appreciated the thought experiment and I took it for that: a theoretical alternative that would otherwise seem untenable being held up against a known pattern. I take it as theoretical because the author didn't actually build the system they're proposing for BusinessInsider, and without putting it into practice, I can only see it as that. In practice, articulating and defining the cost of making choices is still the responsibility of the engineer and I don't believe the author was ignoring availability to suggest that we should too. In fact, I'm left with: "I find this proposal interesting, of course there are availability concerns, how might I solve those concerns from here?" The difference between that thought and the "straw-man" I pointed out is that the straw-man argument reads: "throw this all out because that system is only going to fail."
  - hx833001 3y ago
    His experiment would have looked a lot better without his server going offline from too much traffic, though.
- ReflectedImage 3y ago
  It's a straw man because both the cloud and dedicated suffer the same problem.

nostrebored 3y ago

How is it a strawman? It’s what anyone sane operating on premise or in the cloud would ask about this in design review

thomascountz 3y ago
I agree with you. I mean to say that after reading the author's ideas my takeaway was not that they were suggesting that I irresponsibly construct a single-point-of-failure system for a situation that demands a strong availability story. My takeaway was to mull over and challenge what the availability requirements are before building the ubiquitous cloud system that I'm familiar with. What tradeoffs are made and what risks are budgeted are not ubiquitous, therefore, our architecture should not be. I, for one, appreciated the thought experiment and I took it for that: a theoretical alternative that would otherwise seem untenable being held up against a known pattern. I take it as theoretical because the author didn't actually build the system they're proposing for BusinessInsider, and without putting it into practice, I can only see it as that. In practice, articulating and defining the cost of making choices is still the responsibility of the engineer and I don't believe the author was ignoring availability to suggest that we should too. In fact, I'm left with: "I find this proposal interesting, of course there are availability concerns, how might I solve those concerns from here?" The difference between that thought and the "straw-man" I pointed out is that the straw-man argument reads: "throw this all out because that system is only going to fail."
- hx833001 3y ago
  His experiment would have looked a lot better without his server going offline from too much traffic, though.
ReflectedImage 3y ago
It's a straw man because both the cloud and dedicated suffer the same problem.