A recent article by James Lewis and Martin Fowler has kicked off a discussion about “microservices” and SOA in general; one of the few topics in the API community besides Hypermedia that’s pretty much guaranteed to generate some healthy debate. The original body of work defines the characteristics of a microservice:
At least some portion of the community expresses some incredulity that the talking points are enough to justify a distinct concept from the more classic idea of SOA that was first put forward somewhere in the neighborhood of 2005. Many companies have architectures that would check all the boxes above without ever having heard the word “microservice”.
Even among its originators, the term doesn’t seem to have a perfect definition with wide consensus. A talk by Fred George on the subject in Barcelona adds the “micro-” back in microservices and puts forward some more radical assertions regarding their nature:
Although microservices might be SOA with a modern veneer of HTTP, JSON, and polygot, the concept of a “micro microservice” (that 200-500 LOC sweet spot) is worth considering in a bit more depth. In my own experience, not all services can fit into this size, but services that do are remarkably more stable than their counterparts — and for anyone who’s an operator as well as a developer, building a completely autonomous system is an idyllic vision well worthy of pursuit.
These tiny services have some major advantages over their heavier counterparts:
I ran some inventory of our own production services, and came up with a few that do in fact make the 500 LOC microservice cut:
git push heroku masterroute.
A few others didn’t quite make weight, but are still small:
(Jamie Hodge points out that many of these services lack full databases and therefore might better be described as coordinators. The more limited state which they maintain simplifies their operational characteristics to a large degree.)
One common trait of all the services listed above is that their autonomy is remarkable. We have some basic alarms on them in case they go down, but they go off rarely. Being deployed on the Heroku platform is certainly a big help here, but also that their concerns are so narrow and unchanging that there isn’t a lot of room for bugs to hide.
I suspect that 500 LOC isn’t enough to box in all concerns of many components, even if they are quite narrow in scope – anecdotally, most of our more important services easily blow past this limit. I’m also not quite at the point where I’d replace my unit or acceptance tests with self- or business monitoring (also one of the assertions made above).
SOA bestows a huge number of architectural advantages, but we probably want to be careful to keep its expectations in check. Boiled down to a fundamental level, SOA is about introducing very hard isolation between components that can result in big gains in organizational and operational effectiveness, but by extension leads to component boundaries that are more difficult to evolve.
The less desirable features of a SOA-like system include the following:
Although not meant to sound too bearish on microservice type architectures, the short version is that it’s not just about building the system — it’s also about building the tools, processes, and infrastructure to operate it. Larger companies will almost inevitably have to move to something that looks like SOA to keep forward progress possible, but it might not make sense for smaller shops to rush into it headlong, even if the technology is really cool.
Wikipedia nails this idea in a single line:
Significant vendor hype surrounds SOA, which can create exaggerated expectations.