1. 11
  1.  

  2. 2

    There has been a lot of discussion about the scope of microservices. When is a microservice too big? When is a microservice too small? I think a microservice that is “forgettable” might be too small.

    Although at first glance a microservice that you can set up and forget about sounds great, but all software rots, so the remaining struggle is how fast we’re noticing and dealing with that rot. If the typical workflow is to set up teeny, tiny microservice that’s finished and you start it and don’t look at it again until five months down the line when it’s too expensive, or it doesn’t report stats the way your other services do now, or the memory leak is fast enough that you’re not comfortable with monit just restarting it when it goes down, then that problem is that much harder to fix because you haven’t even glanced at the service in months, or years. We run into similar problems even if a service has been looked at recently if the one person who knew how to operate it leaves the company.

    A few things fall out of this. No service should be scoped so tightly that it’s “done” until there’s a team that is confident in handling long-term support for it. No service should be scoped so tightly that it’s owned by an individual. These policies have operational costs and benefits, but the benefit is organizational, and in keeping code alive and adaptable.

    1. 2

      A few things fall out of this. No service should be scoped so tightly that it’s “done” until there’s a team that is confident in handling long-term support for it. No service should be scoped so tightly that it’s owned by an individual. These policies have operational costs and benefits, but the benefit is organizational, and in keeping code alive and adaptable.

      Couldn’t agree more. Writing the code itself is almost always the easiest part, and what you’ve described (maintenance and socializing/communication) is the hardest.

    2. 1

      Neat to see more Rust in production! How did you pitch doing it in Rust to management? Is Everlane pretty progressive on PL choice?

      1. 3

        We’re pretty conservative in our PL choice (eg. we’re steadfast Ruby on Rails users). Rust was actually an experiment in this regard: which is why we used it for a small service outside of our main application. Given the requirements of this service—high performance and strong'ish reliability guarantees—Rust seemed like a very good candidate. And so far it’s proven itself to have been a good choice!

        I’m nowhere near as fast at building features in Rust as I am in Ruby, but in some cases—such as this—speed of delivery takes a back seat to other concerns (eg. safety and reliability).

      2. 1

        is there any more info on what libraries, features, or design patterns were used? (or point me to the source if I missed it because of my tiny mobile screen) I have been interested in rolling some services in rust, but good complete case studies have been hard to find.

        1. 1

          No, because this is not a high-content article.

          1. 1

            is there any more info on what libraries, features, or design patterns were used? (or point me to the source if I missed it because of my tiny mobile screen)

            This uses the metrics_distributor library to accomplish the aggregate-and-forward design pattern.

            I have been interested in rolling some services in rust, but good complete case studies have been hard to find.

            I’m working on a longer blog post with more in-depth examples and discussion of doing exactly that!