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

« August 2017 | Main | January 2018 »

September 18, 2017

Microservices in the Insurance Industry - Part II


...continued from Part I


Maturity Level in an organization for MSA      

When MSA is being introduced, it is important to be prepared to handle the additional complexities and realize the benefits. Below are some of the key competencies that are considered essential in an organization for effective implementation of MSA:

  • Containerization and Automated provisioning: One of the key drivers behind MSA is that services can be deployed and scaled independently, based on the demand. Also, MSA demands reliable and scalable infrastructure. For this to happen seamlessly, there is a need for containerization (e.g. Docker), and the provisioning of resources (servers, virtual machines, containers etc.) should be automated as much as possible. This can be achieved by the effective adoption of one of the various available cloud platforms (e.g. Azure, Cloud Foundry, AWS) for computing resources.
  • Monitoring: When MSA is adopted, one can expect a large number of services in the target state. By its very nature, one can expect very frequent changes and deployments of different services. In such a scenario, chances of any of the services not working as expected increase. To enable to quickly troubleshoot, pinpoint and fix an issue, it is important to invest in robust monitoring of all the services. Also, since transactions could span multiple services, the logging mechanism should ensure complete traceability.
  • Automated Deployment: Whether it is introducing new features, or fixing bugs, one can expect a large number of deployments within a short span of time in the MSA world, in comparison to monolithic systems. This calls for the ability to rapidly deploy changes, and hence tools and process to automate deployments as much as possible.
  • Agile and DevOps Culture: Rapid rolling out of new features, fixes and deployments requires Agile development and DevOps culture.
  • Event Driven Architecture, Eventual Consistency etc.: With MSA, data is expected to be private to every service. This requires a big change in mindset with respect to data consistency and the way systems are designed and developed. With a large number of services, interactions between different services is expected to be asynchronous, and it is important for the organization to embrace the concepts of Event Driven Architecture and Eventual Consistency.

E.g.: Consider a Policy Administration System that takes an underwriter through the various stages of a Policy - Submission, Quote, Bind, Issue etc. After successful completion of every stage of the workflow, it is necessary to update the status of the policy in the master data. This would be simpler in a monolithic system with a single database, since each action can have direct access to, and update all the necessary data within a single transaction. However, in the case of MSA, for instance, the Issue Service may not have direct access to the Policy master data. So, after the successful execution of the Issue service, an event may have to be published to a message broker with the necessary details, which will be subscribed to by the Policy Service, to update the status of the Policy in the Master Data. This is not an ACID transaction; here the data belonging to different services is expected to become eventually consistent.

MSA sample use case.png

  • API Management, Gateway, Security etc.: For a monolithic service, interactions between the client and the service, as well as security implementation tend to be simpler. However, with a large number of microservices, this would become complex. Hence, for instance, instead of every service in a MSA implementing security separately, an API Gateway may implement centralized security. Similarly, instead of the UI making a large number of calls to the services, an Edge Service may do the necessary orchestration and reduce the chattiness of interactions between client and services.
  • Service Discovery: In a MSA scenario, new instances of services can be launched on demand, moved to different computing resources, and so on. For a client to be able to easily and correctly connect to the target service, a Service Discovery (e.g. Eureka) solution is essential.
  • Resilience to Failure: When a monolith fails, the entire system fails. One of the key goals for adopting MSA is that when a monolith is split into a large number of small services, the failure of one of them should not bring down the entire system. But, if the services are too dependent on each other and not built to withstand failure of one or more individual services, it will defeat the purpose of MSA. Hence, it is necessary to design services keeping fallback procedures (e.g. using Circuit breaker) etc. in mind, to make the entire system resilient to failure.

 

Typical use cases in the Insurance Industry

In the Insurance industry, if we take the example of a Policy Administration System, some of the key functionalities include:

      • Account management
      • Intake of applications through various channels
      • Submission
      • Quote
      • Bind
      • Bill
      • Issue
      • Rating
      • Document Processing etc.

 

Before one dives into MSA, it is important to assess the overhead and risks involved, as well as the potential benefits. There are some key implementation considerations that need to be kept in mind:

    • Service Granularity: When a service has low granularity, it is less agile, but simpler with fewer interactions. On the other hand, when a service is highly granular, it is highly agile, but is more complex with high external interactions. The goal is to keep services small enough to stay focused and big enough to add value.
    • Data Ownership: For a service to be truly independent, it should have its own private data. Any communication with other services should be over exposed public interfaces.

 

Where MSA can work:

Some functionalities can be more easily segregated into independent services than others. For e.g., Account/ Customer management, Rating, Billing, Issue etc. are functionalities that can become truly independent microservices, if the underlying data models are well designed and interactions with other services can be minimized.

 

Where pure MSA may not be beneficial:

However, if there are functionalities (e.g. Submission and Quote) where the underlying data is very closely knit with each other and data consistency is very important, pure MSA can be a challenge. The overhead of managing data consistency and communications between such services can make it too complex and risky, thereby outweighing the benefits of MSA.

In such cases, it may be more beneficial to initially have granular services for each functionality along with a Shared Database. Later on, if required, there could be a remodeling of the database, to have separate databases for each service.

 

Other use cases for MSA:

There could be certain functionalities (e.g. document processing) that are highly resource intensive. Such functionalities are good candidates for microservices, since they can be independently deployed and scaled as per needs, thereby avoiding adverse impact on the performance of the rest of the application.

MSA - Transformation.png

Conclusion

The transformation from monoliths to microservices will help an organization improve its agility, speed-to-market and efficiency, and thereby compete better with its peers. However, there are no hard and fast rules for this transformation. What worked for one may not necessarily work for another organization.

Organizations that are pioneers in MSA faced a different set of challenges. Insurance is a different domain, with a more complex domain model. Transformation to MSA here will have a different set of challenges. It necessitates a major change in the mindset of all stakeholders - embracing concepts such as Domain Driven Design, Eventual Consistency etc. Systems will have to be designed accordingly, striking a balance between simplicity and agility.

Also, there are many pre-requisites to the adoption of MSA - some of the prominent ones being the capabilities in Automated Provisioning, Continuous Delivery, Monitoring, Agile Development and DevOps culture. Though an organization may start small with a single service, one has to eventually develop all these competencies before the widespread adoption of MSA.



References

http://blog.christianposta.com/microservices/why-microservices-should-be-event-driven-autonomy-vs-authority/

http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/

https://www.nginx.com/blog/refactoring-a-monolith-into-microservices/

https://martinfowler.com/bliki/MicroservicePrerequisites.html


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

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter


Categories