12
vritti
January 2020
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 and
Lightweight
Auto-Scalable
Technically Speaking
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.