09 Jul 2018

In recent years I’ve seen several startups go for a microservices-first approach. This is my two cents, distilled from watching those projects unfold.

If you’re Netflix or Amazon, one of your big problems will be coordinating different teams and projects. Sooner or later, you’ll hit a situation where you need to coordinate the release dates of five different projects to get something major launched.

On that day, you’re hosed.

One sub-project will always slip, so five teams sit near-idle for a month, burning time and money. Fast forward a year or two and you wake up to six-month drop-dead release cycle with a month-five code-freeze and a month-four crunch window. It’s horrible. And it never improves, because coordinating groups of people is hard. [Citation: Theresa May, 2016-2018]

If you’re in that situation, microservices are brilliant. They allow you to turn a human-coordination problem into a system-coordination problem. System coordination is still hard - supporting multiple versions, dealing with concurrency issues, building distributed, fault-tolerant systems - these are all properly, Computer Science hard. But they’re tractable. Computer concurrency problems are a pain, but you can solve them. People concurrency problems are the nightmare scenario second only to herd-of-cats concurrency problems.

Microservices turn people coordination problems into software coordination problems. Microservices are the way out of a quagmire.

But what if you don’t have those problems? What if you only have twenty-odd developers, and you can coordinate just by talking to them? What if your project coordination problems boil down to, “asking Andy and Catherine if they’re ready?” Then by choosing microservices you’ve created API versioning problems, created concurrency problems and created distributed, fault-tolerant problems, all for no benefit.

In the absence of the relevant people problems, microservices create software problems. Microservices are the way into a quagmire.

comments powered by Disqus