Something Old, New, Borrowed and Blue

8th of November 2016

No problem is created equal, and thus no architecture could hope to cope with them all, lest it be watered down to a generic one-size-fit-all solution that in reality fits none of the problems encountered. As it is the case with Micro Services. Having gotten the label “SOA done right”, it has some heavyweight supporters, but also those who took this label the wrong way and are adamant that this new flavor is nothing new under the sun. Those who claim that all these supposed benefices from utilizing Micro Services are there as well in Classic SOA (or the Thomas Erl flavor as I call it), and are even present in older paradigms such as Object Oriented programming and the like. I have pointed to articles on DZone in the past, and here is a more recent one pleading the same case. The objections and justifications being made in these types of articles are usually very technical in nature, and although my nostalgic developer persona can sympathize, for me the nuanced difference between classic SOA and Micro Services is not only technical, but organizational in nature as well.


But let us assume that Micro Services are indeed the next evolution of SOA, and apply the Laws of Media to see how it fares:

  1. Enhancement: Micro Services, as so many other architectures before it, attempt to automate laborious and repetitive manual work in order to increase efficiency and reduce (human) error.
  2. Obsolescence: The idea behind the aforementioned label is that Micro Services is a better version of SOA. Its advocates will hammer this point till exhaustion sets in or a dry throat drives them to a drinking pause.
  3. Retrieval: It reaches back to a time when code was simple, atomic, easily maintainable and deployable. The Micro Services paradigm equates reducing the size of the code base to these goals. As it was, so shall it be!
  4. Reversal: “When pushed far enough, the new medium flips or reverses into a complementary form”. And here is the kicker, or at least the one I put some belief in: Classic SOA and Micro Services are indeed complementary as they address different problems or at least different nuances of similar problems.

The difference in the problems each paradigm solves is stated as such by Bob Rhubart of Oracle: Classic SOA is a strategic initiative to change the IT of a whole enterprise, separating it into different services, thereby allowing the enterprise to be more flexible. Micro Services are a way to structure an application, involving only the team responsible for the application. These words seem to implicate that at least the scope of each initiative is different: One is Enterprise scoped, the other application scoped. The involvement that he is speaking about is also a serious consideration with a lot of impact: Reducing the involvement to a single team taking full responsibility also reduces the reusability of said code. The moment your code base is used for processes outside the purview of your team, your unilateral decisions to alter, replace or redeploy shift to a bilateral or even multilateral decisions, ending the strong points of Micro Services.

Just as with other architectures, there are levels of incorporation open to a company to adopt any architecture, and they are the same for classic SOA as well as Micro Services. The most natural is to add them in the periphery of existing applications, letting the services form a logical extension of legacy code. The second possibility is to start each green field development in the new architectural style of choice, and a third option is to actively start cutting up existing applications into services, paving the way to a complete conversion to the paradigm.

When a company would decide to go full Micro Services with Netflix as a shining beacon of hope, this even has implications on how this company would treat future endeavors of process optimization. Supply chains or supporting processes don’t magically disappear when a company converts all of its systems, however adapting a process running over several departments would become more difficult. As the involvement of each part of the process is represented by these Micro Services is completely mandated to the team responsible for it, they will focus on the optimization of their process part. The buck for them stops at the boundaries. They sign off on the input they receive from the previous process participant, and guarantee the quality of the output their piece generates. Within their piece it becomes a lot easier to optimize, but redesigning a process becomes that much harder.

As most companies would not like to limit themselves to this degree (even with all the benefits such an approach might yield), hybrids or best of breeds will emerge naturally within organizations, leaving open the options to attack the process on a whole instead of just optimizing the pieces. As with all architectural decisions, it comes down to weighing pros and cons in order to take decisions beneficial to the company. So to all professionals that have thrown themselves into paradigms that seem to clash with Micro Services such as for example SOA or BPM, don’t despair. There is work for you to do yet.

Thought SOA