Hacker News Reader

Comment by kevindeasis | Hacker News Reader

anyone wanna share their thoughts about deploying their own messaging system vs using a messaging system provided by their cloud provider?

View on HN

The GCP Pub/Sub API has largely replicated all the features you'd want out of Kafka (including Consumer Groups). The primary consideration at this point is cost. There's an inflection point in size (at some very large message volume) where it makes sense to start running your own Kafka cluster and hire a dedicated person or two to manage it. Most companies will never get anywhere close.

Any project just starting out should use Pub/Sub. One thing I really like is that GCP provides emulators of Pub/Sub et al for local testing. That used to be a bit of an obstacle not too long ago.

In terms of lock-in, I don't see how that applies to an AMQ. The data moving through it should only be transiently persisted, up to a week or two at most in the usual case.

If you want to avoid cloud lock-in, have DB backups, use Postgres/MySQL/etc, containerize your service(s), replicate data in object storage, etc. Common sense stuff, if that's something that's of concern.

Personally, I've seen "vendor lock-in" weaponized as an excuse for a lot of costly NIH bullshit. It's painful to reflect back on a project that could have involved literally a tenth of the time and pain it ended up taking because of that one choice alone.

IMO lock-in fears are overblown. Build stuff out quickly and prove your idea and then refactor when you have customers and revenue.

Refactoring a growing system while maintaining bug-for-bug compatibility is extraordinarily hard. Most people I know who've gone through such a migration never want to do it again.

Most people are simply bad at migrations.

If most are bad at migrations then what should most do?

Learn how to do migrations well. There's plenty of literature on the topic.

Ultimately, building a maintainable system requires that you allow for people being bad. If 10 smart engineers contribute to your system, and they each assume future developers will be good in their own distinct way, the resulting system will be so complicated that none of them are good enough to maintain it.

Preferably, everything that can be is loosely coupled and extensible.

Wasn’t Facebook built on MySQL with the friend graph written in relational SQL and PHP? The idea was but out and then perfected later. In my head this is the same as doing it on AWS or GCP fully on their proprietary stack and then once making some coin you start a refactor or a migration in parallel to your own hardware and stack as costs warrant it.

Dropbox is famous for doing this when they did their move from S3 to pocket — an in house storage layer they built.

It's not likely your product will have enough financial success to afford the huge amount of engineering effort facebook has put into improving their platform. If your system falls apart before you are making enough off of it to fix it you're going to just run out of runway.

Or to add to that, there are often very good reasons to optimize well before facebook did. The sheer friction of making the transition to The Right Thing can often be too difficult to overcome.

I don't believe PubSub has a way to ensure linearizability between messages, where Kafka does have this by deterministic hashing of keys partitioning. Otherwise yeah, Pubsub looks pretty solid and economical.

At my company I'm guessing we push over 200M messages a day through it, and it is a breeze to maintain and stable as hell. Maybe gets harder a couple orders of magnitude more, but no complaints here.

GCP Pub/Sub is insanely expensive

I don't have a lot of devops experience, but I was just struck by how cheap it appeared to me. $40 / TB? I can't even imagine how much money is sunk into managing the Kafka clusters at my employer.

Can you explain? It doesn't seem that way at all.

> The primary consideration at this point is cost.

Certainly. In my experience the operational cost of kafka is enormous. Ive seen incidents too often for a relatively small (<10 machines) cluster. I would expect that after a first long phase of finding the right configuration, to step on a phase were it runs smoothly, but I didnt see it yet.

If you are on GCP I think the choice is simple, use Cloud Pub/Sub. Extremely simple, extremely reliable, extremely performant, fairly inexpensive, multi-region (global). No maintenance, no scaling, almost no tunables, it just works.

Google provides a Pub/Sub emulator for local development.

I don't really buy the vendor lock-in thing for Pub/Sub-like systems. The Cloud Pub/Sub usage pattern is basically the same as Kafka, you can have a library that abstracts away the differences. There are open source libraries that do that[1]. If you ever need to switch cloud providers, or want a messaging system to span cloud providers, you can switch without changing lots of code.

[1] https://github.com/google/go-cloud/tree/master/pubsub

I don't think it's that simple unless I misunderstand how GCP Pubsub works. I don't think GCP PubSub will give you deterministic delivery order within a partition the way Kafka will: https://cloud.google.com/pubsub/docs/ordering

We have Kafka and GCP pubsub. Kafka is the way to go for us. In terms of reliability, performance, load, etc.

Are you saying GCP pubsub have bad reliability? I never used it but would be surprised if it was down for several hours each weak or would just drop your data.

I would love to know your experience

One of the teams was complaining about behavior on load. Now another team will migrate that flow to Kafka. Another team was complaining about reliability/speed. I think eventually they stopped relying on that.

Distributed messaging is really hard to get right. It'll seem to work fine right up until you get weird bugs and unreliability during at the worst moments.

I wouldn't recommend relying primarily on something vendor-specific like Amazon SQS, but there are very good out-of-the-box tools like RabbitMQ or Kafka available.

Writing your own messaging system is like writing your own database, it's the wrong choice 99.9% of the time.

While I agree I see a big problem that people often pick Kafka when they really needed Rabbitmq because of the hype around Kafka and not understanding the difference between a transactional message broker ( Rabbitmq and ibm mq ...) as used in banking and distributed log store (pulsar/ Kafka)

Not sure that I’d want to rely too much on Rabbit’s transactional behavior based on their limitations.

https://www.rabbitmq.com/semantics.html

Testability. Single biggest reason for us not going with the proprietary queue. We can create, reset, throw away queues as we want during testing, thousands times a day. Even on a laptop.

Do you have any advice for setting up a test Kafka environment? I'd love to be able setup a lightweight in-memory Kafka for unit-y tests without going through the whole Docker compose rigamarole.

Depending on complexity and specialisation of your use that's what may work for unit testing:

1) Abstract real library with tech-agnostic interface to remove as much tech details as possible and focus on behaviour.

2) Create simplest in-memory dummy implementation for that interface, basically a mock.

3) Write a test spec for that interface behaviour (does xxx on yyy, returns zzz otherwise) and run it agains both real wrapped interface & mock to be sure they're consistent.

4) Make code to load mock in local testing env

5) Use real kafka when running it on a testing pipeline

Same way you could abstract various things - e.g. once I just abstracted proprietary services and locally flushed everything into local Postgres. You can emulate multiple services there - e.g. database, somewhat-usable queue, etc. And get some extra control nice for tests (e.g. make it to throw errors on your wish or add timeout to simulate net delays). That saved a lot of time for local development for me, without dropping quality.

If you're using Kafka Streams it provides a TopologyTestRunner.

Check out the Kafka support in Testcontainers: https://www.testcontainers.org/modules/kafka/. It is container-based, but with a very simple-to-use API for spinning up Kafka in tests.

If you truly want something embedded, Debezium's KafkaCluster could be interesting: https://github.com/debezium/debezium/blob/master/debezium-co....

It's used four our own tests of Debezium, but I'm aware of several external users. It spins up AK and ZK embedded. Disclaimer: I work on Debezium

We use Amazon MSK and are pretty happy with it so far.

Much much cheaper.

does that factor in development costs?

does developing for NATS is so much harder than for cloud provided pubsub?

Configuration & administration of the kafka cluster is more time-consuming.

Yes, but nats is dead simple

Dev time would far outweigh the cost of a managed equivalent.

Disagree.

Dev time is virtually identical between the two kinds of infrastructure.

Avoiding vendor lock-in is the only quasi-sane reason I can think of.

Reply on news.ycombinator.com