Why do people think I'd rather have speed than security? Would you?https://twitter.com/pawel_lasek/status/1123610028047466496 …
-
-
Replying to @BenLaurie
Colm MacCárthaigh Retweeted Colm MacCárthaigh
leaving this here ...https://twitter.com/colmmacc/status/986286693572493312 …
Colm MacCárthaigh added,
2 replies 1 retweet 6 likes -
Replying to @colmmacc @BenLaurie
I see availability and speed as the same thing. Availability is just a speed threshold chosen by the service provider. If an API is so slow that every client times out, then it’s unavailable. If an API fails but succeeds when retried 1ms later, then it’s probably available.
2 replies 0 retweets 1 like -
Replying to @dvassallo @BenLaurie
Well, that's a ridiculous take. Availability and speed are not the same thing.
1 reply 0 retweets 3 likes -
In this sense they are: A client cannot distinguish between a slow server and a down server.
1 reply 0 retweets 0 likes -
Of course it can! only when the slowness goes beyond the threshold is that true. And a 100% error rate, but with super fast errors, is clearly not available.
1 reply 0 retweets 1 like -
I think availability is best seen from the POV of delivering the promised utility to the user. If my Netflix movie streams without buffering, I don’t care if some packets had to be retransmitted. The service I wanted was available. But if it starts buffering, it’s not available.
1 reply 0 retweets 0 likes -
That doesn't make availability == speed. Of course extreme slowness is downtime. So is durability failure. So are some security incidents. But these words have independent meanings. Systems can vary in speed and remain available, as you point out! That's why availability > speed.
1 reply 0 retweets 2 likes -
Wouldn’t a good definition of availability be the ability to deliver something with certain performance & features? Saying availability > speed implies that one can be traded for the other. But availability is a function of speed, so they can’t be treated independently.
1 reply 0 retweets 0 likes
A classic example of a speed/availability trade-off is a cache. Introducing a cache often increases speed, but also creates a severe availability risk, in that the cache can be another point of failure, and that a cold cache can lead to an unrecoverable state.
-
-
From my speed==availability perspective, the cache would be an option to make the service "available" to use cases that cannot use it without the perf provided by the cache. So you're not trading avail/perf, but just making a strategic choice about availability options. ...
1 reply 0 retweets 2 likes -
Replying to @dvassallo @colmmacc and
If, say, S3 has a latency of 50ms, and I need 10ms for my project, S3 is not available to me. If S3 adds a cache and the latency drops to <10ms, then it becomes available to me. But the cache might add a risk of making it unavailable to everyone. It's all availability!
1 reply 0 retweets 1 like - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.