It is more complex, to be sure. I actually think that we're not yet getting all of the benefits that we'll ultimately get from services. For example, we have o

It is more complex, to be sure. I actually think that we're not yet getting all of the benefits that we'll ultimately get from services. For example, we have one deploy queue still, so we'll likely benefit when teams can deploy even more quickly because they're not waiting on other teams. Multiple services also makes it so that a deploy of one service gone awry is less likely to cause problems on the whole site. I also think that the maintenance will be better over time. It'll be easier to swap out the guts of an individual service. But, we haven't gotten to that yet. We _have_ already gotten benefits from certain things being in separate services. The best example of this is with our "content" service which, as you might guess, provides content data and metadata to the rest of the services. Since this is a separate service, it's able to store a whole bunch of content directly in instance memory, so it can respond to queries very quickly. This part didn't work as well in the monolith. I don't think I'd argue for services in general for a smaller team (Monolith First[1]), but I do think that splitting some bits out that have very different operational characteristics (different traffic patterns or uptime needs) can be worth it, even for smaller teams. [1]: https://www.martinfowler.com/bliki/MonolithFirst.html https://www.martinfowler.com/bliki/MonolithFirst.html