XMPP was supposed to be this. There was a boom in the early to mid-2010s (I worked at HipChat back then, and it was built on top of XMPP). IMO, it works well; it scales, but none of the commercial solutions picked up for whatever reason. In the end, as you say, proprietary protocols like WhatsApp or Slack won the market.
I've heard great things about Matrix. Peeble's founder, Eric, was building Beeper, a chat app with a similar purpose to what you describe (it recently got acquired by Wordpress). I believe that the core was built on top of Matrix, so you might be up to something there.
I'd highly discourage you from using SMS; it's very insecure. I'd go as far as to recommend you not to implement your own auth and instead use something like Auth0, WorkOS, SuperToken, or SSOReady (https://github.com/ssoready/ssoready), among others.
Building auth stacks is not trivial and is not what will make your SaaS successful. The more you can leverage experts to focus on what makes your SaaS special, the better.
Every time I read about Nomad, I wonder the same. I swear I'm not trolling here, I honestly don't get how running Nomad is simpler than Kubernetes. Especially considering that there are substantially more resources and help on Kubernetes than Nomad.
I agree with @metaltyphoon on this. Even for small teams, a managed version of Kubernetes takes away most of the pain. I've used both ECS+Fargate and Kubernetes, but these days, I prefer Kubernetes mainly because the ecosystem is way bigger, both vendor and open source. Most of the problems we run into are always one search or open source project away.
The most significant value I get from Costco is that the quality is consistently high and the options are well curated. I like not having to go through 100s of brands of basic staples like yogurt, toilet paper, milk, etc...
@blakesterz what kind of pain are you feeling when developing with containers on a Mac vs using your Linux box? I know perf is worse, but are you hitting other things?
I think this something that people miss a lot when trying to optimize their Docker builds. Is the whole optimizing for most of your builds vs optimizing for a specific build. Not easy.
Distroless are tiny, but sometimes the fact that don't have anything on them other than the application binary makes them harder to interact with, specially when troubleshooting or profiling. We recently moved a lot of our stuff back to vanilla debian for this reason. We figured that the extra 100MB wouldn't make that big of a difference when pulling for our Kubernetes clusters. YMMV.
We have the same problem in Okteto. We've been investing a lot on building tech to prevent this (I gave a talk on this during the last eBPF community days -> https://www.youtube.com/watch?v=tplv3Hjjv2Q), but it's tough. We spend a LOT of resources fighting it.
1. Register each dev env with the provider. Dev Envs can have predictable URLs (e.g in okteto cloud it's the name + namespace + domain), so you can directly register it. This works well with self-service webhooks like Github.
2. Have a proxy that routes to the right dev env. This works if there's a key you can use for the routing, like a user ID or the subscription.
3. Have a proxy that duplicates traffic and send it to all the dev envs.
I'm curious wow do you solve this on the DTAP env. Are you registering a single endpoint with the webhook? Then how does it reach the separate dev envs? (or do you have a single, shared dev env?)
> We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the right JVM options
Yes, you should. This is something you can do in the 'okteto.yml' file. You can specify different environment variables, different commands and even a different image (e.g. an image with your dev tools and debugger, which you don't need in prod).
> Latency
This can be a challenge, for sure, specially if you have a bad network connection. In our experience, debuggers and incremental file sync don't require too much bandwidth.
> Don't leave your debugger paused for too long
This has happened a lot to me. In the latest version we introduced a switch to disable healthchecks during dev time so avoid this.
> And forget about trying to debug something that happens on application boot
This is the trickiest definitely. I've had luck by pausing the debugger on attach (on go and node you can do this), but it's not the most optimal.