From OOP to Microservices: Part 2
The alternative for a monolithic architecture is the microservices architecture. As the name suggests, the idea is to build a set of smaller, interconnected services.
The abstraction here is quite similar to modularity - but at the scale of components. Each distinct component (which implements some set of functionalities) is a microservice - a mini-monolith by itself.
Source: Martin Fowler’s blog
The next step is to make these microservices communicate. The communication can be synchronous or asynchronous1. This is done by exposing the APIs2 of services to each other. One popular and scalable way of doing this is the REST architecture.
Quick review of REST (gist of wiki):
Client-Server Model - Clients and Servers3 have clearly delineated functionalities.
Stateless - Server does not store any context. When a client asks a server for help, it sends all the information the server would need to make that decision. State can be held by an external database (another service) for persistency of state (like login sessions).
Service is accessed and manipulated using HTTP Methods (GET, PUT, POST, DELETE) URLs. Ex. A HTTP GET on
http://rest-example.com/resources/can return all the results from the service’s database.
Back to microservices, a popular way of communication is exposing REST endpoints in each microservice. Each of these microservice could be running as a Docker container on the cloud - possibly multiple instances for HA. And, there can be a load balancer in front of these containers.
Another significant change required is the way the databases and the application interact. For loose coupling, each microservice should have its own database. An added advantage here is that each of these databases can be different - one can be a NoSQL db optimized for a specific purpose and another one could be a traditional MySQL database.
Source: Martin Fowler’s blog
Like every other architecture, microservices have their own drawbacks. The primary point of concern is the complexity arising from the distributed nature of microservices. CAP theorem comes into play here. From a developer’s perspective, debugging microservices is no easy task. And, the rollout of changes in a set of interdependent microservices has to be carefully planned. Kubernetes with Docker can bring some organization and automation into the chaos that is deploying microservices.
This barely does justice to the complexities in the microservices architecture - but is a good starting point. The complexities, in general, slowly start cropping up in natural progression as the microservice is built.