Microservice vs SOA differs

Question

I was looking for differences b/w SOA and Microservices architecture style and found a good link https://www.infoq.com/articles/boot-microservices

It Says:
As a successor to "Service Oriented Architecture" (SOA), microservices can be categorized in the same family of "distributed systems", and carry forward many of the same concepts and practices of SOA. Where they differ, however, is in terms of the scope of responsibility given to an individual service. In SOA, a service may be responsible for handling a wide range of functionality and data domains, while a general guideline for a microservice is that it is responsible for managing a single data domain and the corresponding functions around that domain.

Please help me to understand :
The meaning of single data domain (recommended for microservice). is it saying that a separate Microservice has to be build to manage a single domain/entity (and associated/composite domain/entities with this single domain/entity). Becasue if this case, then there will be many(~20 to ~50) microservices even to implement a basic functionality (enterprise) application

Edit: I have gone through the link Difference between Microservices Architecture and SOA, but it explains, that it is same on the first two tenets, and different on 3rd point (in SOA, Services share schema and contract, not class), but that is SOAP contracts, but then what is the difference b/w SOA (with REST) vs Microservices (which is mostly with REST)

Answer 1

Adding to what Sean had said, microservices are what people started to call APIs when SOA had started to being put to use in many companies. The rise of Domain-driven design has also led to the increase in usage of the term. In the industry right now, there is absolutely no difference between the two, people call it as they seem fit.

You are right when you said that you will end up with many micro-services when you follow the philosophy in principle. In my opinion, be it SOA or microservices, abstraction to independent services should depend only on the use-case, how the services are going to be deployed and how many teams are going to work on those in parallel. There is also an increasing cost to network bandwidth if the services are deployed across hosts (though containers and DC/OS frameworks are solving this problem now). If it is fast-changing service, having lots of moving parts, then breaking down a big service into microservices would make sense. Otherwise I would avoid premature optimisation and have the functionality packaged into a single (or a few big) services.

Answer 2

I think that this is a matter of interpretation:

I'd argue that in SOA a service is not a physical process (windows service/app domain) but a logical boundary... and the same rules apply in SOA and Microservices in regards to the smallest autonomous component. they own (the technical authority and data owners meaning they are the only one component that can change the state of that piece of data) of a collection of one or more domain properties/fields.

Now at runtime, I'd argue that if you don't need to distribute you process, then you can deploy them all in the same process (later when you need to scale, distribute your components to achieve better performance)...

Make sense?

Answer 3

I found a good explanation done by Microsoft :

Microservices derive from SOA, but SOA is different from microservices architecture. Features like big central brokers, central orchestrators at the organization level, and the Enterprise Service Bus (ESB) are typical in SOA. But in most cases, these are anti-patterns in the microservice community. In fact, some people argue that “The microservice architecture is SOA done right.”

Answer 4

Regarding your question about the "domain", to my view, and I believe it is a main characteristic for Microservices: A Microservice should manage its own functional domain and data model.

Let's say you have a products catalog application within your company. You probably would not like to have many other applications hitting the catalog persistence layer and abstracting (again) the catalog model as it would harden the model refactoring / evolution. Probably it would cause concurrency issues between these applications preventing the catalog application to be scaled Instead you would probably prefer to maintain a single catalog application, which would expose web service APIs (such as REST endpoints) consumed by other applications.

I've read this comment in this other related question "Microservices = SOA - ESB". Indeed, ESB are incompatible with this microservices characteristic: "Smart endpoints and dumb points" which means that when a microservice needs another one as a dependency, it should use it directly without any routing logic / components handling the pipe.

Finally, you could take a look to this cheat sheet based on a Martin Fowler introduction to Microservices video.

Answer 5

SOA is different from micro service. SOA is feature base and it needs a message service middle ware for interactions between the components. To save you some lengthy theory, let me use some software i worked with recently as illustration.

There is a finance solution i worked with of recent. The solution was broken down into two sub solution that communicate with each others.

The first one is called Fusion Banking Trade Innovation(FBTI) while the other is called Fusion Banking Corporate Channel(FBCC). These solution were developed by separate team and sold as different solution but work together as a single solution. FBCC cannot be used without FBTI. FBCC is what the customer interact with(client interface) while FBTI is the admin dashboard that the bank interact with.

Communication between the two features is achieved using a message service middleware like IBM Message queue(MQ). FBCC send message to the queue and is being picked by FBTI and that is their channel of communication.

Micro service on the other hand is task based. The interactions between components is made possible through a web service. I will used a solution called Prestashop ecommerce solution as illustration.

When you download prestashop, all the functionalities is divided into separate module e.g if you want to change the banner of the home page, there is a module for it. There is a module for navigation bar alone and is different from module for footer. There are more than 300 modules for the solution. There are also modules like Manage Products, Categories, Shopping Cart etc. see fig below

The modular nature of this solution has provided an avenue for other prestashop partner to develop different modules that could replace those default modules in prestashop i.e you can buy another module from a partner to replace default modules like cart, shipping calculator.

In conclusion, SOA concept is majorly used for interaction between two or more solutions while micro service concept is used for interaction between two or more tasks within a solution.

Answer 6

A SOA service is all about componentization on service level. A Microservice is all about functional composition on service level.

They are two different solutions for different problems.