As a remote-first startup (from day one), we were heavy Slack users.  Considering moving to Mattermost, or any other alternative, caused many folks to shiver.  But we switched.  Why?  Because of what matters the most to us:

  1. Permissionless innovation
  2. Control and visibility of our data
  3. Zero Trust security
  4. Belief in open source
  5. Ability to dogfood our Zero Trust functions

Now, obviously core messaging functionality is critical.  Mattermost is great there, but so is Slack.  In fact, Slack features like third-party integrations and threaded messaging were missed greatly (thank you, Mattermost, for recently adding threaded messaging).  So the relative parity between the solutions from a ‘speeds and feeds’ perspective was table stakes, but we ended up going with the solution which arguably had less ‘features’ and niceties, but fit better with our core principles.  And we are now very happy Mattermost users.

Sidebar: we are sharing the paragraph above because we believe it is critical to any startup, such as Mattermost, which is courting an early adopter market segment.  Focus on what your tiny, tiny pond of early adopters wants and needs, rather than fighting a feature war for mass market opportunities.  Delight your tiny pond of early adopters, and you can grow from there.  Ok, back to the main story.

Let’s look at the reasons we switched from Slack to Mattermost, grouping together the list at the top of this post:

Permissionless innovation; control; open source

We like to innovate.  Mattermost, as an open source based solution, gives us that opportunity.  Closed SaaS (like Slack) is terrific, and we use plenty of it, but we always prefer to use open source at the core to give us the extensibility and flexibility we want, and then to use SaaS around the periphery to make our lives simpler or easier.  The world is much different than it was before C-19 became part of our vocabulary.  What will the world look like in 5 years?  No idea.  So we need the flexibility to change with an ever changing world.  Mattermost open source helps provide the basis for that permissionless innovation.

Control and visibility often go hand-in-hand with an open source base.  We can host the Mattermost servers anywhere.  We control the architecture and retain full control and visibility of each byte of data.  We have direct access to the (also great and open source) database (PostgreSQL).  Our data is core, messaging is at the nucleus of our business and security is not negotiable.  Now, this doesn’t mean we don’t use third party software as part of our security.  It is quite the opposite.  Because we control our core data, we have the capability to use best in class third party software (and SaaS) in the ways which best meets our needs.  Mattermost helps enable that paradigm.

Zero Trust; eat dogfood and drink wine

As a Zero Trust provider, Zero Trust is important to us.  Duh.  And, as a startup, we always eat our own dogfood and drink our own wine.  Fine, what does that have to do with Mattermost versus Slack?  Everything.

Enter our JavaScript-based Zero Trust SDK for securing web apps (and Chromium based frameworks like Electron) applications with code.  And only code.

The JS SDK puts Zero Trust into Mattermost clients (browsers, thick clients).  What does that mean?  When I use Mattermost from my Chrome browser, then the Mattermost code (aided by the JS SDK) establishes a Zero Trust Mattermost connection to our Mattermost servers, without a VPN client, without DNS configurations and without infrastructure.  Code replaces configuration.  As a user, I just, well, use Mattermost with no VPNs etc. in the way.  It doesn’t matter where I am .  It doesn’t matter where the Mattermost data is.

Not in the Zero Trust fan club like us?  Then you have the freedom and flexibility to deploy Mattermost in a different way – the beauty of Mattermost’s open source approach.

How Zero Trust Mattermost looks to a user:

Ok, every user is happier when not on a VPN (riddle: who is the only party in the world that likes VPNs and firewalls?  Answer at the end of the post).

But what does all that mean from an administrator perspective (admins, DevOps, NetOps).  Simplification, automation and a better night’s sleep.  No VPNs to manage.  No DNS complexity.  No open firewall ports.  Far less risk of ransomware.  The ability to innovate – e.g. fully automated deployments in a complete Infrastructure as Code (IaC) model.  It doesn’t matter how many features a SaaS solution may have – can you innovate with it and fully automate it within your model, or do you need to shift your model to fit what knobs it exposes?

Again, Zero Trust may not be the food or wine you are consuming, but many software companies will be better positioned to dogfood their services, innovate and automate with Mattermost, considering how important messaging/communication is to most software companies.

How about from a security perspective – CISO, CIO, security, SecOps and DevSecOps type folks?  End-to-end Zero Trust which is impossible to get with any other solution.  Impossible?  Yes, because if Zero Trust is not in the app itself then by definition other ‘things’ must be trusted, such as the host for example, or maybe even (shiver, shudder, shiver) a LAN/WAN, VPN concentrator or firewall.  Trusting vulnerable things is no bueno from a security perspective.  Our folks labeled this as SaC (Security as Code).  So, our IaC meets our SaC, inside of Mattermost (just by leveraging our JS SDK inside the awesome Mattermost software)!

Just dialing that down a notch – both our Mattermost clients (browsers or their Electron based clients) and Mattermost servers are now invisible to the Internet and invisible to any network.  If a user session is properly identified (dive deeper here if strong identification (no, IP addresses don’t count!) is important to you), authenticated and authorized then it can open a Zero trust application connection.  Else, no soup for you.  Yes, full Zero Trust…as code, meaning the users and admins are not running the soup line.  All enabled because Mattermost is based on open source and gives us an extensible, flexible, software-only base.

How Zero Trust Mattermost looks from a security perspective:

Note: the Fabric Routers are containerized or virtualized software which deploys anywhere and enable application specific (in this case, Mattermost, only!) Zero Trust overlays which make the client-side and server-side dark (invisible) to the Internet, WAN and LAN.  NetFoundry open sourced them, as well as includes Fabric Router based private SDNs in our SaaS services.  Only identified, authenticated, authorized traffic is routed by the Fabric Routers, and each side opens outbound only ports to the private Fabric Routers, closing all inbound ports to all networks (remember, the WAN is a vulnerable, juicy target…don’t risk your Mattermost data, or any data, on the WAN).

MattermoZt

Something this cool needs a name.  Our lead developer coined it as MattermoZt.  MattermoZt is Zero Trust Mattemost, leveraging our Ziti (open source) SDKs.  This story started with the fact that Mattermost is open source based, enabling permissionless innovation, in this case for security, control and visibility.  Due to the excellent Mattermost software, this story then continued to today in which Mattermost is a critical communication tool for us.

What’s next for our MattermoZt?  We don’t know but we do know we’ll be able to continue to innovate with it.  Similarly, other orgs may not need Zero Trust, or may use some other Zero Trust solution, but we believe that orgs which value innovation, open source, automation and control should consider Mattermost as their communications solution.  Finally, we applaud Mattermost for focusing on their core early adopter communities.

Answer to riddle: cyberattackers (bonus points if you remember what the riddle was, or didn’t speed read over it to begin with).

 

Discuss On: