There seems to be a fundamental technical misunderstanding of these systems in the blog post. Unless you're running in the (generally quite dangerous) scenario where replication factor = 1, both EventBus and Kafka have a network hop (Kafka to the replica and EventBus to the storage layer) and JVM traversal, so the argument that Kafka is more efficient there doesn't make sense.
As you say, it would be trivial to run EventBus storage and serving on the same nodes if the network hop were an issue.
The argument that a decoupled storage layer costs more than co-locating storage and serving also seems dubious. The cluster is basically doing the same amount of work when you decouple those layers, it's just separating them into components that can be optimized for specific roles. So if you pick the right hardware/instances for each layer and tune for that, you really shouldn't need more hardware. Otherwise we'd all still be running full-stack applications on mainframes to minimize the number of servers. :)
Yes, agreed. It seemed odd because Kafka isn't split into layers so there's no other option, and it confuses resource utilization for number of servers.
As you say, it would be trivial to run EventBus storage and serving on the same nodes if the network hop were an issue.
The argument that a decoupled storage layer costs more than co-locating storage and serving also seems dubious. The cluster is basically doing the same amount of work when you decouple those layers, it's just separating them into components that can be optimized for specific roles. So if you pick the right hardware/instances for each layer and tune for that, you really shouldn't need more hardware. Otherwise we'd all still be running full-stack applications on mainframes to minimize the number of servers. :)