Microservices, not microthinking


Microservices, not microthinking

Let’s get one things straight, I like micro services (the why we’ll get to later).

When you design any system, you have to understand the user needs and have an architecture that supports it (the goals and constraints of the system, and one that helps mitigates the risks you know about). I’ve seen a few microservices implementations now and for many, the ‘design’ word seems to be a naughty word. There is nothing wrong with design.

What is important is the right level of design – what keeps you up at night? What are the big scary unknowns with what you are about to build? Worry about those, and do enough design/experimentation to put something in place to deal with them.

But microservices must be simple, look I can tweet one

so simple my dog could do it...

So simple my dog could do it…

class App {
  String home() {

At the same time, any APIs need to be designed. What do I mean? Well, if you’ve ever used a poor API, where there are inconsistencies, or API calls at very different levels of granularity all mixed in you’ll understand!

APIs should be consistent, i.e. people should be able to infer consistent behaviour by looking at the API. For example, if, /customer/addresses gives you a list of that customers addresses (current and previous), then /employee/addresses should do the same thing for employees. Make sense? People have little time for poor APIs, and in larger systems the mass of inconsistent spaghetti rapidly increases.

Design your APIs for consistency, and make sure the pass a common sense test. Have a small number of people oversee the APIs …not designed by everyone on the team.

By all means get going quickly to prototype, but refactor the API asap for consistency. Make sure the APIs echo the domain of the customer, not yours! for example if you customer talks about containers and shipments, those nouns should be in the API, not ones that you invent e.g. parcels and deliveries just because you don’t like their language. It’s their system not yours! Read a good book Domain-Driven Design: Tackling Complexity in
the Heart of Software by Eric Evans  see alsohttp://en.wikipedia.org/wiki/Domain-driven_design.

Think about purity and practicality if you can make a local call to a service in the same process space using a language based mechanism, why make an external HTTP to some kind of service lookup, to redirect to another node? You are adding complexity and uncertainty that someone (read you) needs to deal with. See Martin Fowler’s article here http://martinfowler.com/articles/distributed-objects-microservices.html

A great example in that article, and worryingly one I’ve seen is a very fine grained API that needs to be called many time for each person and involved complex cross-system integration to get a very simple answer, and for purity had been built to match the rest of the system, yet each of these fine grained calls took 2 seconds to complete. Poor in isolation, but appalling when it needs to be called ten times to get something that would have previously been retrieved in a single call!  So make sure you balance purity and pragmatic integration.

Read Simon Brown’s Distributed big balls of mud. Just adopting microservices won’t fix problems you have.


So why do I like Microservices?

  • They encourage people to write the smallest thing possible to get the job done – focus on the value, not the tech or the cool.
  • Reuse – they encourage people to throw away and re-write rather than carry legacy baggage, critical for rapidly evolving systems


We live in a world where we chase the next thing that we think solves the problem without really addressing it – we move the complexity elsewhere.

When you get to an MVP, make sure you can understand your APIs, how they are surfaced at runtime, how you monitor them, and make sure you understand the runtime dependencies! (some scope for a future post there).


You have lots of work to do on monitoring, management and deployment, don’t skimp!