1) What was problem?
Longer release cycle time, ever increasing code base, tightly coupled
functionalities of application making difficult to implement change, complex
organisation structure.
2) How we have approach towards problem: -
A) People transformation: - New organisational design where people are
responsible for making and running small set of Microservices. The services are
defined based on bounded context by levering Domain Driven Design.

B) Process transformation: -In order to identify the organisational process bottle
neck, End to end value stream mapping done and Improvements themes such as
change management, release management etc has been implemented.
C)Technological transformation: - New technologies, tools and practices adopted
that has helped in achieving engineering excellence by Automation,
Autonomation ,CICD, Infra as a code, cloud only infra , Microservices and API
led economy etc.

3) Our Approach towards Microservices :-
1. API led connectivity: - Composiblity of different system is the key for
Microservices experience and we can achieve the composiblity of
different system by leveraging API led connectivity approach. In this
approach, we will have system API, process API, and experience API.
System API takes cares of system of record underpinning the service,
process API takes care of business process underpinning the service and
Experience API is responsible for experience of consumer of services.
2. Elements of API design:- In our API design we have used domain
model , architectural standards , API catalogue ( experience , process ,
system) to identify development details, stub details , deployment
details, RAML specification ,data mapping ,back end system
specification and integration specification.

4) Client –Server Monolith application to Microservices application: -
1. Strangler pattern of Microservices: - In client –server monolith
application to Microservices application journey, we have used the
strangler pattern of Microservices. As we can see from architectural
diagram that we have put the dispatcher (API gateway, reverser proxy)
in front of monolith and directed our clients to it. The dispatcher also
acts as an API gateway and provides utility such as Authentication and
authorisation, logging and Auditing. The dispatcher is just a proxy to
endpoints exposed by monolith. We have refectored each domain into
Microservices and deployed them into Microservices platform.
2. Swagger: - We have used swagger to define, generate and Document
API’s.
3. Caching as a service: - We have implemented cashing as service and we
have cached the static data of system API, experience API, and process
API. Cashing helps in improving the user experience.
4. Configuration of the API security context: - Our API Gateway exposes
API to consumers and protects services using the policy enforcement:
security policies.
5. Engineering excellence in Microservices landscape - We have achieved
engineering excellence by practicing CICD, Infra as code, automation
etc in Microservices landscape.
6. Other API design consideration: - a) Asynchronous event based
communication using the network for loose coupling between services.
b) Circuit breakers for isolating the failure of services c) Consumer
driven contract as way of service consumption.

5) When not to go for Microservices.