Approach of solution designing and architecting has undergone an evolution with the concept of micro services. Monolithic architecture is still of use for certain types of applications but the need of reusable applications, independent functional components, ease of migration to new tech stacks, automatic scalability and agility is fulfilled by micro services. It started from SOA where components provide services to each other to meet the end requirements of the product rather than assembling all into one monolithic system. It is now fine grained into a micro services world.
In the rush these days to move to micro services, often the mistake to not follow the key design principles of micro services is made leading to a clutter of components in the system which are tightly coupled to each other making the product complex to debug, upgrade and be auto-scalable. So before anyone decides to adopt to micro services architecture, reason of migration to the new architecture should be very clear. Further, investment to discuss, debate and conclude on the design strategy that should be followed to get the most benefit from micro services should be done.
Comviva has adopted to micro services architecture for its products. It has been an enriching journey to reach where we are. Today, our micro services are designed and developed such that they are fully independent & reusable. The way product offerings and deployments are being planned is completely undergone a change. Just picking the right set of micro services to meet the business requirement is what is to be done for a deployment.
Micro services by its name and principles have to be:
- Independent (self-contained)
- Should meet a functional end requirement, scope should be a business capability
- Simple & Lightweight
- Auto-scalable
Calling a micro service “Independent” looks to be one simple term but brings in huge expectations from one simple application. A micro service can be independent in execution and deployment if it is a full stack application having one responsibility and hence meeting a business requirement.
Beyond this, the service does self-monitoring, regulates load and is scalable independent to any other micro service running in the system. Circuit breakers in the application open up when the application reaches an unstable state, system has the capability to apply pressure on the producer when consumers are not able to pick and process data, thresh holds are defined so as to eventually make self-healing and auto-scalability possible.
Independent micro services communicate using an async backbone. Comviva uses RabbitMQ as the message broker which is based on AMQP. Each micro service is mapped to a separate routing key in a single topic exchange.
When there is a cluster of services which together make ONE product, there is a need to tie them up together with some principles so as to ensure clear definition of dependencies, clean and segregated configurations, an integrated CI/CD pipeline, logs as a stream and DevOps. Compliance to 12-factors for micro services enables this.
