Infosys experts share their views on how digital is significantly impacting enterprises and consumers by redefining experiences, simplifying processes and pushing collaborative innovation to new levels

« Integrated Blockchain with API & Microservices | Main | Microservices in the Insurance Industry - Part II »

Microservices in the Insurance Industry - Part I

Recent Digitization Trends, and where MSA fits

In the increasingly competitive Insurance industry, speed-to-market, ability to innovate, efficiency of processes, and agility of systems are supremely important for any Insurer to stay ahead of the competition.

Legacy applications in the insurance industry have typically posed multiple challenges in realizing the goals of the Insurer. A typical legacy application would consist of a monolithic architecture where, a large number of functionalities are packaged under one roof. Though monolithic architecture has its own advantages, it also poses a number of challenges. Some of the key challenges include:

    • Since, different components/ functionalities cannot be deployed independently, it slows down the development and deployment process for everyone, thereby greatly affecting the speed-to-market.
    • A failure in one part/ component will affect the entire monolith.
    • Different functionalities within a single package may have widely varying computing resource requirements. There may be a need to scale different components independently. That is not possible in a monolithic architecture.
    • Since everything is packaged under one roof, there is bound to be resistance to change the existing technology stack, even if certain functionalities can be handled better by other stacks.
    • Loading a huge code-base in the IDE will affect developer productivity.


Steps are being taken/ contemplated by most Insurers to modernize their IT systems and address these challenges. Some of the key trends include:

    • Cloud adoption: With speed-to-market being one of the primary concerns, cloud adoption helps automate and drastically reduce the time to procure IT infrastructure, provides enhanced and simplified IT management and maintenance capabilities, better reliability, and reduces costs.
    • Agile and DevOps: Agile and DevOps help faster delivery of features, more stable operating environments, improved communication and collaboration, and more time to innovate.
    • Microservices: If an application has a monolithic architecture, it does not help achieve the full benefits of Cloud adoption and DevOps. This is where Microservices Architecture fits in. When a microservices-based architecture is adopted, the benefits realized include:
      • Helping truly leverage Agile Methodology with smaller, independent teams.
      • Increased speed-to-market and agility, with shorter build, test and deploy cycles, which helps the faster rollout of newer versions of a service.
      • Ability to scale specific functionalities, independent of others.
      • Better reliability, since failures are more isolated.
      • Better availability due to greatly reduced/ zero downtimes during rollout of newer versions.
      • Greater choice of technology stacks, since microservices are loosely coupled.


MSA in the Insurance Industry: Scenarios, Approaches, & Pre-requisites

A commonly expected scenario in the Insurance industry is one where, a monolithic legacy application that has served the business needs of a company for years, needs to be modernized.
The transformation from a monolithic architecture towards a Microservices Architecture is supposed to ensure more independence/ autonomy, speed-to-market etc. However, the transformation will not be the same for every organization/ domain. What worked in one organization/domain may not work for another.

Big Bang or Incremental?
Given the fact that microservices introduce more complexities, and there could be many unknowns, things could go wrong in a Big Bang approach.
Hence, it is important to start small and take key learnings forward, as one incrementally migrates all functionalities to MSA.

Incremental Approach
In this incremental approach, whenever any new functionality is needed, it is developed as a separate, independent service, instead of adding to the existing monolith. Also, from the existing monolith, modules are extracted into independent services, one at a time. While the refactoring is done one new service at a time, the newly created services co-exist with the existing monolith until the monolith keeps shrinking and is ultimately, fully replaced.
To make this process simpler, it is recommended to refactor the code within the monolith into loosely coupled modules first.

Starting Small
In this incremental approach, it is important to choose the right module/ functionality to start with.
1. Choose a module that is easy to extract. This will help one implement it quick and also document best practices etc. for the other services that will be implemented.
2. The focus can next be on modules that offer the most business value as separate microservices. Examples include:

  • Modules that change very frequently - ensures that only this service needs to be redeployed after every change.
  • Modules that have significantly different scalability or other computing resource requirement

3. As newer services are added, it is important develop the competencies (elaborated later) that are essential for adopting MSA.

Data Ownership, Consistency etc.

One of the most challenging parts of building microservices is the ownership of the underlying data. The domain model in the Insurance industry is more complicated than the ones where microservices were first implemented. Hence, it is important to identify the most appropriate bounded contexts while developing microservices. 
In the traditional monolithic architecture, ensuring data consistency is far simpler since the entire database belongs to one monolith. But, to reap all the benefits of MSA, every service needs to be independent, with its own private data. This introduces a lot of additional complexity when it comes to managing data consistency across multiple services.
This requires a change in the mindset, to embrace concepts such as Domain Driven DesignEvent Driven ArchitectureEventual consistencyResilience from Failure etc. Also, this might necessitate a remodeling of the underlying data model, to be able to adapt to the new architecture.


.....To be continued in part II

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.