Microservices
#Microservices is basically breaking down your one application and "DECENTRALIZING" them into multiple applications.
For example in a company like Amazon which enables selling of products, it may have Orders application (one microservice), Products application (second microservice) and Shipping application (third microservice).
Each one is "INDEPENDENT" of the other and probably operates with its own architecture (which can be monolithic), own application memory process, own database, own development team, own boss. Microservices seemingly enables a Scrum of several Scrum teams, each with its own product manager (or more specifically "service" manager). The idea is one service does not stop the other, each is "UNSTOPPABLE", can "DEPLOY AND RUN FAST" and can "PRODUCE MINIATURE CLONES" on demand.
Martin Fowler encourages to go for microservices (distributed model) only if you are pushed to, else you should be fine with your monolithic architecture (which is our simple client server model) because microservices increases many lines of communication which adds to the complexity.
The monolithic architecture is like talking to one boss but a microservice architecture is like talking to many bosses. At times, we have the need for two or more bosses to work together. This can be messy if not thought out and implemented well.
Martin Fowler emphasizes that if you go for microservice architecture, make sure you have atleast taken care of four things i.e.
- Availability (service has to be available else business can stop)
- Monitoring (some thing and maybe someone has to monitor that these individual services are orchestraing well to represent a full end business service to the customer)
- Rapid Deployment (it should be quick to deploy a single service without having to worry about the other services)
- DevOps culture (Continuous development, testing, integration means product builds and up and running faster through demanding scrums, at desired velocity)
In Microsoft world, if one orchestrates the use of Azure cloud, Azure functions, Azure service fabric, Docker containers and Visual Studio Team services, then I see a possible microservice architecture model. Additionally I would emphasize that one should clearly see a positive difference in cost, simplicity, reusability, speed and future needs before burning the client's pockets with any architecture.
Here is a nice video from Martin Fowler to help you understand the Microservices architecture better.
https://www.youtube.com/watch?v=2yko4TbC8cI
