7 ms·
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
by realtalk_sp 6y ago
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.
- gigatexal 6y agoIMO lock-in fears are overblown. Build stuff out quickly and prove your idea and then refactor when you have customers and revenue.
- SpicyLemonZest 6y agoRefactoring 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.
- halbritt 6y agoMost people are simply bad at migrations.
- cglace 6y agoIf most are bad at migrations then what should most do?
- halbritt 6y agoLearn how to do migrations well. There's plenty of literature on the topic.
- SpicyLemonZest 6y agoUltimately, 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.
- halbritt 6y agoPreferably, everything that can be is loosely coupled and extensible.
- gigatexal 6y agoWasn’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.
- rcxdude 6y agoIt'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.
- runT1ME 6y agoI 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.
- deleted 6y ago[deleted]
- dirtydroog 6y agoGCP Pub/Sub is insanely expensive
- bootlooped 6y agoI 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.
- nwsm 6y agoCan you explain? It doesn't seem that way at all.
- jooz 6y ago> 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.