> Doing this with serverless might be a lot easier than building the global network & edge infra on your own.
You don't need a global network and edge for a basic b2c chat. Yes it makes a difference in UX when everyone has to exchange messages through your servers in us-east instead of something closer, but the difference is so small it hardly matters unless you're being compared against a messenger that's highly focused on message latency, most are not.
My opinion/bias is that small companies shouldn't continuously reinvent the wheel and sacrifice end user UX just to keep things in house. I've been at so many companies that insisted on building some shitty in house version of some commonly available thing, done with minimal QA and scaling and UX design. A couple years later it has to be completely rewritten anyway but the people involved in its initial implementation are all gone and a bunch of new mistakes are made. If it's not a core business function / major feature, why not outsource it, if not at the app level, at least the platform level?
It's just another facet of the on premise vs cloud discussion, really. But having a single VM handle global multi tenant chat seems like a good way to ensure headaches later on, when it's harder to change things already in prod with existing customers...
Running ejabberd isn't reinventing the wheel though. And it's a battle tested approach to building a chat service, weather it stays on ejabberd or morphs into something else. IMHO, better than getting locked into a single vendor system.
You don't need a global network and edge for a basic b2c chat. Yes it makes a difference in UX when everyone has to exchange messages through your servers in us-east instead of something closer, but the difference is so small it hardly matters unless you're being compared against a messenger that's highly focused on message latency, most are not.