Ramblings on Microservices.txt

Originally sent in a Twitter DM to Robin Biljani.

----

Glad Irma wasn’t too catastrophic for you!

I have similar feelings about Funding Circle, the technologies they’re using, social lending platforms, and the team at Park Assist 👍

OK so, that scenario sounds suspiciously like the “classic” microservice architecture. So it would be… understandable to see this as reasonable simply because it’s fairly common. The logic is something like: this seems to be working for various high-profile orgs, so why not for us? Which is understandable.

There are, however, some serious downsides to this approach. You’ve intuited some of the big ones: tight coupling and potentially high latency (more specifically, one slow service can make many other services much slower). There are many others. For example, it can be very difficult to determine/understand which services call which other services, so it can make refactoring very risky.

So microservices (specifically request/response based microservices) like all architectural patterns, presents a set of trade offs, and it’s important to weigh the costs and benefits against each other — and ideally not in a vacuum, but in a comparison to some other architectural patterns, so as to have multiple options to compare and contrast.

To get a bit more concrete, in order to do request/response based microservices “well” — to reduce the costs to a reasonable level — an org generally needs to adopt a standardized orchestration layer, a service discovery layer, a centralized logging and monitoring system, and a distributed tracing system.

Here are some articles that might be more helpful than my ill-informed rambling:

https://blog.komand.com/microservices-please-dont
https://martinfowler.com/bliki/MicroservicePrerequisites.html
https://www.youtube.com/watch?v=VPPz8TaUYyc
https://juristr.com/blog/2015/01/notes-microservices-fowler-xconf/
https://www.udig.com/2017/06/28/you-must-be-this-tall-to-ride-microservices/

(There’s a tangential rant I could share here but I will restrain myself. It’s about how the term _microservices_ like most jargon subject to the pop-culture hype cycle, has become watered down to the point where people use it interchangeably with SOA, i.e. “just services”. But I’ll skip it for now. Consider yourself lucky, having dodged this particular bullet. For now!)

FYI, there are other ways to implement microservices that _might_ present a better set of tradeoffs for your company. I’m thinking of microservices that, rather than communicating via synchronous request/response (whether HTTP, Protocol Buffers, Thrift, gRPC, or whatever) they communicate asynchronously via a distributed message queue or distributed log, e.g. Kafka, Kinesis, RabbitMQ, ActiveMQ, etc.

I’m sure there are lots of different variations on that specific approach — let’s call it, say, async services — but I’m most familiar with the variants being discussed in the Kafka community. So here’s a few links on this particular architectural pattern:

https://www.confluent.io/blog/data-dichotomy-rethinking-the-way-we-treat-data-and-services/
https://www.youtube.com/watch?v=6lONG_F76To
https://www.confluent.io/blog/tag/microservices/

(That last one is in reverse chronological order, just FYI.)

Sorry if that’s too much to digest, but once I get started it’s hard for me to stop 😉 let me know what you think!