5 ms·

The best part is when it’s all architected to depend on something that becomes essentially a single point of failure, like Kafka.

by pram 2y ago

bamboozled 2y ago
Not saying you're wrong, but what is your grand plan ? I've never seen anything perfect.
- deleted 2y ago
  [deleted]
intelVISA 2y ago
Shhh, you're ruining the party!
arctek 2y ago
Isn't this somewhat better, at least when it fails it's in a single place? As someone using Kafka, I'd like to know what the (good) alternatives are if you have suggestions.
- happymellon 2y ago
  It really depends on what your application is. Where I'm at, most of Kafka usage adds nothing of note and could be replaced with a rest service. It sounds good that Kafka makes everything execute in order, but honestly just making requests block does the same thing. At least then I could autoscale, which Kafka prevents.
- NortySpock 2y ago
  NATS JetStream seemed to support horizontal scaling (either hierarchical via leaf nodes or a flat RAFT quorum) and back pressure when I played with it. I found it easy to get up and running, even as a RAFT cluster, but I have not tried to use JetStream mode heavily yet.
lmm 2y ago
At least Kafka can be properly master-master HA. How people ever got away with building massively redundant fault-tolerant applications that were completely dependent on a single SQL server, I'll never understand.
- trog 2y ago
  I think because it works pretty close to 100 percent of the time with only the most basic maintenance and care (like making sure you don't run out of disk space and keeping up with security updates). You can go amazingly far with this, and adding read only replicas gets you a lot further with little extra effort.
- slt2021 2y ago
  stack overflow has no problem serving entire planet from just four SQL Servers (https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...) There is really nothing wrong with a large vertically scaled up SQL server. You need to be either really really large large scale - or really really UNSKILLED in sql as to keep your relational model and working set in SQL so bad that you reach its limits
  - HideousKojima 2y ago
    >or really really UNSKILLED in sql as to keep your relational model and working set in SQL so bad that you reach its limits Sadly that's the case at my current job. Zero thought put into table design, zero effort into even formatting our stored procedures in a remotely readable way, zero attempts to cache data on the application side even when it's glaringly obvious. We actually brought in a consultant to diagnose our SQL Server performance issues (I'm sure we paid a small fortune for that) and the DB team and all of the other higher ups capable of actually enforcing change rejected every last one of his suggestions.
  - lmm 2y ago
    > There is really nothing wrong with a large vertically scaled up SQL server. Large or small, it's always going to be a single point of failure. All hardware is fallible, especially if we're talking about a commodity box rather than a mainframe or something.
vergessenmir 2y ago
I'm sorry,but I can't tell if you're being serious or not since you commented without qualification. One of the most stable system archictectures I've built was on Kafka AND it was running with microservices managed by teams across multiple geographies and time zones. It was one of the most reliable systems in the bank. There are situations where it isn't appropriate, which can be said for most tech e.g( K8S vs ECS vs Nomad vs bare metal) Every system has failure characteristics. Kafka's is defined as Consistent and Available and your system architecture needs to take that into consideration. Also the transactionality of tasks across multiple services and process boundaries is important. Let's not pretend that kubernetes (or the tech of the day) is at fault while completely ignoring the complex architectural considerations that are being juggled
- pram 2y ago
  Basically because people end up engineering their microservices as a shim to funnel data into the “magical black hole” From my experience most microservices aren’t engineered to handle back pressure. If there is a sudden upsurge in traffic or data the Kafka cluster is expected to absorb all of the throughput. If the cluster starts having IO issues then literally everything in your “distributed” application is now slowly failing until the consumers/brokers can catch up.

The best part is when it’s all architected to depend on something that becomes essentially a single point of failure, like Kafka.

by pram 2y ago

The best part is when it’s all architected to depend on something that becomes essentially a single point of failure, like Kafka.

bamboozled 2y ago

Not saying you're wrong, but what is your grand plan ? I've never seen anything perfect.

deleted 2y ago
[deleted]

intelVISA 2y ago

Shhh, you're ruining the party!

arctek 2y ago

Isn't this somewhat better, at least when it fails it's in a single place? As someone using Kafka, I'd like to know what the (good) alternatives are if you have suggestions.

happymellon 2y ago
It really depends on what your application is. Where I'm at, most of Kafka usage adds nothing of note and could be replaced with a rest service. It sounds good that Kafka makes everything execute in order, but honestly just making requests block does the same thing. At least then I could autoscale, which Kafka prevents.
NortySpock 2y ago
NATS JetStream seemed to support horizontal scaling (either hierarchical via leaf nodes or a flat RAFT quorum) and back pressure when I played with it. I found it easy to get up and running, even as a RAFT cluster, but I have not tried to use JetStream mode heavily yet.

lmm 2y ago

At least Kafka can be properly master-master HA. How people ever got away with building massively redundant fault-tolerant applications that were completely dependent on a single SQL server, I'll never understand.

trog 2y ago
I think because it works pretty close to 100 percent of the time with only the most basic maintenance and care (like making sure you don't run out of disk space and keeping up with security updates). You can go amazingly far with this, and adding read only replicas gets you a lot further with little extra effort.
slt2021 2y ago
stack overflow has no problem serving entire planet from just four SQL Servers (https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...) There is really nothing wrong with a large vertically scaled up SQL server. You need to be either really really large large scale - or really really UNSKILLED in sql as to keep your relational model and working set in SQL so bad that you reach its limits
- HideousKojima 2y ago
  >or really really UNSKILLED in sql as to keep your relational model and working set in SQL so bad that you reach its limits Sadly that's the case at my current job. Zero thought put into table design, zero effort into even formatting our stored procedures in a remotely readable way, zero attempts to cache data on the application side even when it's glaringly obvious. We actually brought in a consultant to diagnose our SQL Server performance issues (I'm sure we paid a small fortune for that) and the DB team and all of the other higher ups capable of actually enforcing change rejected every last one of his suggestions.
- lmm 2y ago
  > There is really nothing wrong with a large vertically scaled up SQL server. Large or small, it's always going to be a single point of failure. All hardware is fallible, especially if we're talking about a commodity box rather than a mainframe or something.

vergessenmir 2y ago

I'm sorry,but I can't tell if you're being serious or not since you commented without qualification. One of the most stable system archictectures I've built was on Kafka AND it was running with microservices managed by teams across multiple geographies and time zones. It was one of the most reliable systems in the bank. There are situations where it isn't appropriate, which can be said for most tech e.g( K8S vs ECS vs Nomad vs bare metal) Every system has failure characteristics. Kafka's is defined as Consistent and Available and your system architecture needs to take that into consideration. Also the transactionality of tasks across multiple services and process boundaries is important. Let's not pretend that kubernetes (or the tech of the day) is at fault while completely ignoring the complex architectural considerations that are being juggled

pram 2y ago
Basically because people end up engineering their microservices as a shim to funnel data into the “magical black hole” From my experience most microservices aren’t engineered to handle back pressure. If there is a sudden upsurge in traffic or data the Kafka cluster is expected to absorb all of the throughput. If the cluster starts having IO issues then literally everything in your “distributed” application is now slowly failing until the consumers/brokers can catch up.