Microservice : comparison with SOA and 12 Factor Cloud Principles

Microservice : comparison with SOA and 12 Factor Cloud Principles


Hello friends, hope you are doing really good and following the Microservices : Beginner to Expert series. We have already discussed about What is Microservice and its various characteristics and Principles in our previous blog.

In this blog . lets discuss about how Microservice style is compared with SOA architectural style and Cloud based development 12 Factor principles.

Relation with 12 factor Cloud development Principles

1. Single codebase – Each application has a separate codebase. This is a fundamental principle of development on Cloud platform. This principle drives a modular nature within overall business architecture where each functional module can have its own codebase. This also supports basic concepts of Microservice architectural style i.e. service should be modular, independent and atomic.

2. Bundling dependencies – All applications should bundle dependencies and execution libraries. All applications are totally independent and even has it’s own execution container / HTTP listener. This enables microservices to be independently maintained and scaled.

3. Externalize configurations – An application’s configuration parameters vary with environment . The principle advices to externalize configuration parameter from code. This enables configuration values to be changed without code deployment and with no application downtime.

4. Backend services are addressable – All backing services should be addressable by an URL. Microservice implementation style of a specific requirement feature follows well defined interface a.k.a. API definition over REST communication pattern. Hence , it is complementary with this Cloud principle too.

5. Build, release & run – Strictly separate build and run stages. This is fundamental requirement to create independent and modular Microservices.

6. Stateless – Applications should be stateless and share nothing. Similarly, Miroservices should not maintain conversational state between multiple service calls.

7. Exposing services through port bindings – HTTP listeners should be emended in the services. Port bindings are one of fundamental requirements for applications to be autonomous. A microservice should not try to access another microservice’s data directly but rather should contact the exposed API to get the data

8. Concurrency to scale out – The principle suggests that processes should be designed to scale out by replication. Microservices should scale out horizontally to address additional load and scale in when load reduces.

9. DisposabilityApplication startup and shutdown time should be minimal.

10. Development and production parityThis principle states that development and production environments should be as identical as possible.

11. Externalizing logs –This principle states that logs should be shipped to central repository by tapping logback appenders and write to one of shipper’s endpoints. Since there will large number of microservices to implement all features , application slogs should be externalized and centralized to a common location.

12. Package admin processesThis principle advises that admin tasks should be packaged along with application code.

This proves that by following 12 factor cloud app principles facilitate Microservices architectural style of development. Note, Micorservice architectural style can be applied for both Cloud & on-prem infrastructure but without cloud all benefits of microservices may not be realized.

Next part is to understand how Microservice Architectural style has evolved  from earlier SOA style and how it is different than SOA. Lets compare both of them.

Comparison with SOA

SOA is the foundation of Microservice style of development and there are lot of useful best practices and principles that are still valid. However, as SOA was primarily used to develop Monolithic application, though it has evolved from there, it has few fundamental differences from pure Microservice architectural style too. Service oriented integration– Many organizations use SOA to resolve integration complexities. In this case applications communicate with each other through a common integration layer using standard protocols like SOAP over HTTP based webservices or JMS. Organizations in this case heavily depend on ESB technologies. In this case all services are accessed by ESB. Microservices are a different ball game in communication pattern perspective. It becomes standard practice to follow communication pattern over REST protocol with JSON format data in case of Microservice style of development.

Legacy Modernization – SOA is also used to build service layers on top of legacy applications. In this case services are built and deployed in ESB layer connecting to backend systems using ESB adapters. For these organizations microservices are different from SOA. Microservices focuses on moving away from costly esb products . In microservice business events are handled by software like Rabbit MQ , Kafka where the queues are like dump pipes.

Service oriented application – Lightweight integration frameworks like Apache Camel, Spring integration are used to handle cross cutting capabilities like service integration , protocol conversion . All services are packaged as a monolith application. Such organizations can see microservice as next logical step.

Monolith migration using SOA  Some organization use SOA to breakup a monolith into smaller units . Each unit is self contained application deployed in separate web servers. These units communicate with lightweight protocols to exchange data among themselves. For these organizations microservice is same old wine in new bottle.

So, that’s it friends, be in touch and follow this series learn more about Micorservice. In my next blog, In our next blog we will discuss about key advantages of microservice based architecture.

Do not forget to let us know in below comment section about your feedback or if you want more clarification. CTT team will address all your technical questions as soon as possible.

Keep visiting and Happy reading!!



Author: Debajyoti Mukherjee

Debajyoti Mukherjee has more than 11 years if IT experience in application design , application development. He has worked in large MNCs and has worked for eminent clients. He is proficient in custom development , cloud platform , microservice based application migration.

One Reply to “Microservice : comparison with SOA and 12 Factor Cloud Principles”

  1. Hi, In my opinion, the comparison with SOA is a bit simple and product/technology oriented. Could it be compared base on the SOA manifesto and principle by Thomas Erl?
    1. Standardized Service Contract
    Services adhere to a service-description.

    2. Loose Coupling
    Services minimize dependencies on each other.

    3. Service Abstraction
    Services hide the logic they encapsulate from the outside world.

    4. Service Reusability
    Logic is divided into services with the intent of maximizing reuse.

    5. Service Autonomy
    Services should have control over the logic they encapsulate.

    6. Service Statelessness
    Ideally, services should be stateless.

    7. Service Discoverability
    Services can be discovered (usually in a service registry).

    8. Service Composability
    Services break big problems into little problems.

    9. Service Interoperability
    Services should use standards that allow diverse subscribers to use the service. This is considered so obvious these days that it is often dropped as a principle.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.