Candy or Death: The Automatic Halloween Candy Dispenser
Stop Calling It Theft: Thoughts on TheDAO

One Second Services

Microservices have problems. Monoliths have problems. How do you wind up in a happy middle? Here's what I do.

As I talked about in my new book, I'm skeptical of starting systems with a microservice architecture. Splitting a new system across a bunch of different services presumes you'll know how to organize things up front, and lots of little microservices can make refactoring difficult. 
So I start with a small monolith. As I build, I add tests. My tests run very fast...hundreds of tests per second. I run the tests automatically on every change to the code, so speed is essential. 
When the entire test suite for the monolith starts creeping up into the 800-900ms range, I start to notice the time it takes to run the tests, and then I know it's time for this monolith to split into two smaller services. By then, I usually know enough about the system to know how to split it cleanly, and because I have a good test suite, refactoring it into this shape is easy. 
It usually doesn't split in half...80/20 is more common, but it's enough to speed my tests up again. After that, I just keep growing the services and splitting as necessary. The last system I built like this wound up with dozens of services, each with dozens or hundreds of tests which never take more than a second to run. Right in the Goldilocks Zone, if you ask me.


Feed You can follow this conversation by subscribing to the comment feed for this post.

Josh Graham

G'day Ben,

Thanks for the article!

For me, this really is a good metric for one facet of the benefits a microservices architecture affords (that being shorter development cycles).

Another facet is short deployment cycles, so perhaps if it also takes more than a second to spin up a new instance that is ready for requests, then there's another point to look at possibly splitting the service.

Remember, too, that a microservices architecture is an *architecture*. Certain decisions allow us to implement as seperate services if / when we choose to. Decisions like TDD, infrastructure-as-code, autonomous teams, antifragile design, continuous integration and delivery, homogeneous containers which contain (possibly) heterogeneous stacks, etc also play a part in the option of a microservices implementation.

By the way, great book, I enjoyed reviewing it in the early drafts, it helped reshape my thinking about serverless applications – although I'm still not an SPA fan ;-)

The comments to this entry are closed.