The Small Things in Life
11th of November 2015The 11h of November marks the celebration of Armistice Day for my country of origin, and thus it is a bank holiday, giving me the time to sort my random thoughts of the last week, and putting them to paper, or at least to bits and bytes. And my mind has been wandering lately in the vistas of microservices. Services dotting the application landscape of an organization much like island groups dotting the ocean. Geographically separated, but culturally linked.
The world, or at least the organizations within the world, have barely implemented their service oriented architectures, and here is the next best thing, taking the concepts of SOA and running them to their perceived extreme. I take the words of Martin Fowler as a form of definition, introducing microservices as an approach to develop a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms (such as a REST API). Very much an IT view on things, so definitely a technical architecture.
Where services in a SOA context are linked to a certain layer, introducing business entity services, technical (or utility) services, orchestration services, and whichever additional layer you might introduce, the microservices encapsulate each of them a business capability, with a bare minimum of central management. The main selling points for microservices are the facts that they are independently deployable and scalable, so that there are no deployment dependencies, and their loose coupling, enabling their development in different programming languages. Both promises that were made to us by the introduction of SOA as well, and their success stories such as Netflix are well known.
Over at the DZone website, Bozhidar Bozhanov arguments in his article that the listed benefits of microservices exist just as well in monolithic applications. And he is correct to argument these. There is nothing wrong with, as I call them, silo architectures. However, as with all architectural styles, it has its benefits and risks. Scalability and impact of a deploy are risks more easily incurred with a Silo Architecture, but if you can mitigate these risks, or their relevance (for example in terms of frequency of occurrence) is negligible, this architecture is a valid choice. One caveat is that the article strongly focuses on the technical “benefits” of the microservices architecture, and takes no heed of the linked organizational practices and business process impact. He does however have a point about the need for transactions. Within the SOA sphere, distributed transactions, especially crossing application server or virtual machine boundaries, are a tricky business, and compensation transactions loom just around the corner, ready to introduce a whole new level of complexity. Since microservices attempt to take the concepts of SOA to their extreme, the risks are along for the ride.
Melvyn Conway, 1967
By organizing these services around business capabilities, Martin Fowler arguments that these microservices tackle the problems caused by Conway’s Law. You get cross-functional teams instead of siloed functional teams. However, it would seem to me that you just redraw the communication structure, and the solution architecture still mirrors this. To think the introduction of microservices and their decentralized governance model has no impact on business operations is a bit shortsighted. The organizational structure of Netflix shows that this is not the case.
But let us list the different stated benefits of microservices, which are just the usual suspects in terms of manageability of the solution and impact reduction (during upgrades as well as fault scenarios).
1. Independent scaling
2. Independent upgrades
3. Easy maintenance (code restricted to one function/business capability, thus easier to understand)
4. Potential for use of different technologies
5. Fault and resource isolation
6. Improved communication across team
These advantages come at the cost of increased complexity for stringing these individual business capabilities together into a solution for any given business problem. For this, the design patterns rear their head. As the most common of these, we get the Aggregator Pattern, which is the orchestration from the SOA patterns according to the venerable Thomas Erl, the Proxy pattern, the Chained Pattern (flirting with choreography patterns), branching to use parallel processing and aggregation of results (like for example actors in Akka), Async Messaging and so on.
The conclusion is simple. As always, the course of action is similar. Whether or not to adopt the microservices way of thinking, a determination needs to be made where you want to put your benefits and risks. Reducing the impact of individual components in your landscape increases the complexity of compositions. Weigh the pro and contra arguments to see whether an organization is ready to adopt or to pass on this architecture. Resist the urge of the first mover advantage, and exercise rational thought. It will pay off in the long run.
| Thought | SOA | Silo Architecture |