Micro Services Approach
A variant of "Service Oriented Architecture", and a concept popularized by Martin Fowler. Martin also coined "RESTful Architecture", which dominates the present day Internet. Each service implements a set of related functions. For example, an application might consist of services such as the enrollment service, auditing service, the customer management service etc.
Service communicate using synchronous protocols such as HTTP/REST or directly. Services are developed and deployed independently of one another.
- Each micro service is relatively small
- Easier for a developer to understand
- The IDE is faster making developers more productive (as the services are smaller as opposed to one big java project. You can open the project / service that you are currently working on).
- The web container or application server starts faster, which makes it more productive, and speeds up deployments
- Each service can be deployed independently of other services - easier to deploy new versions of services frequently.
- Easier to scale development. Easier development. Each resource / team is responsible a single service. Each resource /team can develop, deploy and scale their service independently of all of the other teams.
- Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic (macro service) architecture can bring down the entire system.
- Each service can be developed and deployed independently
- Deciding how to partition the system into micro services. One approach is to partition services by verb or use case.
- Inter service communication - This is achieved either by wiring the service dependencies or using synchronous protocols such as HTTP/REST (core client module facilitates this communication).
- Developers must deal with the additional complexity of creating a distributed system.
- Implementing use cases that span multiple services without using distributed transactions is difficult
- Implementing use cases that span multiple services requires careful coordination between the teams
- Deployment complexity In production, there is also the operational complexity of deploying and managing a system comprised of many different service types.
- Increased memory consumption The microservices architecture replaces N monolithic application instances with NxM services instances. If each service runs in its own JVM (or equivalent), which is usually necessary to isolate the instances, then there is the overhead of M times as many JVM runtimes. Moreover, if each service runs on its own VM (e.g. EC2 instance), as is the case at Netflix, the overhead is even higher.
