It’s a story of what happens when cloud technologies work as they should. In this case, the technologies are Docker and Kubernetes.

At Datawire, we use Gitter so that users of our open source tools can chat with us (and each other). We like Gitter because it’s less frictionless to join, especially if you have a GitHub or Twitter account. However, Gitter’s mobile client isn’t great, and notifications in general don’t work well.

Since migrating a community of users is quite a task, I decided to see if I could deploy a bridge between Slack (which we use internally) and our Gutter Chat. A little Googling led me to Matterbridge.

In the rest of the article, I’ll talk about how Docker and Kubernetes really made my life easier, and why. I found the amount of yak shavings remarkably small…which made me really appreciate how far we’ve come in the cloud world.

docker is great
I wanted to run Matterbridge locally to debug the configuration. I followed the general instructions to create accounts for Slack and Gutter, and then put the required authentication tokens in the materbridge.toml file.

I’m glad to see how Matterbridge is available as a Docker image, so I was able to copy its configuration file into a Docker image to test the configuration. I only needed to specify my configuration file when using docker run:

It took me a few turns to debug my configuration, but it was quick and easy. The Docker image did exactly what it was supposed to do: provide a test runtime environment for Matterbridge so that I don’t have to debug it on my laptop.

running in the cloud
The next step was to deploy my configuration to the cloud. We already run a production Kubernetes cluster powered by an API Gateway powered by Envoy, so I wanted to deploy the service in its own namespace.

Also, if I wanted to make the above reproducible, I would have to use Terraform, Ansible, CloudFormation, or one of these types of tools. Here’s an example from the Terraform documentation on how to create an EC2 instance:

As a developer, many of the options above (fields, instance types) are things I don’t really care about. Still, this is the current abstraction if I want to code as an infrastructure.


Kubernetes is more than just a container scheduler. It really gives you the primitives you need to control how your service runs, without bogging you down in the details of deployment.

We’re definitely adapting to the mindset of having a small team of ops people manage a Kubernetes cluster, while the rest of the development team manages its services through Kubernetes primitives.

While in Kubernetes-land it isn’t always sunshine and roses, in the case of the Matterbridge deployment, it was. You’ll have to wait for another article to read about the challenges!

Leave a Reply

Your email address will not be published. Required fields are marked *