The Micro Services Architecture has emerged as yet another old wine packaged in a spanking new bottle. Thought Works and Netflix have published this architecture to the multitude with their blogs and frameworks. People have jumped into the bandwagon and have deployed Micro Services for multiple situations. Look at this video for instance. There are about 3500 person days of work which was divided into smaller pieces and executed using Micro services. It is the old unix style, divide and conquer yadda yadda yadda.
But personally I was still confused. I did not understand how you would orchestrate so many services and make them do something that you want done. I started reading a little bit more and finally found that the recommendations were chiefly around using light weight messaging frameworks, keeping services less than 1000 lines long, independent deployment of services etc. Basically we can break the application into a zillion small pieces, orchestrate the small pieces (in fact they should choreograph themselves using a pub-sub model), slap a rudimentary canonical messaging model on top of them and voila - you have got a web application that is deployable in 1000 small chunks. Look mom no monoliths!
This is quite reminiscent of what we do when we design components. Components can be viewed as strategy classes that can collaborate with each other to form the entire application. Components would manifest themselves as beans in a spring XML configuration file for instance. Now what if the components were to develop wings and fly away into their own JVMs or equivalent? You would end up with Micro Services. In a spring file, the components would collaborate with each other using IN-VM communication. In case of Micro services they need some light weight protocol to accomplish the same kind of collaboration. This can include protocols as diverse as Hateoas to even ESBs.
But, how are you going to deploy so many tiny applications? Are you trading deployment complexity for development flexibility? Do you really need that flexibility? Do you envisage so many tiny teams developing so many services and bringing them all together during deployment?
Now, as a rule, I am not a big fan of this kind of game. It makes me uncomfortable to think that all these services which were hitherto rubbing shoulders in the same JVM as a close knit joint family, are suddenly forced to rough it on their own. Micro services architecture seems to have shifted the complexity to complex orchestrations.
I was faced with the same problem when I was working with a huge bank before. I wanted the ability to construct an SOA without going overboard about breaking the services. It was exactly as was claimed by Fowler in his famous article about Micro services - using UNIX style filters to break the task down into pieces. Basically I needed to break my task into multiple pieces which were stitched together. I explored the possibility of using commons-chain to do this. Finally, I ended up writing a small light weight framework (see OWIZ). This simplified my application considerably and achieved it without using expensive SOA interactions across the wires.
On the whole the following points must be kept in mind when using Micro Services Architecture:
- “Micro Services Architecture” (MSA) is not a new architecture but a detail about implementing SOA. It talks about small services, lightweight orchestrations and such.
- The paradigm shift in using Micro services happens when you think of "end to end teams" (i.e. teams that can develop, deploy and maintain one micro service) and other concepts such as elasticity. Micro services are typically more amenable to be deployed in cloud-based deployment architectures that also typically have abilities to resize themselves to handle elastic loads.
- MSA is relatively new without widespread adoption. As such, there are not too many patterns to follow. This should be treaded with care. (Edit: Increasing adoption somewhat invalidates this claim)
- Micro Services Architecture does not fundamentally change the game on Service Oriented Architecture despite claims to the contrary. Look at this article and this article in Steve Jones blog for example. The point to remember here is that the original OASIS SOA Reference Model had already provided for the possibility of SOA being provided by a design that closely resembles a Micro Services Architecture that is being formulated today. The moral of the story here is that it is not mandatory to go with Micro services architecture to gain from SOA. In fact our recommendation would be to separate the two considerations and make the choice of a Micro services architecture, a decision from a deployment viewpoint rather than be dictated by development.
- Monitoring is a big concern though partially mitigated with the usage of frameworks such as the Metrics library.
- Transactions across micro services need special thought. Micro services are easier to implement for “read only” applications (like the PDP for example).
- Heavy process orchestrations are discouraged for Micro Services. Instead, use simple lightweight messaging or HTTP based architectures.
- Use Conway’s hypothesis to your advantage in deciding on the teams and services i.e. ensure that teams are structured around Service boundaries to ensure cohesiveness and proper boundary separation.
- Micro Services can easily morph into “Nano Services” where the division becomes too fine-grained leading to code and functionality duplication, complex orchestrations etc.
- Some articles on Micro services seem to emphasize that since these services are so tiny, it is easier to rewrite them if they don’t perform as expected. Though this is practically true, it is not a good mindset to approach programming these services.
I would go with a logical separation of services rather than physically separate them. Use something lightweight to begin with. Get into micro services only if these services are coarse enough to be owned by their own product teams.