One Second Services
May 02, 2016
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.
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 ;-)
Posted by: Josh Graham | May 03, 2016 at 09:14 PM