sbellware

12 ms·

1.
by sbellware 4mo ago
Author here. Eventide is an open source Ruby framework for event sourcing, autonomous components, and message-based architecture built on PostgreSQL (via Message DB). This post is the second in a three-part series. Part one covered the deve
2.
The Next Generation of Eventide – shaped by a decade of event sourcing(blog.eventide-project.org)
1 points by sbellware 4mo ago|1 comments
3.
A Decade of Eventide: Evolving an Event-Sourced Architecture and Ecosystem(blog.eventide-project.org)
1 points by sbellware 6mo ago|1 comments
4.
by sbellware 6mo ago
Over the past decade, I’ve been working on an event-sourced architecture—used in production systems (including legal and financial systems)—that evolved into an open-source ecosystem. This write-up looks at: - How the architecture developed
5.
by sbellware 3y ago
As an entrepreneur and engineer and programmer having spent 30 years in software without washing out and still accelerating, I'm shocked every time I encounter the well-conditioned presumption that work cells in knowledge work should b
6.
by sbellware 3y ago
I've always found it odd (at least since 2001-ish) that developers see the 1-work-for-1-person as some kind of desirable norm, rather than some arbitrary fixation that has been burned into them since the start of their careers. It&#x27
7.
by sbellware 3y ago
Erl and Yourdon's books are definitely still relevant, but they have to be put into historical context and historical perspective at this point in order to extract the enduring value that they have. I wouldn't literally build a SO
8.
by sbellware 3y ago
Pull requests are a relatively recent addition to software development. What did you do before pull requests? If you haven't been around for that long, and have had a career that always had pull requests, then pull requests seem like a
9.
by sbellware 3y ago
Right. We don't name the methodology. If we did, people who claim to be "doing it" by mentioning the name of the thing. It's the individual practices that are talked about, and that's on-purpose. We can't affor
10.
by sbellware 3y ago
Some additional context on this: - There are additional organizational and process mechanics in-play that are out-of-scope for just a write-up on commit messages - The team is made up of around 15 people supporting around 400 repos and abou
11.
by sbellware 6y ago
If the question "are there any case studies where microservices went well" is a valid question, then so must be, "are there any case studies where monolithic architecture went well". My point being that if and only if we
12.
by sbellware 6y ago
What happens when the write of the current position fails? It's the same problem as presuming that ACK messages in message brokers/queues are guaranteed to not fail. Since the message transport and other durable resources are rare
13.
by sbellware 6y ago
> most I experimented with would lose data in a catastrophic event and cause inconsistencies Fair enough. Those are probably message buses or message queues that are ephemeral transports. Since event sourcing is predicated upon permanent
14.
by sbellware 6y ago
What happens when the server that holds the thing that holds that state is restarted?
15.
by sbellware 6y ago
> Pub/sub in Event Sourcing is a bad idea I find this point surprising. I would say the exact opposite. I would say that pub/sub and event sourcing are two sides of the same coin: events. > what to do if sub happens after pu
16.
by sbellware 7y ago
The only telltale metric of software work that I know is the ratio of time spent making progress to time spent not being able to make progress because of past mistakes made and shortcuts taken. It's reasonable to consider that the reas
17.
by sbellware 7y ago
The problem here is that an unmitigated monolith with no domain partitioning in its data model can't be transformed into a service architecture by carving off pieces. For pieces to be able to be carved off, they already have to be auto
18.
by sbellware 7y ago
Indeed. And having been around in both the SOA period and the Microservices period, and having witnessed the transition, I'm comfortable with maintaining the assertion that "Microservices" as a term was specifically introduce
19.
by sbellware 7y ago
> Are you saying that this is bad? It doesn't seem so. It's not "bad" per se, but it's not what it seems on the surface. ACKing a message doesn't mean that the message will not be received more than one time
20.
by sbellware 7y ago
A message store is really not a comparable pattern to a message queue. It's unlikely that the usages would be similar enough to engender a meaningful comparison. They're not as dissimilar as an apples-to-oranges comparison, but ma
21.
by sbellware 7y ago
The right store is the one that has the features needed to implement the targeted patterns, has client libraries for most programming languages, can be tuned and scaled, has a large ecosystem, has numerous managed hosting solutions offered
22.
by sbellware 7y ago
There are too many "it depends" issues, especially the hardware, and not least the application architecture sitting on top of it. There's a script in the Message DB codebase that will do some fairly rudimentary read and write
23.
by sbellware 7y ago
Or managed Postgres on AWS Aurora, AWS RDS, Google Cloud SQL, Heroku, etc :) SNS, Kenesis (Kafka), Google Pub/Sub are awesome. Not the same problem/solution fit as an event store, but awesome for the scenarios and architectures th
24.
by sbellware 7y ago
> The almost-but-not-quite unstated major premise of the whole argument is that you're putting a key piece of smarts into the queue: Tracking whether a message has been processed. One could argue that that is the real antipattern. I
25.
by sbellware 7y ago
Anything that processes a signal checks if a signal has been received. It's no so black-and-white at the level of electricity, but higher-level things at the level of durable message queues check for new signals, even if those signals
26.
by sbellware 7y ago
Yes, we disagree :) The response given by @ethangarofolo does a good job of addressing the main points. I would say that the slide deck linked is a bit sneaky. Sooner or later, in anything built with a computer, there's going to be pol
27.
by sbellware 7y ago
Awesome answer!
28.
by sbellware 10y ago
By "problems that shouldn't exist in the first place", I mean complexity and lack of clarity that is the result of presuming to reproduce a relational database schema in an object model. This is the single biggest problem in
29.
by sbellware 10y ago
I've had similar, unfortunate gigs. Even where there are smart, capable, technically-adept folks in-place, it in no way means that they have full command of the implications and the ways and means of event sourcing. In my experience, e
30.
by sbellware 10y ago
I've done a number of event-sourced projects, and have built a good amount of tooling over time to support the work. There's one overarching issue I see early on in the adoption process. The difference between what is being called

More ›