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)
SOA is a modular means of breaking up monolithic applications into smaller components, while microservices provides a smaller, more fine-grained approach to accomplishing the same objective.
So, if you want to integrate several systems using different protocols in a heterogeneous environment, you need to consider SOA. If all your services could be accessed through the same remote access protocol, then microservices are a better option for you.
Service independence Another one of the SOA principles that still applies in microservices is language independence. Services don't need to use the same programming language, middleware or OS as long as they support the common API.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With