Micro Management for Micro Brains - why Micro Services suck

It sounds like a great idea. Instead of building a monolithic enterprise application, just split functionality into small components and run them independently in their own processes. These micro services need to cooperate with each other to provide more advanced functionality. For that purpose, they are going to communicate with other micro services.



Such an approach promises better flexibility in changing and deploying systems. If only a small part of the functionality is changed, this will affect only a small number of micro services. Or, as we like to say, "small is beautiful".



What a wonderful new architecture style. Eventually, we found the silver bullet. Agreed, micro services may not be a silver bullet, but, at least, they are silver shotgun shells.



This idea is not new, though. For example,  "actors" are providing the same kind of solution. They encapsulate fine grained services behind message-based interfaces that enforce argument and result types to be value types, so that no side effects may occur. In order to achieve a common goal, actors interact with each other.



"Micro services" contains the term "services" for a reason. Micro services basically introduce a stripped down resurrection of SOA.



However,  the delicious looking and tempting apple may be poisoned. There are several "challenges" when using this architecture style:

• Complexity:  If we are building a non-trivial application, it will reveal inherent complexity.  For the moment, let us assume, there is no accidental complexity involved. When this application is based on micro services, where does the complexity go? Unfortunately, it does not go away, but manifests itself  in complex connection and cooperation patterns between tiny services. 


• Modifiability: If our enterprise application is partitioned into small micro services, we only need to touch and redeploy small services for changing the system, instead of facing the mess of application monoliths. In theory, this is a perfect solution. In practice, it is not, because for non-trivial changes of micro services, we may need to rewrite  a lot of other micro services that are connected with the modified micro services. Remember, the complexity does not disappear but shows up in the topology of the micro services network. This does not only affect design but also evolution, assessment and refactoring activities.


• Internal  Architecture Quality: Architecture is about strategic design. Its main purpose is to map the problem domain to the solution domain. If micro services are used as the primary concept for structuring functionality, the problem domain will be mixed up with the solution domain, especially, if the usage of micro services is not transparent. Thus, the architecture will very likely be technology-based instead of problem-based. Note, that this is another variant of Conway's Law: "show me your architecture and I will know the technologies it depends on".


• External Architecture Quality: As we all have learned the painful way, main reason for architecture failure typically are not functionality aspects.  Main reason are quality attributes like performance, extensibility, fault tolerance, and so forth. For each of these quality attributes, well known design strategies and design tactics are available that present alternative solutions how to introduce the respective quality into the architecture. Architecture design uses utility trees and scenario diagrams to specify external quality requirements. These quality attributes are often crosscutting, which is why complex networks of services make it hard and sometimes even impossible to design and implement  quality attributes.


• Infrastructure: We may use a technology stack for leveraging the micro services architecture pattern or we may build it ourselves. The latter option is a no go, because we are not in the middleware business, at least most of us aren't.