REST API Notes for 2016/10/17 - Microservices Deep Cuts
Normally, in this newsletter, I like to quickly hit upon some valuable resources that bubbled up to my attention. But there's a different class of work that takes longer to savor. However, with a bit of effort, these pieces yield tremendous insights.
THE HIDDEN DIVIDENDS OF MICROSERVICES
The first "deep cut" comes from Tom Killalea. Writing on the ACM site, his piece is entitled "The Hidden Dividends of Microservices". There have been times when I've had to debate the merits of sound service design with staunch RPC-over-HTTP advocates. I'll readily concede that RPC is easier to "get out the door". But the initial speed is far outshadowed by the cost to integrate, maintain, and update; all things that all-too-many defer to post-launch consideration.
API implementers have recognized the value of microservices: clear separation of concerns, minimal coupling across domains, and potential for a higher rate of change. What Tom details in his article, however, are those post-launch benefits that may not get accounted for.
In addition, the warning signs that there's a problem with your interface design are gold. Your microservices are troubled if:
- Different services do coordinated deployments.
- You ship client libraries.
- A change in one service has unexpected consequences or requires a change in other services.
- Services share a persistence store.
- You cannot change your service's persistence tier without anyone caring.
- Engineers need intimate knowledge of the designs and schemas of other teams' services.
- You have compliance controls that apply uniformly to all services.
- Your infrastructure isn't programmable.
- You can't do one-click deployments and rollbacks.
MICROSERVICE DESIGN ADVICE FROM 1971
It can be easy to assume that microservices is a new phenomena. One of the most common microservices questions I get is "how big should my microservice be?". While the "microservice" label may be (relatively) new, thoughts on service decomposition have existed for sometime.
Adrian Colyer has been publishing amazing work. His blog attempts to discuss "interesting/influential/important paper from the world of CS". In a recent post he recaps David L Parnas's 1971 paper, On the criteria to be used in decomposing systems into modules. What does 45-year-old work have to do with our modern software architecture? Quite a bit, actually:
"The effectiveness of a 'modularization' is dependent upon the criteria used in dividing the system into modules.
Replace "modules" with "microservices", and you've got a piece that easily shames an average Medium thinkpiece.
Put another way, it is not just about having a lot of itty bitty services, but how you choose to divide the system up.
Adrian not only recaps the major insights, but then walks through two sample system decompositions to identify problem areas (and opportunities). If you are building any kind of system with multiple pieces this post is well worth your time.
WRAPPING UP
I updated webapi.events this morning with the latest info on RESTful API events. Did I miss something? I'm more than happy to update - just let me know.
Till next time,
Matthew (@libel_vox) http://voxpop.co