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.
Well said. We are strong believers in open source and zero trust but reading the post with fresh eyes instead of writing it does make me realize there are some parts of that post in which we can dial back our enthusiasm (OP here). Thanks for the candid comment.
That said, it worked on me :) I've subjected people to using VPNs and I would rather have a worse security posture than to do that again. I'm really intrigued by Netfoundry and agentless zero-trust networking. I've POC'ed ZeroTier + whitelisting but doing so in the app sounds like a great approach!
> 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.?
Having multiple comms channels totally makes sense. I quoted “on premise” as most remote orgs are pretty much all cloud (though some may use colo)- which is really to say on hardware where a SaaS vendor doesn’t hold the keys. I can’t imagine how catastrophic a Slack hack would be for many orgs, and in that scenario you’re entirely dependent on their security and disclosure. It’s completely within their TOS to read your messages for various purposes, along with any apps that have been given access. That’s a pretty weak security posture if dealing with secret IP or other sensitive info. While nothing is guaranteed to be secure, limiting access to your team only seems like a smarter place to start for those who need privacy. Many companies really don’t, or at least accept a small level of risk.
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 don't think the messaging platform should always be on-premise. You can consider running it on premise, but it's not an obvious decision.
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.
