Slim Ouertani is a solution architect, InfoQ-Fr editor and SOA trainer. After completing his Bachelor's degree in Computer Science, Slim spent more than 10 years between multinational companies as an architect, international agile coach and head of IT development department. His main role was to build, design and collaborate in the development of enterprise solutions. Slim regularly contributes to InfoQ-FR community where he is an author of many articles and news. In addition to his SOA certifications (Trainer, Architect and Professional), Slim is certified in Togaf 9, PMP, Spring, JAVA, ITIL, CMMi, and Mongo.
From Microservices to SOA Published: July 20, 2015 • Service Technology Magazine Issue XCI PDF
The term microservice has been a hot topic over the last few years. It gained hype last year and continues its growing trend nowadays. Although there is no exact definition of this style of architecture, the characteristics through which it is described defines it as an absolute breakup with monolith solutions that don't introduce new features compared to SOA. This article is far from the comparison between these models of architecture. Instead, we will try to interpret the transition from microservices to SOA.
During his last recognition, Martin says that addressing a project with a microservice orientation isn't a wise decision as it generates additional risks and headache. He recommends, on the other side, to start with a monolith solution to avoid the burdens imposed by microservices.
Martin recommends moving toward a microservices modeling once the complexities and limitations of monolith become unbearable. Unfortunately, sacrifice the architecture or make an incremental transition can be very costly or even impossible in specific scenarios.
Isn't it time we took a moment around this infection point: moving from monolith to microservices architecture. One issue with microservice architecture is that it tries to sell us the product model which can jeopardize organizations. How do we predict changes to the product model and convenience the mobilized and specialized teams to change their hats, give up their highly specialized specialties to work in integrated mode? How do we deal with more than one monolith solution, moreover it is generally the case, and if one of them requires a microservice overhaul? By what means do we jeopardize the stability of the organization and mixing resources?
During GOTO conference keynote, Martin says that microservices are a subset of SOA. By the same token, we recommend opting for SOA in the early stages of the enterprise to drive a plan which sets projects outlines. Obviously, we need to distinguish between enterprise architecture and project architecture.
Nevertheless, having a directive to adopt the broad SOA principles is a paramount at an early stage of the startup. Thinking about the repercussion on projects will be a matter of time, priorities and resources. SOA will thereafter provide a framework and an umbrella to drive projects.
However, being convinced that the golden age of SOA has been eclipsed by the end of the last decade is somewhat misleading and due to bad and incorrect conjunction with labialized SOA products such as ESB, or technology like SOAP or BPEL.
Recall that there is no SOA project, but rather a company adopting SOA as an incubator which sponsors projects in the shape of services and even proposes a solution to deal with legacy products without introducing a risk in the ecosystem.
Many argue that microservice is not a revolution, but instead a reaction to DevOps movements such as Agility and Cloud. However, SOA provides a framework that behaves strictly with a set of laws and principles. We should be clear that agility is at the heart of SOA, yet the alignment between business and technology is one of its first commandments and among its strategic goals.
Figure 1 - Goals and Benefits of Service-Oriented Computing
SOA fights against classic project management and claims an agile management with adhesion between business and technology.
Figure 2 - Source: "SOA: Principles of Service Design" by Thomas Erl, Prentice Hall
Microservice resumes this model and adds the deployment phase with an integrated team throughout the lifecycle.
It's worth pointing out that SOA introduces an agile axis for enterprise architecture whereas microservice is only a screening on the application and operational part.
Martin admits that microservice brings an additional burden and recommends avoiding it by the simplification of the existing monolith solutions. Microservices become, to some extent, the way to increase productivity when silo-based solutions reach their limit:
Figure 3 - Source: www.martinfowler.com/bliki/MicroservicePremium.html
Meanwhile, having thousands of microservices connected in point-to-point mode or through a dumb middleware can make coordination for any changes or updates difficult or even impossible. Devolving governance to the services themselves as a self-service model will bring a further handicap against agility: each service should manage its own channels and messages and any uncontrolled changes will affect both consumer and supplier services. The governance model that SOA leads try to solve problems in advance and according to both: organizational with the introduction of new roles and a solid technical base such as versioning, as well as standardization. SI roles introduced by SOA are summarized in the following diagram:
Figure 4 - Source: www.soaschool.com/pdf/mindmaps/Module15_2.pdf
As an analogy, when teenagers become mature, you have laws and bodies to establish and ensure respect of them. Otherwise, it would be anarchy and disorder: this instance is SOA. Many believe that laws are a burden, but they should try wild and forest life to decide.
SOA is a cornerstone for a long term microservice architecture and plays the governor's role in the enterprise. From this perspective, SOA tries to not get into the privacy of microservices.
Setting an enterprise architecture from the young age of a company may be a luxury, but in case you start having trouble with scattered microservice architecture, establishing SOA governance can act as a remedy.
Microservice is an SOA interpretation using a set of specific principles and patterns that claim to be in harmony with agility and introduce a new name to break the misunderstandings and incomprehension of SOA. If SOA is a victim of its success and that microservice will blow its new life, we confirm that it's totally the opposite, and you must go back to SOA principles to govern your microservices. SOA will give the company the missing enterprise scaling dimension which is explicitly absent in microservice architecture.