New Service Scorecard

We're publishing a tool today called the Service Scorecard.

Check Out the Service Scorecard →

Why Build This Tool?

The advantages of splitting out services are evangelized constantly to developers and managers. And why not? Who doesn't love separation of concerns, faster iteration, as well as independent scaling and SLAs. However, designing the boundaries of those services is a hard problem and it can go poorly. How poorly? You can easily end up with something much worse than an unruly monolith.

When your functions share space in memory, it's much easier to have tightly coupled interfaces. For example, you may have a rich context object that gets passed down through a series of methods. Small changes to that context object require changes to a whole swath of unrelated functions down the chain. This kind of thing slows down development.

Creating a service and placing certain functions in it encourages you to think about the interface and the boundaries of responsibility. Yet it makes no guarantees. It's bad enough if you are passing around rich context objects between entirely separate functions. When you do this kind of thing with services, you are forcing situations like coordinated deployments. You now have slower iteration than with a monolith.

The Service Scorecard contains a series of reflective questions designed to get teams to think about what a new service will consist of and whether or not it's a net positive for the application.