Microservices and SOA: the uphill battle. In my previous article on the integration stack, we discussed all of the digital integration stacks.

We had discussed the relationship between SOA and microservices, two types of architecture that are total opposites and at the same time very close. Thus, it is common to read literature about anything and everything about this infernal couple, such as:

• Microservices will kill SOA.

• Microservices are SOA well done.

• Microservices are not SOA.

• SOA are microservices and that's all (see Uber).

• Nothing is common between microservices and SOA.

It almost goes without saying that the truth is much more subtle and less Manichean than that. So what exactly are the differences between these two types of architecture? How are these architectures so close and so different at the same time? How can an IT architect handle all of this?

If we had to sum it up, we would say this:

But first, let’s take a step back. Both architectures define a way to design by services, but with different goals:

• While SOA focuses primarily on exposing a legacy application through services, microservices are about defining a software with services.

• While SOA seeks to expose a large number of services to make them available to all, microservices are about defining small in order to be scalable.

It is, therefore, clear that these architectures do not have to be opposites, but rather should be complementary. We must, therefore, be wary of any SOA bashing, which would only be the result of the opposition of two worlds that do not understand each other. While microservices come from the world of software development, SOA is primarily from the world of IT architects. When we take a closer look at the literature, the similarities are striking.

For example, as we traditionally speak of enterprise architecture, the domain-driven design that governs many microservices projects is already a kind of entreprise architecture. Past a certain size of microservices teams, architects of these teams should be aware of all the IT, both technologically and functionally. Doesn't it remind you of anything?

Then, of course, after understanding differences and similarities, we must now understand how to make these two types of architecture coexist.

Two issues are raised by this coexistence:

• Do they have a common denominator?

• Will one kill the other?

For the common denominator, the answer is simple. It is API management. Both are likely to be made available over the internet. Both gain from having a good documentation and good governance. Both gain from using an API management solution.

Regarding the risk of killing, it is real and we must think carefully about coexistence. According to the reference book Building Microservices written by Sam Newman, microservices will themselves expose services from a legacy application. Two choices are available to handle this:

• Define governance (but that may be complex and hard to monitor).

• Use microservices-oriented ESB as Tibco may propose, for example (and surely other actors in the very near future).

There's one last important point for us. Choices of solutions for both architectures must be agnostic on environments. They must be able to switch from on-premise to the cloud and vice versa. This approach is to dig, as literature on microservices agrees with using different solutions for the implementation, while at the same time limiting these choices of technologies. The problem is that market maturity is not that rich, and very few solutions correctly answer the question of deployment for SOA solutions. So it requires making the right choices in SOA and Microservices solutions.

As we have seen, microservices and SOA are born to live together. Only time will tell how this cohabitation will happen, exactly, but it is sure that the debate is not about the relevance of each of them. In addition, we see the arrival of SOA solutions that are Microservices compliant. It is, therefore, important to prefer technical solutions that are agnostic on deployment choices in order to establish an architectural strategy aligned on the roadmaps of the relevant technical solutions.