Services. Because we're all mediocre.

03 October 2016

Progress in the field of software development occurs when developers invent technical solutions to problems caused by their own laziness, lack of discipline and mediocrity. Or, to put it more kindly, when we repeatedly prove that we can’t be trusted to do something, we invent a way to avoid doing it. This is a good thing.

Garbage collection is the most obvious case of this, but the microservice architecture is the most relevant example today.

Working in a monolith requires an incredible amount of discipline. Especially in languages like Ruby, it’s very easy blaze across boundaries, jump right into the core domain and start doing whatever you want. As the code changes, enforcing module boundaries requires sharp eyes and constant care. More than anything else, it requires people to continuously enforce these boundaries.

Enforcing boundaries sounds easy in a blog post about software design. In practice it means repeatedly having awkward conversations with your fellow engineers – conversations where you tell them they need to do something over again. These conversations can range from very easy to incredibly exhausting. In the worst case, they make you feel like a complete asshole. Developer culture is obsessed with the feeling of rapid progress; it’s very hard to be the one holding up the train.

These conversations will only get more difficult as the team grows. It’s easy to help someone make a course correction when you know both who they are and what they’re working on. It’s much harder when you have no idea what their goals are and have never met them.

Worse yet, these conversations also get more difficult as the monolith gets older. It’s harder for people to see a line that has already been blurred by years of drift. In the long run, betting solely on discipline isn’t a great move. It’s better to find a way to embrace our mediocrity.

Architectures where team boundaries align with service boundaries seem to be the key. Rather than rely on developers to repeatedly have difficult conversations with peer teams, you reify module boundaries as service boundaries. The network hops between services force (relatively) clear thinking about seams, entry points and responsibilities. This is a very good thing. In an environment where many different teams are all trying to get things done, system design should largely be a conversation about boundaries.

Thus, service orientation helps you be mediocre and still have a healthy codebase. You don’t need to have legendary discipline (although it’s still the most important quality in an engineer) and you won’t need to feel like an asshole.

comments powered by Disqus