Search code examples
architecturemicroservicessoa

Service oriented architecture vs Microservices

?I have gone through many articles ,still couldn't understand SOA vs Microservices. I still think both are same. Can somebody help me with an example or in laymen's term.

Solution

  • I guess that SOA means different things to different people, so it can be hard to state all the differences between Microservices and Service Oriented Architecture that will be right for all of us, so I'll say what I understand from both approaches.

    SOA

    First and foremost: in my understanding, SOA is an software architecture style (Service-oriented Architecture).

    SOA is suited for an enterprise environment, where you need to integrate different applications (e.g.: human resources, billing, logistics...). This integration must occur by using service interfaces - that's why it is Service-oriented.

    Since these service interfaces utilize common communication standards, SOA can promote the decoupling of applications from each other and make the development easier and faster. SOA does not define which protocol to use when integrating systems, but the most commons out there are probably via HTTP requests and messaging. Also, it doesn't define if it has to be synchronous or asynchronous service interfaces, you can use sync, async or even both.

    There are some architectural patterns that help corporations implement SOA ecosystem, but the most common is the ESB - Enterprise Service Bus. There are some big players in the market that has products that implement this pattern, as an example: Oracle's Oracle Service Bus, IBM's IBM Integration Bus (Oracle has a family of products focused on service-oriented architecture that is called Oracle SOA Suite).

    In summary: SOA is an enterprise-scoped concept that enables existing applications to communicate with each other via a loosely coupled interface that can use multiple protocols, messaging, sync and async interfaces, so that one application can expose it's functionality to be reused in other applications.

    Microservices

    Microservices is an architectural style that aims on developing an application as a suite of small, independent services.

    See that? It says that ONE application MUST be developed as a SUITE of small SERVICES.

    What are the benefits of this approach? Well:

    1. Since they're small, they are more maintainable
    2. They are loosely coupled (of course, it depends on how you designed your ecosystem)
    3. They are independently deployable, which means that you can scale one part of your application without scaling the other.

    Of course, there are some drawbacks, so don't trust when someone say that every application should be developed in this architectural style: distributed systems add complexity (!!!)

    Microservices Architectural Style doesn't define how microservices interact with each other. It can, like SOA, be through HTTP requests, messaging, file, etc. Also, it doesn't define how one application (no to be confused with microservice) interact with another - for that, we can look into the enterprise-scope of SOA.

    To clarify what these statements mean in a Microservices architecture:

    • application - a suite of small, independent, loosely coupled services
    • microservice - a service of the suite

    The differences

    While SOA is an enterprise-scoped concept that aims to integrate applications with each other via loosely coupled service interfaces, Microservices is an application-scoped concept that aims to develop ONE application as a suite of small services.

    That's my point of view on both concepts and, of course, there can be disagreements