Live data from Hacker News

Every System is a Log: Avoiding coordination in distributed applications

restate.dev

81–90 of 157 posts

Re: Every System is a Log: Avoiding coordination in distributed applications

#82

Excuse me for sounding rough, but - isn't this reinventing comp-sci, one step at a time? I learned about distributed incrementally -monotonic logs back at the late 90s, with many other ways to do guaranteed transactional database actions. And I'm quite certain these must have been invented in the 50s or 60s, as these are the problems that early business computer users had: banking software. These are the techniques t…

This is certainly building on principles and ideas from a long history of computer science research.

And yes, there are moment where you go "oh, we implicitly gave up xyz (i.e., causal order across steps) when we started adopting architecture pqr (microservices). But here is a thought on how to bring that back without breaking the benefits of pqr".

If you want, you can think of this as one of these cases. I would argue that there is tremendous practical value in that (I found that to be the case throughout my career).

And technology advances in zig zag lines. You add capability x but lose y on the way and later someone finds a way to have x and y together. That's progress.

Re: Every System is a Log: Avoiding coordination in distributed applications

#83

Earlier quoted context omitted.

delaying writes by a factor longer than the max clock skew of the cluster is a pretty common strategy. It is what Google Spanner does.

Right but it's not magic as you cannot predict networking delays. The max clock skew also has to pick between A and C, in underestimates you lose serializability, in overestimates you pay in write latency.

What if you use CockroachDB for your log? They do something pretty clever: https://www.cockroachlabs.com/blog/living-without-atomic-clo...

Re: Every System is a Log: Avoiding coordination in distributed applications

#84

> If everything’s in one log, there’s nothing to coordinate # On the contrary. Everything becomes coordinated. The entire "log" becomes a giant ass mutex lock. Good luck scaling it.

You can use something like DynamoDb with partition per interaction. That would scale great.

Re: Every System is a Log: Avoiding coordination in distributed applications

#86
post #57

This post makes a great case for how universal logs are in data systems. It was strange to me that there was no log-as-service with the qualities that make it suitable for building higher-level systems like durable execution: conditional appends (as called out by the post!), support very large numbers of logs, allow pushing high throughputs with strict ordering, and just generally provide a simple serverless experien…

What about journalctl?

Re: Every System is a Log: Avoiding coordination in distributed applications

#87
post #57

This post makes a great case for how universal logs are in data systems. It was strange to me that there was no log-as-service with the qualities that make it suitable for building higher-level systems like durable execution: conditional appends (as called out by the post!), support very large numbers of logs, allow pushing high throughputs with strict ordering, and just generally provide a simple serverless experien…

I just want a recognized standard format for write ahead logs. Start with replicating data between OLTP and OLAP databases with minimal glue code, and start moving other systems to a similar structure, like Kafka, then new things we haven’t thought of yet.

Re: Every System is a Log: Avoiding coordination in distributed applications

#88
post #57

This post makes a great case for how universal logs are in data systems. It was strange to me that there was no log-as-service with the qualities that make it suitable for building higher-level systems like durable execution: conditional appends (as called out by the post!), support very large numbers of logs, allow pushing high throughputs with strict ordering, and just generally provide a simple serverless experien…

What about journalctl?

This is why we didn't actually call it logs as a service, but streams :P I meant to refer to the log abstraction this post talks about, see links therein. Observability events are but one kind of data you may want as a stream of durable records.

Re: Every System is a Log: Avoiding coordination in distributed applications

#89

> If everything’s in one log, there’s nothing to coordinate # On the contrary. Everything becomes coordinated. The entire "log" becomes a giant ass mutex lock. Good luck scaling it.

Exactly what I was thinking. Now what's the best mutex system we've built? An SQL database.

Re: Every System is a Log: Avoiding coordination in distributed applications

#90

Excuse me for sounding rough, but - isn't this reinventing comp-sci, one step at a time? I learned about distributed incrementally -monotonic logs back at the late 90s, with many other ways to do guaranteed transactional database actions. And I'm quite certain these must have been invented in the 50s or 60s, as these are the problems that early business computer users had: banking software. These are the techniques t…

When I was in school I had an optional requirement. You had to take one out of 2 or 3 classes to graduate. That was compiler design, which was getting terrible reviews from my peers who were taking it the semester before me, or distributed computing. Might have been a third but if so it was unmemorable.

So I took distributed computing. Which ended up being one of the four classes that satisfied the 80/20 rule for my college education.

Quite recently I started asking coworkers if they took such a class and was shocked to learn how many not only didn’t take it, but could not even recall it being an option at their school. What?

I can understand it being rare in the 90’s but the 00’s and on were paying attention to horizontal scaling, and the 2020’s are rotten with it distributed computing concerns. How… why… I don’t understand how we got here.

Post reply on HN