Technical Empathy – the ability to see the system from the point of view of the caller of your code, not just the point of view of your code
— Michael Feathers (@mfeathers) January 26, 2015
Michael Feathers’ tweet about technical empathy packs a lot of wisdom into 140 characters. Lack of technical empathy can lead to a system that is harder to both implement and maintain since no thought was given to simplifying things for the caller. Maintainability is one of those quality of service requirements that appears to be a purely technical consideration right up to the point that it begins significantly affecting development time. If this sounds suspiciously like technical debt to you, then move to the head of the class.
The issue of technical empathy is particularly on point given the popular interest in microservice architectures (MSAs). The granular nature of the MSA style brings many benefits, but also comes with the cost of increased complexity (among others). Michael Feathers referred to this in a post from last summer titled “Microservices Until Macro Complexity”:
It is going to be interesting to see how this approach scales. Some organizations have a relatively low number of microservices. Others are pushing higher, around the 600 mark. This is a bit beyond the point where people start seeking a bigger picture. If services are often bigger than classes in OO, then the next thing to look for is a level above microservices that provides a more abstract view of an architecture. People are struggling with that right now and it was foreseeable. Along with that concern, we have the general issue of dealing with asynchrony and communication patterns between services. I strongly believe that there is a law of conservation of complexity in software. When we break up big things into small pieces we invariably push the complexity to their interaction.
The last sentence bears repeating: “When we break up big things into small pieces we invariably push the complexity to their interaction”. Breaking a monolith into microservices simplifies each individual component, however, as Eran Hammer observed in “The Fallacy of Tiny Modules”, “…at some point, someone has to put it all together and then, all the complexity is going to surface…”. As Yamen Sader illustrated in his slide deck “Microservices 101 – The Big Why” (slide #26), the structure of the organization, domain, and system will diverge in an MSA. The implication of this is that for a given domain task, we need to know more about the details of that task (i.e. have less encapsulation of the internals) in a microservice environment.
The further removed the consumer of these services are from the providers, the harder and less convenient it will be to transfer that knowledge. To put this in perspective, consider two fast food restaurants: one operates in a traditional manner where money is exchanged for burgers, the other is a microservice style operation where you must obtain the beef, lettuce, pickles, onion, cheese, and buns separately, after which the cooking service combines them (provided the money is there also). The second operation will likely be in business for a much shorter period of time in spite of the incredible flexibility it offers. Additionally, that flexibility only truly exists when the contracts between two or more providers are swappable. As Ben Morris noted in “Do Microservices create extra challenges for distributed development?”:
Each team will develop its own interpretation of the system and view of the data model. Any service collaboration will have to involve some element of translation or mapping and will be vulnerable to subtle bugs that can arise from semantic differences.
Adopting a canonical model across the platform can help to address this problem by asserting a common vocabulary. Each service is expected to exchange information based on a shared definition of the main entities. However, this requires a level of cross-team governance which is very much at odds with the decentralised nature of microservices.
None of this is meant to say that the microservice architecture style is “bad” or “wrong”. It is my opinion, however, that MSA is first and foremost an architectural style of building applications rather than systems of systems. This isn’t an absolute; I could see multiple MSA applications within an organization sharing component microservices. Where those microservices transcend the organizational boundary, however, making use of them becomes more complex. Actions at a higher level of granularity, such as placing an order for some product or service, involves coordinating multiple services in the MSA realm rather than consuming one “chunkier” service. While the principles behind microservice architectures are relevant at higher levels of abstraction, a mismatch in granularity between the concept and implementation can be very troublesome. Maintainability issues are both technical debt and a source of customer dissatisfaction. External customers are far easier to lose than internal ones.
Reposted from Form Follows Function.
Interesting article and I like quite liked the analogy of two fast food restaurant; second restaurant who operates on micros style services may not be good for fast-food but if instead they target their business to different sector of consumer even changing the business nature will help. Any business can be successful if one know their consumer.
Microservice architectures can brings lot of flexibility because its granularity in nature, therefore as a base they can be good before any start-up or recognizing the consumer sections. Once the consumers are decided then yes bringing up to build product will be less hassle than starting from the scratch. However, base itself is not properly architect-ed then yes binding up granules to make something solid can turn into complex thing and even more costly than doing from scratch.
“Do Microservices create extra challenges for distributed development?”: To avoid it if we adhere to some standardization which comes at compromise will lessen the challenges but might gives the output which are less desirable or plain but doable.
I as a layman went through the article; thought of adding my two cents and hope that it make sense. 🙂
There is much more in MSA than philosophy. Alos, there is no denial that MSA is a set of patterns derived from SOA, but this time much more domain oriented. Companies like Amazon, Google, Azure are using MSA all over the place for years, and they are kind of solving the complexity through various tools and services with real success. What are the practical issues that you’ve encountered while developing a MSA platform?
Companies like Amazon, Google, and Azure are very good examples of where the style is very appropriate. That’s because all three are platform companies. There’s no issue of pushing complexity outward, because that’s exactly what you want – a bunch of low-level items that you intend to compose into a unique application. Netflix is more representative to the type of line of business application that can benefit from a well-designed MSA. It all comes down to context and fitness for purpose.
Regarding issues I’ve personally run into: none, but that’s because the organization I work for doesn’t have anything that is appropriate for this particular style. We’ve got some very small, focused services that meet many of the criteria and have been very successful. What we don’t have is an entire application constructed from these type of services.