Steven Sinofsky of a16z (previously Microsoft) probably first coined the phrase, “Don’t ship the org chart”. I think there’s a new variant of this worth discussing: shipping the microservices. I’ve been reviewing a few products in depth recently for different reaasons, and once you see it, it actually becomes really obvious.

Assuming it was Sinofsky who originally talked about the org chart, he was making a great point that was obvious (in hind sight). All organisations have a habit of creating little silos – often along the lines of specialism. For example, we split people into “development team”, or “finance department”.

Some product features will sit within a specific silo. These features tend to pass through into the product quickly and effectively, and the eventual implementation is good. But most features don’t; they cut across a number of teams – maybe Customer Services. These features require the divisions within the organisation to work closely and effectively together to deliver effectively. Of course, that rarely happens.

The end result is that you can look at the good and bad in the product, and map out the organisation that created it.

The signs of a microservice product

Designers of microservices often adhere to a doctrine internally. The process of defining a new microservice result in drawing bright lines around some set of capability. In Domain-Driven Design, this is called the “bounded context”. It’s basically a form of design by taxonomy: “this service handles invoice data, this other service handles payments”. We humans love to sort things into little boxes.

Of course, the real world rarely works this way. Any form of classification is messy. For many years there was an argument about whether Red Pandas and Giant Pandas are similar species – as you can tell by the name, originally everyone thought they were closely related. Turns out a Red Panda is actually closer to a raccoon. For similar reasons, Pluto was no longer classified as a planet not that long ago.

Defining the right boxes, and then placing objects into their correct box is difficult. Designing microservices is even more complex: you’re attempting to define the right boxes and then design services that will fit in those boxes. All the goalposts here are moveable, sadly.

Manifest Microservices

Netflix is a relatively well-known microservice architecture. When you look at the application, sadly, a lot of that seems to bleed through. You can search for things, and there’s a specific “Search” area in the application. Something keeps track of what you’ve watched, and sure enough there’s a nice “Continue Watching” list. Algorithms look at what you’ve watched, and try to predict what you’d enjoy watching. So we also get nice lists of “stuff”, some of which are interesting, many of which are not.

Lots of boxes; some literal, some figurative. What’s missing, though? Cross-cutting concerns. For example, I can sit down at 6pm or 11pm, and it will offer me exactly the same list – even though I very rarely stay up beyond midnight. Netflix will offer me Watchmen at either time, when a small bit of data analysis and filtering or weighting of results should rank such films way down the list.

Google Drive is another application which shows some of these smells. I’m not totally sure whether this is because it genuinely is microservice-based, or whether the design is just consistently bad in some areas (nothing much is published about Drive). But, for example, I can right-click on a file and move it to a new folder – but I can’t open the folder containing the file. Seemingly, associating files with folders is one box on its own.

The frustrating common theme is that many of these apps have a great range of functionality in pockets, and within those pockets they work well. But you then have these common use cases that they simply fail at, where you have to cross from one pocket to another.

Sometimes the pockets are obvious – the capability segmented into a specific page, or a specific block on a page. Maddeningly, if this were an abstraction leaking through to layers above you know some engineer would be all over it.

Side-stepping Conway

One of the reasons many organisations choose to implement, or migrate to, microservices is to attempt to defy Conway’s Law. By deliberately implementing components that are significantly smaller than organisational units, the thought is the services will not reflect the communication structures of the developers.

However, the barriers between services are – by design – pretty rigid. Data from one is not easily married to data from another, without the two services co-operating in some fashion. The smaller the footprint of responsibility for each service, the more likely a series of high-level services will be needed to tie them together in a sensible way – but this is more easily said than done, and this aspect of the platform is often neglected.

I would love to see some great examples of microservice-based products that avoid most of these problems. Having a great user experience is so often the end goal, but so rarely achieved.