What is the difference between SOA and Microservices?

Question

My understanding is that both in SOA and in Microservices modules should be independant and reusable. But what really distinguishes the two?

Answer 1

I tend to agree with Chris Richardson's[1] definition.

3 main areas where SOA and micro services diverge:

Inter process communication

    SOA:
     Smart pipes eg. ESB          
     Protocols - SOAP, WS*
 
    Micro service:
     Dumb pipes eg. Message broker
     Protocols eg. REST, gRPC    

Database

SOA:
 Shared databases

Micro Service:
 Databases per service

  

Services tend to be monolith in SOA whereas small in nature as micro services.
[1]: https://microservices.io/index.html

Answer 2

The difference between them (from real-life production project) is that SOA project has ESB (like Mule ESB, Camel or other) which intended to route messages (SOAP, JSON etc) from one service to another, and acts like a mediation layer between services. Services in turn, does not know about each other and just send\receive messages from ESB.

In opposite to SOA, microservice architecture implies that services will communicate with each other directly, using some protocol (usually HTTP). Microservices similar to SOA in that we focus on business functionality and separate it into single, small deployable chunk.

Answer 3

Taken from: https://www.digitalroadmap.management/blog/2019/11/19/what-are-microservices-and-what-is-soa-and-what-are-the-differences-7245k

SOA and microservices have much in common and at first sight, it seems that the latter is just a new hyped buzzword for what SOA has already described. Yet, there are some differences between both.

What are Microservices?

Let´s first look at what a microservice is. Although there is no common definition for what a microservice is, there are a couple of common characteristics that definitions of microservices share. Those are:

1. Microservices are small, individual and independent components of software that, together, make an application.
2. Microservices are business-oriented, which means that the software architecture focuses on business purposes, such as a business capability, a particular product or service.
3. Every microservice provides a small piece of software to a greater purpose. Therefore, microservices regularly communicate with each other when in operation.
4. A major purpose of microservices is that they can be developed and deployed independently from each other. This leads to a decentralization of development teams in practice, which enables them to develop and deploy faster and with less dependencies and constraints.
5. Due to the modular architecture and the increased amount of communication interfaces between the microservices, errors and failures can be analyzed more precisely. In addition, microservice architectures are usually designed in such a way that they still function in the case that single microservices provide errors.
6. A microservices architecture is often used in areas that are continuously developed further. In such environments, the advantages of independent development and deployment, as well as failure tolerance is of highest importance.

What is Service Oriented Architecture (SOA)?

SOA, which stands for Service Oriented Architecture, is a software architecture style where generic services are provided to other components in the same architecture that provide more complex services based on the shared generic services. In the end, it is similar to a company´s shared services center.

Let´s imagine the following situation: A company that is operating in different countries has no shared services center at the moment. Therefore, basic HR and Finance activities, such as payroll and accounting are done individually in every country. By implementing a shared services center, the company can send all requests related to those activities to one single point of contact where the activities are executed. When the task is finalized, the results are sent back to the individual country. The individual countries then use the results, adapt them to country rules or their individual workforce and provide an additional, more sophisticated, or more individual service to their customers. SOA works in a very similar way. It allows to extract basic services from individual applications and bundles them in a shared services module instead. This shared services module then executes the tasks and provides the results back to the individual applications, which use them further.

So let´s investigate what SOA and microservices have in common and what not.

What do Microservices and SOA have in Common?

Both enable an integration into the wider IT – in contrast to monolithic systems that have no integration outside their own boundaries. A monolithic system can be the better option in areas where security is highly important or where there are no synergies with other systems expected, however, with the broad adoption of cloud technology and the required scalability, integrated systems are usually the preferred solution for architects Both try to identify independent pieces of software that can be applied in different contexts and environments. SOA does this with the help of services that deliver information from one to another system and microservices do this with APIs that provide standardized interfaces for communication SOA can have very different scopes, from very small to very big. Unlike the name suggests, this is also true for microservices, which can be just the authentication of a user at a service or the full purchase process behind your e-commerce basket

What are the Differences Between Microservices and SOA?

The objective of SOA is to design systems as a set of loosely coupled services that enable the integration of applications. On the contrary, microservices have the objective to work on different platforms and in different environments that emerged due to the manifold cloud environments and mobile solutions that require to work on different operating systems. SOA is not dynamic and cannot fit for different purposes. They must be adapted or redeveloped every time a critical architecture piece of the involved technology changes. On the contrary, microservices try to be more independent by building on standardized interfaces that are valid across different technologies. However, there are often different standards, which can in the end lead to the same challenge that SOA has. SOA typically shares fundamental components across different services. On the contrary, microservices usually have everything they need within the service, duplicated in every single microservice. Microservices are hence a bit slower, but less dependent on underlying services in order to work.

SOA and microservices are quite similar concepts. Some might also argue that microservices are a particular type of SOA. In the end, SOA and microservices both have their purposes. SOA helps to interconnect large enterprise systems (e.g. an HR or ERP system) so that they can communicate and interchange data. In contrast to that, microservices have the goal to work in different environments and independent from those environments, such as on web-based systems, operating systems, or cloud environments.

Answer 4

Microservices Architecture is not an invention. Enterprises such as Amazon, Netflix, and eBay used the divide and conquer strategy to functionally partition their monolithic applications into smaller units, and resolved many issues. Following the success of these companies, many other companies started adopting this as a common pattern to refactor their applications. Eventually the pattern was termed as Microservices Architecture. Nothing radically new has been introduced in MSA. MSA is the logical evolution of SOA and supports modern business use cases.

Microservices vs SOA: How Are They Different?

Answer 5

Both rely on the services as the main component but a lot of differences there. Few are below

SOA:

• Follows “share-as-much-as-possible” architecture approach
• Supports multiple message protocols
• Multi-threaded with more overheads to handle I/O
• Maximizes application service reusability
• Not focussed fully into DevOps / Continuous Delivery

MicroService:

• Follows “share-as-little-as-possible” architecture approach

• Uses lightweight protocols such as HTTP/REST & AMQP

• Single-threaded usually with use of Event Loop features for non-locking I/O handling

• More focused on decoupling

• Strong focus on DevOps / Continuous Delivery