It has nothing to do with latency and it’s making your systems more complicated.
I’m fighting this ongoing war with the phrase “real time” at work. I want to eliminate it from our vocabulary — to the point where I periodically fantasize about standing up a Slack bot that auto replies to the phrase “real time” with “did you mean to define a clear SLO?”
The problem with the colloquial use of the phrase “real time” among most software engineers and the startups that employ them, is that it does not set a clear requirement. It is used to communicate the expectation of a quick response time (which is also not what it means … more on that later) but the most literal interpretation of that is impossible. Computer systems cannot process things instantaneously. There’s always some delay, maybe only milliseconds or nanoseconds.
Adding to the problem is how people perceive time. From the prospective of most users milliseconds is instantaneous. But so is the five second delay on live TV. From a technical perspective the difference between five milliseconds and five seconds is a completely different architecture.
For example, if it’s necessary for us to process data within milliseconds of it being created we probably don’t care about recovering the occasional dropped packet. Data that is actually that time sensitive tends to be completely useless when it shows up late, so we might not even bother with it.
If we need to process data within seconds of it being created we have to stream it, which is a different set of tools and sometimes means wrapping the data in a specific format that makes it easier to cut up and reassemble.
If we need to process data within minutes then we can batch it, which again is a different infrastructure. Batch processing is a lot easier to do than streaming, I personally do not want to support streaming if I don’t have to.
So describing things as “real time” just creates situations where everyone has a completely different idea of what we’re building and what it needs to be optimized for. Pointing this out to people almost always results in them switching to the even more useless phrase, “near real time”
“Near real time” is both as vague as “real time” with the added bonus of also being complete nonsense as technical jargon.
Because, brace yourselves, “real time” refers to process prioritization not response time.
If you didn’t know this, don’t worry. I didn’t either until recently.
Real time doesn’t mean instantaneous, or even as fast as possible, it means there’s a clear deadline in the system that the process must complete by a certain amount of time. That deadline need not be milliseconds. It can be weeks. In hard real time systems the system is verified in such a fashion that we can assume it’s impossible for the deadline to be violated. If the deadline is slipped the system is broken.
Firm or soft real time systems, on the other hand, focus on the amount of times the deadline is violated. Some web based systems could be described as soft real time, but it’s not because they are super fast. It’s because they have a time deadline and track a SLO specifying how often processing is allowed to be slower than that deadline. Again that deadline could be seconds, minutes, hours. Real time doesn’t mean “as it happens in real life” it means “by a previously specified time.”
A part of how hard real time works is by the process in question being deterministic. Meaning operations that might have variable response times are not considered part of the real time component. Fetching data from a data source, for example, or anything that involves network connectivity will create a situation where you cannot guarantee that the process will finish in a certain time. From the perspective of web development this may seem to leave very little on the table. But the concept of real time comes from embedded systems, where many tasks are executed within the bounds of a specific set of hardware.
Don’t Say “Real Time”
So to summarize: stop saying “real time” when you mean low latency. Define your requirements with a specific order of magnitude (minutes, seconds, milliseconds, etc) and set a SLO.
Real time does not refer to how fast a system is, it refers to the nature of a guarantee that the system can finish a process by a given time. It sets expectations on how the hardware will prioritize certain processes over other processes and the ramifications of deadlines being missed.
Calling web based systems “real time” is like claiming you have six nines of availability. You think it’s a harmless bit of exaggeration to impress people, but those who understand what the terminology means will know that you’re full of shit and those who don’t will make bad technical decisions in their desire to meet a vague requirement.
"Stop" - Google News
July 24, 2022 at 09:03AM
https://ift.tt/TtuYyn9
Stop Using “Real Time” Wrong. It has nothing to do with latency and… | by Marianne Bellotti | Jul, 2022 | Medium - Medium
"Stop" - Google News
https://ift.tt/qMwNHhr
https://ift.tt/YjdL283
Bagikan Berita Ini
0 Response to "Stop Using “Real Time” Wrong. It has nothing to do with latency and… | by Marianne Bellotti | Jul, 2022 | Medium - Medium"
Post a Comment