secondrow
If durable execution was a simpler architectural decision
Build an open source FeatureHouse in 300 lines of code
In this example, Xorq is used to compose an open source FeatureHouse that runs on DuckLake and interfaces via Apache Arrow Flight.
The post explains how: - The FeatureHouse is composed with Xorq - Feature leakage is avoided - The FeatureHouse can be ported to any underlying query engine (e.g., Iceberg) - Observability and lineage are handled - Feast can be integrated with it
Composite Data Engine: Augmenting Trino with DuckDB AsOf Join
But really, any system that runs the risk of failing or committing an error should have something in place to observe it, undo it, resume it. Your point about "big enough scale" is true - you can write your own code to handle that, and manually troubleshoot and repair corrupted data up to a certain point. But that takes time.
By making durable execution more lightweight/seamless (a la DBOS or Restate), the use of durable execution libs become just good programming practice for any application where cost of failure is a concern.
Done Asking and Forgetting? (Chatty vs. Tabular AI Interaction)
Why Durable Python Execution Should Be Lightweight
Is AWS Lambda costing more to wait than to compute?
Moving from AWS Lambda to DBOS: Embracing Serverless Development
DBOS Cloud hosts and executes DBOS Transact apps/workflows a la (AWS Lambda+Step Functions). So it is apples:apples. Functionally, DBOS Cloud is like Lambda and Step Functions in one.
Making Serverless Orchestration 25x Faster
Managing Customer Billing in <500 Lines of TypeScript
A few thoughts: 1 - I think it's good to focus some of them on developer (user) acquisition and some on developer retention. The former are more evangelical - social, talks, demos, content that attracts new users. The latter focus on the user experience (UX feedback, docs, issue resolution, community support, how-to vids, etc.) to make sure new users become and remain active with the software. Both are critical to adoption and growing word of mouth.
2 - Dev Advocates can own the open source contributor experience! Recruiting, welcoming, recognizing new contributors is a great thing to see happen. It's an easy thing to overlook with companies placing so much emphasis on user acquisition. It's important for community goodwill building and expanding the network of external advocates.
3 - Make sure the executive team understands the breadth of Dev Advocate responsibilities. It can get tense if they only expect talks and blog posts.
That's my 2 cents...it's a big question!