Generally it is a method of developing software applications as a suite of independently deployable, small , modular services in which each service run a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal. Microservice architecture is an evolutionary design and again, is ideal for evolutionary systems where we can’t fully anticipate the types of devices that may one day be accessing your application. This is because the style’s practitioners see decomposition as a powerful tool that gives them control over application development.The core application was initially based on monolithic architecture, but as several unforeseen requirements surfaced, instead of revamping the entire app the developers used microservices that interact over an older monolithic architecture through APIs.
In a microservices architecture, services should be fine-grained and the protocols should be lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.
Small, easy to understand code base. Because micro-service application is responsible only for one thing, it requires less code, is easy to understand, is easy to reason about and has less risk of changes.Easy to scale. With a large, monolithic application you have to scale everything together.Easy to throw away. Our field changes constantly at a fast pace, and what was cutting edge yesterday maybe quite outdated and slow today, or a vendor product you rely on does not fit the bill anymore or you want to move to open source alternative. Most of the time it’s easier to start from scratch with modern tools and languages than it is to reuse old, outdated technology. Micro-services facilitate this very well.
Easy to Deploy. With monolithic applications even one line code change require redeployment of the whole application. At least on the jvm platform. This could be a big problem for many organizations with its high degree of risk and disruption. Deploying micro-services is much simpler because the scope of deployment is much smaller. Plus you know where to look for problems if such arise.Ability to use a different technology stack. With micro-services the approach should be to use the best tools and languages for the job, instead of one size fit’s all. The same goes for databases. For example, recommendation micro-services can use neo4j and python because python has a lot of machine-learning libraries; event-processing micro-services may use java and cassandra because of multithreading properties of jvm and high scalability of cassandra. It also allow teams to try new technologies on small services without major disruption.
Smaller teams. It’s much easier and faster to work with a collocated, small team. Each small team can own micro-service and access other services via high level api. For example, a team in New York can be responsible for recommendation services and a team in India for content micro-service.
System resilience. If an monoliths application stop working, then a lot of functionality stop working. On the opposite side, If one of the micro-services stop working – only small, particular functionality will be lost. It’s much more simple to build some resilience around smaller service. For example, failure of the order-processing system can be mitigated with message queues.