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
|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.
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
|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.
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..
soa vs microservices example,soa vs microservices medium