Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams. This approach corresponds to the Y-axis of the Scale Cube. There are three common patterns that are used widely to create microservices: API driven, event driven and data streaming.
Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features. In agile world these services are owned by small autonomous teams.
Below are some of the reasons why we need microservices:
- Supports Object Oriented programming principles. Helps to create modules that are highly cohesive and loosely coupled. Microservices also reinforce the idea of Single responsibility principle.
- Microservices helps to bring those things together that changes for the same reason, and separate those things that changes for different reason.
- Promotes the idea of creating service boundary over business boundaries. This helps to create focused services which doesn’t grow too large.
- System consists of multiple small services collaborating services. Due to this Heterogeneity each service can be built using different technology best suited for the purpose. For example social networking, service might use graph oriented database but for storing blogs they can use document storage. With monolithic application if we need to adopt new technology it will have major impact on the application. Heterogeneity eliminates the long term commitment to technology stack and ensures that service can be individually upgraded to latest technology with impacting other services.
- If monolithic service if the service fails it brings down everything. With Microservice pattern we can build systems that handle the total failure of services and degrade functionality accordingly. A key concept in resilience engineering is the bulkhead. If one component of a system fails, but that failure doesn’t cascade, we can isolate the problem and the rest of the system can carry on working. Service boundaries become our obvious bulkheads .
- With large monolith we have to scale everything together. With smaller service we scale service that needs scaling.
- Ease of build and deployment using well established CICD tools.
- Microservices can be serverless in order to reduce complexity. This brings in no infrastructure cost, auto scaling by unit of consumption, Pay for value billing model and high availability and fault tolerance.
Drawback of Microservices
- Developer must deal with the additional complexity of creating a distributed system. Inter-service communication mechanism must be implemented.
- Resiliency becomes important as individual service can fail and create ripple effect on dependent services.
- Implementing requests that span multiple services requires careful communication between teams.
- Deployment complexity. There is also operational complexity of deploying and managing a system comprised of many different services.
- Increased memory consumption. The microservice architecture replaces N monolithic application instances with NxM services instances. If each service runs on individual JVM, which is usually necessary to isolate the instances, then there is the overhead of M times as many JVM runtimes.