ethangarofolo
Joined 13 years ago
Karma
32
Submissions
18
Member since
Jan 7
Recent submissions
Comment · 3 years ago
5-hour mission? Surely something so awesome can't actually exist...
Comment · 4 years ago
I agree with you. Remote optimizes for one set of things, using a model that works great in a low-trust environment like open source. And you can probably get pretty good results with it. And I find Zoom calls far more fatiguing than in-person meetings.
Comment · 4 years ago
Why wouldn't it?
We're talking about a mortgage on the rental property itself not on the landlord's personal residence.
Comment · 5 years ago
I do, yes, and I ask my team to do the same. Even in software development it's very helpful. It helps the team stay in sync more, reducing the need to meet. It helps me stay in sync from yesterday me to today me as well. It avoids duplicated work as well. I consider doing this part of professionalism 101 at this point.
Comment · 6 years ago
I don't know if linking to one's own work is considered gauche here, but since it fits with the original question, my own book Practical Microservices fits this description (https://pragprog.com/book/egmicro/practical-microservices). It takes the reader from inception of a projection to a functioning system, explaining the basics of microservices, event sourcing, and CQRS along the way. Each chapter builds on the previous ones.
Comment · 6 years ago
There are some similarities, and there are definitely worse technologies you could choose for a message store than Kafka. It's worth calling out the difference between event-sourced and event-based. The former is necessarily the latter, but that doesn't go in the opposite direction.
Event-based just means that communication happens over events. Event-sourced means that the authoritative state of the system is sourced from events. If the events are literally the state, then how those are retrieved begins to matter.
Kafka breaks down as a message store in 2 key ways that I mentioned elsewhere in all these threads.
> The first is that one generally has a separate stream for each entity in an event-sourced system. Streams are sort of like topics in Kafka, but it would be quite challenging to, say, make a topic per user in Kafka. The second is Kafka's lack of optimistic concurrency support (see https://issues.apache.org/jira/browse/KAFKA-2260). The decision to not support expected offsets makes perfect sense for what Kafka is, but it does make it unsuitable for event sourcing.
If my only tool were Kafka, then I wouldn't be able to use the messages in the same way that I can with something like Message DB. And that's okay, different tools for different jobs.
Comment · 6 years ago
100% with you that messages are a better way for microservices to receive their input. I don't see how a service could receive its input over HTTP and still retain its autonomy.
A message store like Message DB can at the same time serve as record of system state and communication channel. Writing a message to the store is the same as publishing it for consumers to pick up. Messages are written to streams, and interested parties subscribe to those streams by polling them for new messages.
The store itself isn't aware of which components are subscribing or managing their read positions.
So to your question, the first action of a component receiving a message is do whatever it does to handle the message and then write new messages (specifically events) to record and signal what happened in response to the original message.
Comment · 6 years ago
In addition to what the sibling comments to this one said, Message DB solves a different problem than what queues solve. Message DB is a good fit in a microservice-based architecture, and the "micro" in "microservice" comes from concept of Dumb Pipes / Smart Endpoints (https://martinfowler.com/articles/microservices.html#SmartEn...). Message DB is a "dumb pipe," whereas queues and brokers fit into the "smart pipe" side of the divide.
Message DB is a message store, a database optimized for storing message data. The database doesn't track the status of anything---that responsibility falls to consumers of the data.
Message queues are fine pieces of technology when what you need is a message queue. Message DB, on the other hand, is used for event-sourced systems. "Event-sourced" in turn differs from merely "event-based." Since I've started building event-sourced systems, I haven't run across the need for message queues, but ymmv, and of course, like all humans, I too have my own hammer/nail biases.
Comment · 6 years ago
Good question. Consumers poll for updates. One of the stored functions in Message DB is designed for this very query.
Polling sounds very crude, but for the systems Message DB is designed for, it's a virtue. No back pressure problems, for example.
Comment · 6 years ago
Message DB happens to be implemented using a RDBMS, but the streams in it end up being very clear partition points. Some thought would be required to move data to a different database, but an event-sourced model isn't the same as coupling through a traditional RDBMS schema.
Edit: Fixed a typo
Comment · 6 years ago
The technologies you listed are message brokers, while Message DB is a message store. The former transport messages, and the latter is a database specialized for storing message data and sourcing system state from those messages. Kafka can, for example, move a lot of events around, but it isn't suitable for event sourcing for 2 key reasons.
The first is that one generally has a separate stream for each entity in an event-sourced system. Streams are sort of like topics in Kafka, but it would be quite challenging to, say, make a topic per user in Kafka. The second is Kafka's lack of optimistic concurrency support (see https://issues.apache.org/jira/browse/KAFKA-2260). The decision to not support expected offsets makes perfect sense for what Kafka is, but it does make it unsuitable for event sourcing.
Being built on top of Postgres, Message DB gives you access to event sourcing semantics using a familiar database technology.
We use Message DB in our production systems, and I'd be happy to talk more about it if you have other questions. We've found it very reliable.
As a disclaimer, I'm listed as a contributor at the Eventide Project, the project Message DB was extracted from, though I did not write any of the code behind Message DB.
Comment · 12 years ago
Imagine the beauty of it! Before making an in-app purchase, you'd get to fill out as much paper work as you do for a mortgage. Disclosures, acknowledgement.
We could make Candy Crush as exciting as opening a bank account!
Comment · 12 years ago
Canonical hosts packages for Ubuntu, and they pay for that by charging for other services. Free packages means more people using Ubuntu means more people seeking enterprise support.
There is always funding for everything that lives. Even if you're hosting something for "free" yourself, your job is the funding.
Author of Practical Microservices (https://pragprog.com/book/egmicro/practical-microservices).