In this blog, I have explained the difference between applications which are implementing SOA(Service Oriented Architecture) and software applications which are implementing the Micro-services Architecture and the scenarios when one is better than other.

---

To summarize, the blog Use-Cases are:

1. Monolithic vs. SOA vs. Microservices
2. My Notes on Monolithic vs. SOA vs. Microservices
3. In SOA, there are Feature Level Services, whereas in Microservices these are Task Level Services.
4. Key Differences between Microservices vs SOA
5. SOA Service Types: {Business Services, Enterprise Services, Application Services and Infrastructure Services}
6. MSA Service Types: {Functional Service, Infrastructure Service}
7. Difference with respect to Heterogeneous Interoperability
8. Difference with respect to Service Granularity
9. Difference with respect to Component Sharing
10. Difference with respect to Middleware VS API Layer
11. Share-as-much-as-possible vs share-as-little-as-possible
12. Example 01: Building a Shopping Cart - How SOA is different from Microservices and when MSA is better then SOA
13. MSA is all about breaking a particular feature/ feture-level-services into Task-level-services.
14. Man, you are killing time. All these things are time consuming. When ?
15. Example 02: When SOA architecture comes better
16. Conclude the Debate: Which One is Better? SOA vs MSA

---

1. Monolithic vs. SOA vs. Microservices

Before we deep dive into the differences between the Microservices vs SOA, let me just tell you the basic differences between the Monolithic architecture, SOA, and Microservices.

Hey, you can read my note first, before going through the subsequent sections. This will help you to clarify the thought while rest might confuse. Follow the arrow and get the note.

---

My Note:

Monolithic Application

You can think of a monolithic application as a contianer which is basically hosting a number of software components. There can be a number of software components as part of your software application and if they are all hosted together and delivered together, then that's called a monolithic application.

Now there are various challenges with any software application which is implementing the monolithic architecture. Lets see the challenges:

1. First of all, they are not flexible. Monolithic applications cant be built using different technologies. That's the problem.
2. Second challenge is that, they are unreliable. Even if one feature of the system doesn't work, then the entire system will not work.
3. Third Challenge, these monolithic applications are not Scalable. They cant be easily scaled and even if the application needs to be updated, then the complete system has to be rebuilt.
4. The next problem is that, with these monolithic applications, they block continuous development. All the features can't be built and deployed at the same time. They will have to be done separately.
5. With monolithic applications, development is very slow. They take a lot of time to be built since each and every time, every feature has to be built one after another.
6. Most of all, monolithic applications are not fit for complex architecture. Because you cant use different technologies. You are very limited and very constrained.

SOA - Service Oriented Architecture

With SOA, these services or features, they are broken down. Entire software application is not built as one but different features and different services are broken down into smaller components. Thats why it's called Coarse Gained Architecture.

Let's say one software application which provides four features, then all those four features are delivered by four different services. That is want you can see in above illustration.

• Each of these services would have multiple tasks inside them.
• And these smaller task would rather delivered as one particular feature.
• and the whole software application comprises of a number of these features.

MicroServices

But comparing to SOA, with microservices it is little more different. In Microservices, these features or services are further broken down into task-level-services

In SOA, there are Feature Level Services, whereas in Microservices these are Task Level Services.

Each and every task in a particular feature was broken down and that's why you have multiple tasks and multiple services in a microservice architecture. That's why it is called Fine Grained Architecture

A Service-Oriented Architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

These are the differences are between these three at high level. Are you Confused!!!! Let me generalize the SOA vs. Microservice

SOA is like an orchestra where each artist is performing with his/her instrument while the music director guides them all.	With Microservices each dancer is independent and know what they need to do. If they miss some steps, they know how to get back on the sequence.

---

1.1 Monolithic

In layman terms, Monolithic is similar to a big container wherein all the software components of an application are assembled together and tightly packaged.

1.2 SOA - Service Oriented Architecture

A Service-Oriented Architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

1.3 Microservices Architecture (MSA)

Microservices, aka Microservice Architecture, is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

1.4 Key Differences between Microservices vs SOA

When comparing Microservices vs SOA, they both rely on services as the main component but they vary greatly in terms of service characteristics.

1.4.1 Difference with respect to Architecture & Coordination

A. Service Oriented Architecture - Service Types

It defines 4 basic service types as depicted below:

SOA Services	What They DO?
Business Services	- They are coarse-grained services that define core business operations. - Represented through XML, Business Process Execution Language (BPEL) and others.
Enterprise Services	- Implements the functionality defined by business services. - They mainly rely on application services and infrastructure services to fulfill business requests.
Application Services	- Fine-grained services that are confined to a specific application context. - A dedicated user interface can directly invoke the services.
Infrastructure Services	- Implements non-functional tasks such as authentication, auditing, security, and logging. - They can be invoked from either application services or enterprise services.

B. MSA - Service Types

Microservices have limited service taxonomy. They consist of 2 service types as depicted below.

MSA Services	What They DO?
Functional Services = Sum{Business Service, Enterprise Service, Application Service}	- They Support specific business operations. - Accessing of services is done externally and these services are not shared with other services.
Infrastructure Services	- As in SOA, infrastructure services implement tasks such as auditing, security, and logging. - In this, the services are not unveiled to the outside world.

1.4.2 Difference with respect to Heterogeneous Interoperability

Any software application need not to be developed on the same programming language. In your core software application, you might have smaller applications and each of those smaller applications could be written on Java or Python or .NET or C# etc.

But when it's written in different programming languages it tough for them to interact with one another. If you want these communications happen, then you have to bring a particular platform.

Thats why we have this messaging Middleware.

In case of SOA, there are something called a messaging middleware which acts as a communication point or the interaction point between different applications which are in a different language.

In the above example, One application is on C#/.NET and other is on classing JAVA. All of these communications, they go through one particular messaging middleware.

But in case of Microservices, we dont have any broker/messaging middleware here.

Here, communication happens directly between application to application even if they are in different programming languages [structurally different and built on different grounds].

Question. In the above example, A C#/.NET application is communicating with a JAVA application. How that is happened?

• It happens with the help of a REST API (REpresentational State Transfer).
  
• Even if the applications of similar type (same language) wants to communicate, they do it through REST API.
  
• See, No broker/messaging middleware here.

1.4.3 Difference with respect to Service Granularity

In MSA, you don't have the software delivered as a whole. It is broken down into smaller features.

• If you are basically performing an operation which involves multiple applications or multiple services, then

• those services are called by one another when its needed.

  • So as an end user or consumer, you might be performing one operation. That one operation will not be calling all the different services. It will call one service and this service when it needs to interact with second service, would make the call to service 2 and similarly service 2 calls service3.
    
  • Once the service requests are made, service response is also given to the one that invoking that request.

• Nows, lets simulate the above example. Assume, each API Calls take 100ms (request and response individually). So, here for this service to get successfully return, it takes 600ms. Thats an awful lots of time for an API call to complete successfully.

This is where it is different from SOA. In MSA--> [Request and Responses Made Sequentially]

In the case of SOA, the service consumer would aging be calling one particular operation. What happens here is:

• this operation would be calling the different services all at the same time.
• So, operation here in the above example would call Service1, Service2 and Service3 which should be encompassed all together.
• Its like, Call One ---> ALL Available

This would save time in comparison to MSA. [Request and Responses Made Simultaneously]

Here we could save around 400ms time for the above example.

1.4.4 Difference with respect to Component Sharing

In SOA- this is very similar to previous section. [The Same Order Service]

• Here it would be the same order service which is interacting with different smaller applications i.e Customer Management, Warehouse Management and Order Fulfillment.
• Data would be stored in different databases.

But in MSA, for each and every application, [Separate Order Service]

• i.e. for Customer management we have a separate order service, that order service will be accessing its own database for data.
• Similarly for Warehouse management we have a separate order service with different database and similar for Order Fulfillment Application.

So, we can summarize it as

In SOA - Share as much as Possible.
In MSA - Share as little as possible

1.4.5 Difference with respect to Middleware VS API Layer

• SOA uses middleware for communication. When MSA uses API Layer (i.e. REST API) for communication.

2. Example 01: Building a Shopping Cart - How SOA is different from Microservices and when MSA is better then SOA

Now lets go ahead and look at the differences between the two by understanding with an example of a shopping cart.

Application 01/Feature 01: User Account
User will create their own user account, there will be a form out there for registration and later they can login. Meantime this application may ask the user to verify his email. Once login, he can browse the product pages and add product to shopping cart and finally checkout.

Application 02/Feature 02: Shopping Cart
Every eCommerce portal will have a shopping cart, where you can add your products to the cart and then checkout later.

• For adding an item, for removing an item, for checking what is the tax, for checking what is the total bill amount; for all those we have a shopping cart application.

Application 03/Feature 03: Product Catalog
It gives details about product name, product ID, product rate, product quantities are present and all different other options i.e. color of the product, product image etc.

All these application together form one particular application in SOA in eCommerce applicaiton.

Now, lets see, How the Feature level services of SOA are fine grained into Task level services in MSA.

But in MSA, each of the different tasks that these services /applications provides, those are fine-grained into task level services. Check the table below we how we fine-grained the feature level services: {user account, shopping cart and product catalog} into different task level services.

Task level services	Application/Feature
Display Product	Shopping Cart
Update Display
User Defaults
Display Image
Check Inventory
Send Email
Product Review
Location Available
User Info
Promotions
Recommend
Add Remove
Billing
Shipping Options
Tax Collection

Task level services	Application/Feature
Display Product	Product Catalog
Update Display
Display Image
Product Rating
Check Inventory
Location Available
Promotions

Task level services	Application/Feature
Update Display	User Account
User Defaults
Product Rating
Send email
Product review
Location Available
User Info
Billing Service
Shipping Options
Tax Calculation

MSA is all about breaking a particular feature/ feture-level-services into Task-level-services.

Now, lets see how the micro services shopping application is different then SOA.

• First, lets take the case of where micro-service shopping application is better.

Scenario 01: Dilemma those SOA is creating

• Suppose, we have certain features which are common to multiple applications.
  • i.e. Display Image service (A smaller task level service). But the Image of the product displayed might be common across all the three applications. It might be present in
    • Shopping Cart Application[products user has added in shopping cart],
    • User Account Application [which product user has bought] and
    • Product Catalog Application[products in the product catalog page]
• So, in this case, if there is a change in image dimensions or anything with respect to the product image, then the code will be similar across in all the three applications, but has to be changed everywhere as its in SOA architecture for now.
  • But when you change the code/rework, it cause lots of problem again. Changing the code here, you are changing the functionality. That might cause the particular application to behave abnormally. It might have bugs or can cause failure.
  • If you want to avoid these, you have to test each of this application after changing separately
  • and after testing, you have to deploy them separately.

Man, you are killing time. All these things are time consuming.

Scenario 02: Dilemma solved by MSA which SOA introduced

In the case of MSA shopping application, we will not have this problem. All the different tasks over here, they are different service.

• and if you want to change the dimension of the image, you change it only in the 'Update Display Service', not individually for every 'Applications'.
• This will save time and efforts.

2.1 Example 02: When SOA architecture comes better

Suppose, you product is not actually that big. So, in this case this is a very simple application, needs the primary functionalities of "User Account Application", "Shopping Cart Application" and "Product Catalog Application".

• These applications doesnt have too many sub-level features.
• They are very straightforward and simple.

In this case, MSA could raise complexity and gives troubles.

3. Conclude the Debate: Which One is Better? SOA vs MSA

Neither of them is better than the other.

There are scenarios, when MSA is preferred and scenarios when SOA is preferred. And you cant hard-coded by saying that one is better than the other.

So, on that note, I would like to conclude this blog. Read my next blog of this Series here.