zlacker

Predicting the Future of Distributed Systems

submitted by borisj+(OP) on 2024-08-27 00:26:37 | 173 points 42 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
5. BraveN+t8[view] [source] 2024-08-27 02:11:17
>>borisj+(OP)
> One-Way-Door and Two-Way-Door Decisions

See also the "Linux kernel management style" document that's been in the kernel since forever: https://docs.kernel.org/6.1/process/management-style.html

12. jensne+0n[view] [source] 2024-08-27 06:07:13
>>borisj+(OP)
I'd like to add that I'm seeing more and more companies unifying synchronous and asynchronous APIs. With the concept of GraphQL Federation, it's possible to "extend" Entities by defining their (primary) keys in a GraphQL Schema. If we're combining this with Async APIs, e.g. NATS or Kafka, we can enable teams to build APIs around events, while still being able to distribute the implementation of how certain fields can be resolved. The Federation Router then joins the Stream with additional data from synchronous services, a very powerful pattern I believe. I wrote a bit more on the topic here: https://wundergraph.com/blog/distributed_graphql_subscriptio...
16. purple+sp[view] [source] 2024-08-27 06:42:27
>>borisj+(OP)
> Programming Models

If you read this section, the author gets a lot of things right, but clearly doesn't know the space that well since there have been people building things along these lines for years. And making vague commentary instead of describing the nitty-gritty doesn't evoke much confidence.

I work on one such language/tool called mgmt config, but I have had virtually no interest and/or skill in marketing it. TBQH, I'm disenchanted by the fact that it seems to get any recognition you need to have VC's and a three-year timeline, short-term goals, and a plan to be done by then or move on.

If you're serious about future infra, then it's all here:

https://github.com/purpleidea/mgmt/

Looking for coding help for some of the harder bits that people might wish to add, and for people to take it into production and find issues that we've missed.

◧◩
19. lifty+bz[view] [source] [discussion] 2024-08-27 09:07:53
>>purple+sp
I remember seeing your presentation many years ago, at Fosdem. Very cool project and if I would have to manage classic OS deployments I would definitely give mgmt a try. That being said, I think the world is moving to more immutable systems similar to how Talos works (https://talos.dev).
◧◩◪◨
26. 629514+Ck1[view] [source] [discussion] 2024-08-27 15:26:44
>>buro9+Ny
Ce n'est pas un Kafka: Kafka is a Protocol Apache Kafka is an aging open source project. It's time to accept that Kafka's protocol is what matters. (https://materializedview.io/p/ce-nest-pas-un-kafka)
◧◩◪◨⬒⬓
29. purple+Dr1[view] [source] [discussion] 2024-08-27 16:06:47
>>karmar+Kd1
I'm hiring for a company that is building a tech stack of VM's. My username at mastodon or twitter has the details, and it's about working with https://github.com/purpleidea/mgmt/
◧◩
42. levent+Eib[view] [source] [discussion] 2024-08-31 06:32:58
>>willva+yo
BigQuery Storage Read API claims to support filters and simple projections pushed down to the storage: https://cloud.google.com/bigquery/docs/reference/storage. See also this recent paper: https://research.google/pubs/biglake-bigquerys-evolution-tow...

I've also recently proposed a Table Read protocol that should be a "non-vendor-controlled" equivalent of BigQuery Storage APIs: https://engineeringideas.substack.com/p/table-transfer-proto...

[go to top]