The content marketing came on a little strong for me, but a good post nonetheless. Messaging is the heart of a remote org and it should be “on premise” by default.
Really not sure about that. I work at an MSP/MHP that has infrastructure everywhere ( multiple DCs, AWS, Azure, GCP, OVH, etc.) and recently we had a huge network outage at a few of our on-prem DCs due to a firmware bug in some redundant networking equipment. Having the communications software "in the cloud" allowed collaboration on fixing and communicating about the issue.
Sometimes it's a good idea not to have all the eggs in one basket. In a similar vein, if your "on-prem" is dead, how do you access the documentation helping you debug/connect/etc.?
In terms of losing systems that you need to access while troubleshooting systems issues, that can be a mess with self-hosted tools, but nobody is immune. When AWS had a cascading network failure at US -East-1, their team was unable to access their logging service which made triage incredibly difficult. That’s super rare, and unlikely to happen again for AWS in that manner, but outages can cripple any ops team. Runbooks are a great thing to copy offline!
I worked on a couple of teams, and somehow no IT team could make the chat apps run reliably: we always had disconnects, terrible loading times, lost messages and we had to jump through hoops to enable the most basic integrations. No regular updates, outdated apps that are years behind in looks, features and integrations.
Whenever we just simply used Slack, it was snappy, reliable, and it was easy to set up connectors for different external services.