Introduction
The micro-services architecture pattern is getting a lot of attention these days and it’s trending. If it is hard to believe, then just check what Google Trends says.
As its name its a micro applications or services those run independently. Mean we can manage (update) independently.
What is micro-services architecture
A micro-services architecture make more sense when we compare it with a monolithic architecture. In a monolithic architecture all modules of the application are tightly coupled inside a single execution or web server.
An example of monolithic application is a like shopping cart application, in which users module, products module, categories module etc are developed in a single project and deployed on a single server like apache or nginx.
This means when we have to update something in project then we need to test the whole project and deploy it again.
In other architecture mean in micro-services architecture all module are developed separately and deployed on different servers. For example users module on one server, products on another server and payment system on another server. So with this approach when we need to update product module then just update product build/server, no need to touch other modules.
Here some other definition of micro-services
- Very very small application that focusing on a single thing
- Independent application
- Individual team can work on it
- Easy to scalable
Risk in micro-services
We had gone through the possible benefits of micro-services, but there some risk as well
Bad design decision- Testing very hard with micro services
- Data storing and sharing
- Compatibility issue
Principal of Micro services
There are 3 principal of micro services architecture
Never ever try to make micro-service from day one: Mean understand application maturely, clearly, data models, communication protocols etc- Premature splitting is then the root of all evil: Don’t split application if you don’t know how application interact with root application.
- Don’t design “CRUD” micro-services: Micro-services should have HTTP apis that not reflect database but provide behavior, actions, like hay sent this report to this user.
Standard protocols
Here are some protocols that used to communication between services
HTTP: Socket, message pack, binary protocol- RestFull: Resource base endpoint (Put, Patch, Post, Path)
- Swagger, Json-schema: Specification json based serialization
- Token Based Authentication: Authentication for request
Keep in mind while designing HTTP API
Don’t surface too many details- Version your api
- Backward compatibility make your life easier
- Json-schema can help for data checking
No comments:
Post a Comment