≡ Menu

Introduction to Microservices Architecture vs SOA vs Monolithic

Microservice is an architectural pattern, or we could say a system design pattern. It is based on Service Oriented Architecture.

Service Oriented architecture (SOA)

Service based architecture is a way of designing your system or applications in such a way that whole system is divided into small individual components where each provide different services to each other component over standard communication protocol shared by all the components, and together they are a complete system providing a useful service to other system/end user.

Microservices are little different from SOA applications, mainly in areas of resource sharing and size of applications. SOA focusses more on share as much as possible. In contrast Microservice pattern focusses more on sharing as little as possible. Microservices emphasis is on individuality of each and every component of system to avoid single point of failure. SOA uses a single event bus kind of structure for message passing, where MSA uses simple peer to peer messaging REST protocol to communicate to other components.

SOA Architecture Vs Microservice Architecture

SOA MSA
Focus on share as much as possible Share as little as possible
Common bus kind of communication channel Simple messaging protocol
Could use many protocols Mainly uses REST. HTTP2.0
Shared databases Each MS has own database
Focuses more on service reusability Loose coupling of components
Common governance less focus on teams’ collaboration More focus on individual team collaboration
Use of containers less popular Use of containers is popular

In microservice architecture the system is divided to finest granularity, each component should only have single responsibility, apart from this work this should not do other work and should communicate to other component for execution of any other required work.

Need for Microservice Architecture

Initially software systems were built as single, monolithic, a single unit of a software. This architecture was very rigid. All the system was divided in many modules, i.e. for TGS website it could have been, authentication module, user data module, articles data module, database access module, security module, subscription module. Etc.

It was a single application, if there was any change in any module, admin must have to recompile the application, redeploy the whole application. Do all the testing of all the modules. So this was a monolithic architecture of interdependent modules. We cannot think about modifying any service, module without thinking of its effect on other.

[TGS Monolith Application]

Fig 1: TGS Monolith Application

Above diagram depicts TGS monolithic design, this is single entity, single software. Where teams work on different modules, complete the coding part then wait for other components to get ready. Only after each and every module is implemented they can start next step software development life cycle.

Microservices in fact are very loosely coupled system of all the components, all components can grow together. In TGS perspective there would be one microservice (REST application) for each and every module i.e. authentication service, user data service, article data service, subscription service.

All would be communicating to one another on REST protocol. If we need to change any module, we can change it test this microservice and deploy in the microservice component easily, the delivery time of this change will be far much lesser that monolithic application development.
They can be built, deployed and scaled individually.

Monolithic Vs Microservices

Feature Monolithic Microservice
Agility Feature enhancement, redeployment is slow Speedy Development and feature enhancement, redeployment is fast
Downtime More downtime as we need to redeploy whole application Lesser redeployment time , as we need to redeploy only one component
Resiliency Single point of failure possible No single point of failure as system is comprise of multiple components
Productivity Less productivity when compared to MSA Increased productivity due to multiple team collaboration

Microservice Sample Design Architecture

This is basic Microservice design of TGS application. Here different teams take up the task of implementing the individual microservices. Once they are done with the development they can deploy their microservice , start their testing process with other microservice simulators . They don’t have to wait for other micro services to deploy their microservice. Each microservice development is independent of each other.

[TGS Microservice Application]

Fig 2: TGS Microservice Application

In above example diagram, the following would be typical flow of messages:

  • End user sends request to TGS MS
  • TGS MS Receives the request from end user
  • TGS MS Sends a request to Auth MS, to authenticate the client
  • Auth MS authenticates the Client by contacting to User Data MS, sends back the response
  • TGS MS sends a request to Subscription MS to check subscription of user
  • Subscription receives sends in response the subscription data.
  • TGS MSA sends a request to Articles MSA to query authorized articles for this user
  • Articles MSA sends back authorized articles back to TGS MSA
  • TGS MS shows all the allowed articles to end User.
  • Analytics MS keep tracking all the activity and important data of user and whenever TGS MS asks for useful metrics it sends back appropriate analytics data.

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

{ 0 comments… add one }

Leave a Comment