1. 1

    I wonder how Envoy compares to Traefik. I found envoy a bit difficult to get started with last time I tried it out (only pre-built docker images, no binaries, nigh inscrutable configs, etc).

    1. 2

      All true. There’s a desire in the community to make these things easier, but I’d definitely say that Traefik is easier to use. That said, Traefik has similar challenges to HAProxy / NGINX from a community standpoint (single company behind it, working on monetization), versus CNCF.

    1. 1

      I’d never heard of envoy before this, and looking it’s yaml config I’m not in a rush to dig deeper.

      1. 1

        Envoy is really designed for machine configuration (the YAML is not for the faint of heart). Most of the advanced config is done via gRPC APIs. That’s one reason why we created Ambassador to manage the Envoy configuration for you.

      1. 1

        Context: Most of my career is at startups with a big focus on growth. When I’m hiring anyone (engineer, marketing person, whatever), the first thing I look for is the ability to learn. A simple question – in your last {job, project} what did you learn? The most interesting people to me are the ones who have clearly reflected on a past experience and have an idea of what they would do differently (and the same).

        1. 2

          I’d be curious to know the flip side here– what notes do you usually take as the employee in one on ones?

          In my case, I carry a black notebook that I scribble reminders in with me to most meetings. In one on ones, I generally try to write down the answers to the three questions (What am I doing well, what can I improve on, what should I stop doing?) I also like to ask about and keep track of projects in the pipeline.

          1. 3

            FWIW, I write down the topics I want to discuss, in advance, so I can remember to cover everything, and I also write down the things that I need to follow up on, post the meeting.

            1. 2

              I use a shared doc with reports during 1:1s so both of us are seeing the same thing and can add to it.

          1. 12

            I agree that the concentration of data at Slack makes them a very valuable target. But I’m wondering if self-hosting is really safer than using Slack:

            • If everyone switches from Slack to Mattermost, this would make Mattermost a valuable target too, and then hackers will target Mattermost instances like they target Wordpress instances.
            • System administration is hard. I would guess that Slack does a better job than most in-house teams at securing their system.
            • For better or worse, most organizations don’t host on their own hardware anymore. They rent virtual machines (AWS, Google Cloud, Digital Ocean, etc.) or physical machines (OVH, Hetzner, etc.). This makes the hosting provider an extremely valuable target too.

            What is your opinion on this?

            1. 11

              I agree, but there’s many reasons beyond those to run your own service, such as policy reasons.

              My main complaint about Slack for FOSS projects for example is that Slack is policy-wise built around being a corporate chat (which has implications to privacy policy etc.).

              1. 10

                I very much agree about Slack not being a good fit for FOSS projects.

                1. 1

                  Is there a service that works much like Slack but with a default-public design intent? Is Gitter the go-to for this kind of thing?

                  1. 8

                    Gitter has become better in that regard (especially with moderation tooling).

                    Discord, Matrix and (almost) Zulip are options, but all with different drawbacks. Zulip has the drawback that moderation features are currently not in the hosted offering. Discord seems to lead the pack when it comes to moderation. I’m obviously not a full-time user of all of them.

                    As much as I dislike IRC, IRC as practiced has a very good model for FOSS: many channels, optional logging and clients geared towards being “AFK by default”.

                    Sadly, there’s almost no chat software built around the needs for open communities.

                    1. 2

                      We’ve used Gitter and Slack for various OSS projects (both ours and others). Gitter’s great because it’s so easy for people to join. However, it doesn’t scale well as more people join a channel, because the search is really bad, no threading, scrolling through history is really cumbersome, etc. Also, the mobile app is terrible at notifications.

                      Slack definitely feels like a closed ecosystem. The workflow of getting an invite, then signing into the Slack client, etc. adds a lot more friction to the process. Plus, switching between Slack chats on the Mac client is SLOW.

                      1. 1

                        the search is really bad, no threading, scrolling through history is really cumbersome, etc.

                        It feels to me you’re looking for email, not a chat.

                        1. 2

                          That’s a simple statement to make, but the difference between email and chat is none of these properties.

                          1. 3

                            It’s time for forums to make a comeback.

                            1. 3

                              They have? Everyone and their dog has a discourse now.

                            2. 1

                              I agree, but how would you characterize the difference between email and chat?

                              1. 1

                                Temporal and conversational characteristics. Chat is built around real-time exchange of short messages, mail is built around slower discussion with larger, self-contained messages.

                            3. 1

                              Not really. We want real-time conversation with people. For example, someone may download Telepresence (one of our OSS projects) and struggle to get it working. Telepresence under the hood does a bunch of networking stuff: deploys a proxy in Kubernetes, sets up a VPN tunnel via kubectl port-forward, etc. So being able to talk to someone with problems in real-time (versus filing a GitHub issue, or email) is extremely helpful to accelerate the debug process.

                              And then, it would be nice to search through and say oh yes, so so had an issue with Mac OS X and kube 1.7 that was like this … but you can’t really.

                          2. 1

                            YES this! I don’t hear this being talked about nearly enough, but I seriously dislike the whole model where individual communities are shuffled off to their own ‘teams’ or ‘rooms’ or whatever. IRC’s channels offer an invitation to collaboration and discovery - NONE of these services offer that, and I don’t understand why so many people are willing to throw the baby out with the bath water like this.

                      2. 3

                        That address only the question of external attackers. But can you trust Slack to keep your data private? I think many people are also worried about this.

                        1. 4

                          I also feel like we should definitely model “attackers” and “state actors” differently. Withing the law of the state Slack is in, the state can just walk in and ask and get things. No amount of anti-intrusion measures can counter that.

                          (In Germany, that’s the same, but at least everything happens in the territory I have my lawyers in :) )

                          1. 2

                            I agree. It’s a very legitimate concern. For example, if I was working for a defense company, I would definitely not use Slack.

                            1. 1

                              We treat slack internally as open to the internet (or assumed to be). No passwords in slack, no secrets of any kind. If the contents of our conversations leaked, it’d maybe be bad, but you have to assume someone will be reading them at some point regardless for potential compliance reasons.

                            2. 3

                              Sure, but you have to know a lot more things. WP is easy to spam, because it’s pretty easy to find. Even if 60% of companies started using mattermost, you’d have to find their instance (is it chat.example.com or is it mattermost.example.com or… ?). Plus it’s not that difficult to fend off wide script-kiddie attacks like this. IP rate limiting, regular patches, etc. That’s not very difficult to do with WP or mattermost. The upside is Mattermost being a Go application has a much smaller footprint of attack surface, plus they take security fairly seriously, and release often. WP started with a negative security outlook and PHP only helped the problem.. PHP is like the opposite of safe and sane(it’s getting better, but still).

                              System Admin is hard, but if you aren’t investing in good people, then chat data is probably the least of your worries.. see Equifax, etc.

                              I’m quite sure Slack also rents virtual instances, so it’s the same issue.

                              1. 2

                                I agree that if a company already self-hosts some services, then it makes sense to also self-host a service like Mattermost, which is easy to install and administrate.

                                Good point about Slack also renting virtual instances.

                              2. 2

                                I know you are not addressing me, but: when you host yourself you can (easily) add additional layers of security. For example put the services behind a VPN.

                                1. 6

                                  True, but I don’t believe that perimeter security is very useful with the open networks we have nowadays (see BeyondCorp).