Plenty of Fish in the Sea

2nd of July 2016

The world of IT is prone to hypes when it comes to new ideas and technologies, and Technical Architects (together with developers) are more easily swayed than most in the IT business when it comes to the introduction of novel things. We tend to get excited very quickly before more rational inspection sets in. The “kid in the candy store” phenomenon is not a rare occurrence. As it was in the past with the introduction of SOA, so shall it be in the future present when it comes to Microservices. This got a strong boost in 2014 by the endorsement of Martin Fowler and the launch of the book “Building Microservices” by Sam Newman.

The main point of the aforementioned book on how to decide when to cut up your codebase into smaller pieces, is derived from Robert C. Martin’s definition of the Single Responsibility Principle: “Gather together those things that change for the same reason, and separate those things that change for different reasons.” An additional element for me is the frequency with which the thing changes. As already shown in the graph by Jim Sinur, hard coding a solution (in for example a monolith), or as Jim Sinur states it: "Application Development over Process Automation" is fine as long as the frequency of it changing is near zero. Or at least near enough not to warrant the additional effort to set it up in with more flexible adaptability.

 

Some articles online hail the coming of Microservices by coupling it to the virtue of choreography. Where choreography certainly isn’t a new concept, and was investigated to some extent during the different SOA approaches out there in the coding world, the common SOA would still employ mostly orchestration as a standard. Microservices architectures seem to prefer the other way. Articles on the subject even go to lengths to convince that orchestration is a dirty word to be chunned in any discussion between architects of different persuasions. The downsides of choreography (point-to-point integration being the principal one) are mitigated by introducing an event stream to which the Microservices can subscribe, based on a state in the message to determine whether to act upon any given message. To me this is just the application of the Event Driven Architecture where agents react to business events, but taken one step further to include technical events.

I won’t go as far as to say there is something rotten in the state of Microservices, but it is definitely not all roses and sunshine. The effects of having a steep increase in number of services to host (swarming the sea as hundreds of fish) and maintain within an organization could have detrimental effects on manageability and communication plans as discussed in a previous thought. But I don’t reckon an architectural choice will ever exist with only pros and no cons. No gains without risk.

But what about the business process? The importance of the business process comes into question when looking at an architecture with such profound impact on how to structure your business, and where responsibilities are ties to services (or agents) that react to specific business and technical events to perform an atomic task. If responsibility and execution are cocooned off from the rest of the enterprise, should we still string all these separate actions together into a coherent ensemble? There are certainly several components (such as Twitter's Zipkin) that allow for tracking of messages as they make their way through countless of these Microservices in order to track the business transaction. These frameworks are usually based on the Google Dapper paper.

The description of the business process, even in such an enterprise that would work completely reactive to these technical and business triggers, can still help visualize what a company does, in order to form and inform the different stakeholders in the way of things. Thinking in services for SOA where there is a clear orchestration present, can already be a challenge for functional and technical analysis. Thinking in reactions to business and technical events is a level of abstraction further. The process can certainly also help the optimization tracks where the coherence can be taken into account, as opposed to doing point improvements, based on a Microservices domain. The deductions made based on the synergy between the services can be an additional tool in the Microservices improvement arsenal. It could certainly help with the impact analysis, should the need arise to adapt an existing service (or introduce a new version of said service).

Camunda’s white paper on BPM versus Microservices brings up another interesting point: The problems associated with canceling a long-running process become a tad more difficult, as all possible services in the chain need to be questioned as to where the process is in his execution. Compensation steps (if needed) become a bit more tricky as well, although we can imagine designing Microservices with a compensation capability built in when this might occur. The example given by Camunda is the order service which is cancelled before shipping of the product has begun.

All other manners of synchronization and interruption become more difficult for this reason as well. Imagine a process that needs to escalate id it should take more than a predefined timespan. Since the Microservices flow has no concept of how long its business transaction is already active, implementing this means making the services aware of the transaction they are part of, and maybe passing along a transaction start time (correlated with a NTP server), and basing logic on this time in regards with the system time. This time is more than likely dependent on the business context, which the individual service doesn’t know either. It might get called in multiple different business transactions as part of its reuse.

If the Microservices would indeed become completely autonomous from each other, and no overview of their flows kept, I would become very hesitant to change them even in the least, as the results can no longer be really predicted. The reuse of such service (just as in SOA) is one of the selling points of the architecture. Or each service would generate a concurrent version, leading to the rampant growth of the services portfolio of the organization, rendering the portfolio ineffective. The challenges of a proper Microservices seem even steeper than the now typical SOA, but that just means the architecture also holds an equivalent reward. It is an architecture I only have a vague acquaintance with, but I am going to strive to rectify that in future endeavors.

Thought SOA EDA BPM