As I mentioned earlier, there are some common points between MSAs and SOAs, so much so that you can define MSAs as an evolution of SOAs. But what differentiated these two architectural designs and where did SOA fail?
Let's try to summarize their different features and concepts:
|
MSA |
SOA |
|
It's based on team collaboration using Agile and DevOps methodology. It sponsors freedom of choice regarding the implementation technologies, with no shared resources or governance models. |
It's based on shared common governance and is implemented using ESBs and a standard communication protocol. |
|
A fundamental principle is that each microservice must own the data so it must have independent data storage. |
It allows services to share the database. |
|
One of the key points is the automatic scalability that is a native benefit of containers. MSA could be defined as a cloud-native architecture. |
It was born before the arrival of the container—scalability policies don't fit very well in cloud environments. |
|
The execution environment is not based only on application servers—it's possible to use a slim web server, such as Tomcat, Undertow, Jetty, and so on, in a classic way (deploying the application on top of it) or with the Uber JAR feature. It's also possible to use a Javascript engine, such as Node.JS, a reactive system, such as Vert.x, a Scala ecosystem, and so on. It's a polyglot architecture. |
It's based on a common platform, usually a traditional Java EE application server, for all services deployed to it. |
|
It prefers lightweight protocols such as HTTP, REST, and so on to make the environments as performant as possible. |
It supports multiple message protocols but the major one that's used is the SOAP. |
|
Communication between services is based on less elaborate and simple messaging systems—HTTP verbs using JSON objects or an asynchronous messaging pattern (Java Message Service (JMS), Advanced Message Queuing Protocol (AMQP), Message Queuing Telemetry Transport (MQTT), Server-Sent Event (SSE), Push Events, and so on). |
Communication between services is based on XML messages using SOAP protocol, often orchestrated by a single ESB. |
|
It has a strict concept of bounded context. |
It's focused on business functionality reuse so full isolation is not guaranteed. |
|
DevOps, CI, CD, and Agile methodologies are mainstream in MSA architecture. |
CI is used and sponsored in an SOA environment. The other ones listed in the MSA column have been introduced in recent years but don't represent the base philosophy of the design. |
|
One of the main concepts is the immutability of the software and of the infrastructure. A code change should cause a new application release while an infrastructure modification should cause a release of new container images. MSA is often related to a cloud environment. |
A code change requires the update of the monolith while an infrastructure update should be obtained with a modification of the properties' configuration settings. |
|
It's focused on decoupling, even at the cost of violating the don't repeat yourself (DRY) pattern. |
It maximizes application service reusability in terms of code and business implementation. |
Finally, we can't say that one architecture is absolutely great while the other one is totally wrong. There are some positive aspects in SOAs. Maybe, the points which led to its decline are:
- Strong coupling between services due to protocol communication and code sharing that increases the time to release a new version and make it difficult
- Vendor lock-in due to the presence of ESB proprietary implementation
- Limit of the scalability due to the technologies used
We can think about MSA as SOA on steroids—it reuses the benefits and overcomes the limitations with a new way of thinking and designs focal points using the great new features of cloud environments.
The most common approach to evaluate MSA is to refactor a classic Java EE monolith application. In this way, people can examine whether the key features are present in the new design and how they can implement them. After that, they will start to think about building a microservice cloud-native application from scratch.